Retrieve Your cordova app’s localStorage Data Directly From iOS Device

Use Case

If WiFi fails, your ajax call fails and your backup re-submit code fails, you may need a last ditch solution of physically grabbing your form data from inside your PhoneGap app, off of an individual iOS device.


Make sure the app is coded to save data locally using HTML5 localStorage API.

Once the localStorage functionality is tested and working, and you have your PhoneGamp / cordova app running on an iPad, you can use PhoneView to access the file system on your the iPad.

Install DB Browser for SQLite on your Mac. Under the hood, cordova saves your localStorage data as a simple SQLite database.

Retrieve the Data

  1. Connect your device to your Mac and open PhoneView Demo
  2. Go to Apps in the main nav on the left.
  3. Click on Settings in the top nav icons bar and you’ll see this dialog window:
  4. Check the “Show Entire Disk in Disk Mode” and “Show All Apps in Apps Mode (Developers Only)” boxes. You’ll get a warning confirmation popup, which you should accept by clicking OK.
  5. You’ll now see your custom cordova app listed under Apps:

  6. The folders you want is yourApp/Library/Caches/ and yourApp/Documents/Backups/. The file should be called something like “file__0.localstorage” in /Library/Caches or “localstorage.appdata.db” in /Documents/Backups. It’s essentially a SQLite file, and can be opened using an app that lets you view SQLite files.
  7. To open it, you need to first copy the Library folder to your Mac.
  8. Click the Library folder to to select it
  9. Click on Copy from iPhone button in the top icons navbar
  10. Choose a location to save it on your machine.
  11. Launch DB Browser for SQLite
  12. Open your recently copied “file__0.localstorage” or “localstorage.appdata.db” files from your Mac in DB Browser for SQLite
  13. Click on the Browse Data tab towards the top of the interface
  14. You should see your localStorage Key / Value pairs listed as a SQL table:
  15. If you stored your Values as Arrays, your actual data may be stored as a BLOB data type and not plain text
  16. Select your BLOB value in the table and look at the right side of the interface, under Edit Database Cell
  17. Make sure the Mode is set to “Binary”
  18. You should be able to see your data with very bad kerning
  19. Click the “Export” button above the cell content area
  20. Save your file as .txt and open the .txt in any text editor, like SublimeText, to access your data as plain text.

Work in Progress: Choices for Mobile Development

Example “every day” app request:

Build me a “recipes” app that lets me browse resipes and take a photo of a dish and upload to Facebook App, Flickr account, Twitter feed, or Generic Server so it can later be displayed in a web view or another in-app view that gets refreshed after you get a “success” message back from the server that you uploaded to.

Right this second, I’d personally code it in Objective-C/Xcode first, then do a Java version for Android.

QUESTION: Given a bit more time and a chance to step back for a minute, which language, IDE, SDK should it be written in?

Near Term Technology Choices

  • Corona SDK
  • Objective-C in Xcode for iOS / Java in Eclipse for Android
  • AIR 3.1 for mobile, CameraUI
  • PhoneGap
  • Titanium

Corona SDK, media.Camera


  • As of 02.20.2012, lack of support for Web Services (REST, SOAP, etc) processing. So far just HTTP POST & GET and sockets.
  • 2.5D is not easy in Corona SDK. Trying to “fake 3D” or do 2.5D by scaling a physics body while animating it’s position doesn’t work out of the box, for example. Various hacks are required to fake it. While you’re resizing the visual graphic for every frame, collision detection is likely to get screwed up because the physics body’s collision bounding box doesn’t resize “on enter frame” after it’s been set once. This is a Box2D limitation, from what I’ve heard. In general, Corona is best for 2D content only, at least for the moment.


  • Holy shit! It’s so easy! If you have Actionscript experience (or Javascript application dev experience), Corona is a piece of cake. Feels easier than web Javascript (no DOM differences or old browsers to worry about). Here’s a Flash to Corona porting guide, their pitch to Flash Devs.
  • Has support for device hardware access to Camera (native Camera app can be call up) via
  • Has access to SQLlite.
  • No iAds support but has custom Ads framework with support for two ad networks.
  • Has built in Physics, Animation, Facebook, Analytics, JSON, In-App Purchases libraries.
  • Looks super approachable for the average AS3 developer. A bit more to learn for Front End devs who’ve never worked with sprite sheets, movieclips, easing equations, etc. Faster for Front End and Flash Developers to learn than learning about reference counting in Objective-C.

Objective-C / Java native, UIImagePickerController or AV Foundation framework / android.hardware.Camera


  • Building for iOS first (most likely). Will need to write separate Java version for Android. Two code bases to maintain.
  • Possible code base fragmentation between iPhone, iPad 2 and iPad 3, depending on how the app file size download limits issue plays out and whether. People are expecting x4 the pixels for iPad 3 high res display.
  • More dev time required


  • Closer to the metal, more hands on control of everything in the iOS / Android SDK. Fewer problems, re: lack of full native support in 3rd party mobile tools? (a.k.a. no need to find or write “native extensions”).
  • Cleaner code – just try opening up a published Titanium project in Xcode and take a look at the crap load of native code that converts JS to Obj-C included that would not be there if you built your app using native code in the first place.
  • A lot of clients, for the moment, seem very into iPads and iOS, more so than into Android (not a long term bet, considering Android’s market share, even with the hardware fragmentation).

AIR 3.1 for mobile, CameraUI and CameraRoll


  • Adobe’s sloppy management of the Flash platform was a highly frustrating and uninspiring series of events. Between the buggy releases of Flash IDE, Flash Builder and the Flash browser plugin, especially on Mac OS X, and Adobe’s bumbling PR fiasco re:HTML5, it’s belated focus on the Gaming market and it’s late introduction of Stage3D for mobile devices Adobe is not a company that inspires me with confidence when it comes to IDE’s and SDK’s for any kind of code.
  • Lack of full native support in 3rd party mobile tools? (need to find or write “native extensions”).
  • Need to super optimize AS3.0 code. Possibly at the expense of code clarity.
  • To get access to the Gyroscope and Notifications, you need to use a Native Extensions
  • Potentially unable to use some commonly used libraries, for example, if they’re not compatible with Starling framework (Stage 3D) etc. or if they’re likely to affect performance on slower mobile processors


  • There’s a legion of Devs with years of AS3.0 experience out there.
  • Tons of free resources all over the web.
  • I’m getting up to speed w/ Objective-C, have Java experience, how complex will it really be to write my own native extensions?
  • Possibility of a Single Code base for iOS and Android…



  • Adobe…
  • Lack of full native support in 3rd party mobile tools? (need to find or write “native extensions” ?).
  • Will still require lots of conditional code / State design pattern to account for platform specific features as well as iPad v. iPhone, standard display v. high retina display, etc.


  • PhoneGap has some elementary access to the iOS camera (at least).
  • More developers know Javascript, HTML, CSS or at least, those are easier to pick up than manual “reference counting” in Objective-C
  • Support for Web Services via Javascript, examples in their wiki.
  • Possibility of a Single Code base for iOS and Android…



  • Lack of on device debugging in the FREE version of Titanium IDE itself. Looks like there’s a 3rd party tool that might work.
  • Incomplete documentation in Titanium’s API docs. For example, as of 03.19.2012, the Filesystem API doesn’t document methods like mimeType(), which is nontheless included in the Kitchen Sink’s filesystem.js example.
  • Lack of full native API support. Need to find or write modules for certain native features.
  • Will take months for Titanium to be updated for features in every new native OS release (like it did with the iOS 5 release).
  • Will sometimes still require lots of conditional code to account for platform specific features as well as iPad v. iPhone, standard display v. high retina display, iOS v. Android, etc. Perhaps, this is not a surprise, since for Universal apps in Xcode one sometimes has to create separate Views or .xib files for Universal apps, one for iPhone, one for iPad.
  • Titanium IDE was super buggy on my OS X 10.6.8 machines at work and home. SDK 1.8.2 seems to have fixed these issues.


  • A reasonable level of Memory Profiling is possible for Titanium apps using Xcode’s Instruments.
  • Titanium offers you access to your device’s built-in basic camera app (UIImagePickerController on iOS), but it looks like a lot of the Titanium.Media camera related methods are iOS-only.
  • Enterprise-level support available, which Tech / IT Directors in charge of larger projects will find appealing.
  • Titanium allows developers to write their own modules, if Titanium itself is missing native features. There’s an iOS Module Developers Guide. For example, Titanium doesn’t support the iOS AV Foundation framework, the one that allows you to write your own custom Camera or Video application (as opposed to using UIImagePickerController, etc). Here’s a Titanium AV Foundation module written by a dev on GitHub (free, open source, under Apache License 2.0).
  • Has a Web Services (SOAP) example in it’s demo Kitchen Sink app. More developers already know Javascript.
  • Has iAds support. Possible to use other networks, like AdMob, through plugins/extensions (write yourself or get from their Open Mobile Marketplace)
  • Possibility of a Single Code base for iOS and Android…