Apple breaks web storage in iOS 5.1, does not care about web apps?

Many iOS apps which rely on web storage APIs for persistent data have been broken by the recent upgrade to iOS 5.1. The issue affects apps built with PhoneGap or others which use WebKit APIs to store data. The affect for users is that they lose all their data after the upgrade. For example, it sounds like the issue has hit this app:

image

Another developer says:

My statistics show users abandoning ship as their settings are wiped over and over, after each app restart.
This is a critical error that must be patched as soon as possible. Remember there’s also a delay from Apples app approval process to consider.

Put more precisely, WebKit used to store its local databases in Library/WebKit which is a location that the OS regards as persistent and which is backed up to iCloud. In iOS 5.1 this data is stored in Library/Caches which means it is regarded as temporary and likely to be deleted. The W3C Candidate Recommendation says of localStorage:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

An embedded browser is not quite the same as a web browser though, and if you are using SQLite in Webkit then that falls outside the W3C HTML 5 API since Web SQL is no longer included.

The issue is complicated in that there also seems to be a bug, described here, which causes data to be lost after upgrading an app to a newer version; and there are problems with actual web apps as well as with apps that use an embedded UIWebView.

PhoneGap is fixable in that it can call native APIs and there is work going on to implement this. The danger is that more platform-specific code undermines the cross-platform benefits.

Discussions on the Apple developer forums during the beta period for 1OS 5.1 show that Apple was aware of the issue and that it is by design. The impression given is that Apple was annoyed by the number of apps using web storage to speed up their apps (whether web or native) rather than just storing customer-created content, and felt it was imposing too much burden on the constrained storage space in an iOS device.

It does not help that there is no way to increase the storage in an iPad or iPhone other than by replacing it with a newer one with more memory.

The problem is a real one, but you cannot escape the impression that Apple considers solutions like PhoneGap, or even web apps that behave like local apps, as a kind of workaround or hack that is to be discouraged in favour of apps written entirely with the iOS SDK.

Apple benefits from true native apps as they are more likely to be exclusive to its platform, and must be sold through the App Store with a fee to Apple.

The official Data Storage Guidelines for iOS are here.

VN:F [1.9.18_1163]
Rate this post
Rating: 9.3/10 (9 votes cast)
Apple breaks web storage in iOS 5.1, does not care about web apps?, 9.3 out of 10 based on 9 ratings

Related posts:

  1. Google Apps add-on breaks Outlook features in email wars
  2. No Java or Adobe AIR apps in Apple’s Mac App Store
  3. Native apps better than web apps? That’s silly talk says PhoneGap president
  4. WebKit dominance threatens mobile web standards – but who will care?
  5. Amazon Elastic Compute Cloud gets persistent storage

12 comments to Apple breaks web storage in iOS 5.1, does not care about web apps?

  • does iOS allow per-app storage in browserspace? I could see moving from /webkit to /somewhere-accessible as a security fix and if it put space-sucking apps back in their place it’s a bonus…

  • tim

    it puts apps indiscriminately “in their place” if using PhoneGap etc (space-sucking or not) but leaves other space-sucking native apps alone.

    Tim

  • Phil

    Sounds like PhoneGap was napping during the iOS 5.1 beta period. They should have been ready for this sort of change since the larger platform shift has been going on for 6 months already, as described by the ever-readable Marco Arment:

    http://www.marco.org/2011/10/13/ios5-caches-cleaning

    I think the user who filed the original PhoneGap bug report has it just about right:

    “As a framework, PhoneGap / Cordova have to follow platform rule and not the other way round. Thus, this issue should be handle by PhoneGap / Cordova instead of Apple.”

    Any time there’s a platform “adjustment” that inconveniences developers (i.e., requires them to pay attention), you need to ask “Does this change benefit users?” The answer is almost always yes.

  • Dave Lewis

    Gotta love the fanboy comments which equate to: “it’s phonegaps fault, just suck it up”…

    It’s ironic that Apple now regard web based apps as second class since, when the iPhone first came out, that was the only game in town until people complined hard enough that a way of making native apps was created. Not so odd is that now Apple have the power, the no longer feel the need to listen to their customers.

  • “Sounds like PhoneGap was napping during the iOS 5.1 beta period.”

    Well, basically PhoneGap is now working on providing a workaround to the problem Apple created. They are creating a native API call, when it should just work with LocalStorage. Which means web apps are not quite as transferable/cross platform on iOS.

    ““Does this change benefit users?” The answer is almost always yes.”

    How is this benefiting users? By causing apps to break temporary and have users lose their settings before they switch from using a web technology to a native call to do the same thing? PhoneGap apps taking up too much memory with LocalStorage isn’t an issue that is solved when they switch to a native call and take up the same amount of storage.

  • Phil

    @Dave: “Apple now regard web based apps as second class” – because Tim said so in his lurid headline, right? Do you have any evidence at all that Apple regards Web app thus?

    @Matthew: “PhoneGap apps taking up too much memory with LocalStorage” – because Tim said so, right? Do you have any evidence that PhoneGap had anything to do with the change?

    PhoneGap’s fix should have no impact on the “transferability” of Web apps. A PhoneGap “app” is mostly a UIWebView browser control that loads JS/HTML/CSS. The JS calls either the browser-supplied HTML5 storage API or, now, an Objective C plugin that then calls iOS’s Sqlite library directly. The latter approach should give better performance and removes uncertainty about what the browser is doing; no need for the user’s code to change if the plugin supports the same storage API.

  • @Phil The argument “The latter approach should give better performance and removes uncertainty about what the browser is doing”.. Is an argument for not agreeing standards in the first place, and ends up creating the kind of frustration one sees directed at internet explorer, for example.

    Phonegap is referenced in the article, but this is less about Phonegap’s excellent work taking advantage of the commonality of javascript and html/css rendering engines and is much more more about intelligently interpreting the W3c’s recommendations.

    The working group and the candidate recommendation clearly state “User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.” A common Storage API available to Javascript is a valuable thing for web apps and mixed apps alike.

    Taking the decision to implement a recommendation in such a way that is contrary to any reasonable interpretation, for whatever reason, is at best foolish and at worst separatist.

  • Phil

    @Dan: Both you and Tim seem to put quite a bit of stock in “User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.” Would you also agree then that PhoneGap “user agents” should provide a way for the user to delete local storage data the way Mobile Safari does (see Settings -> Safari)? Do you know of any that do? In the absence of that critical feature, does that make iOS the user by proxy for a deficient app?

    Note that Safari even provides a “private browsing” mode that blocks all offline API use.

    If you look at PhoneGap’s excellent start on a cross-platform library:

    http://docs.phonegap.com/en/1.5.0/index.html

    it appears as though only two of these use W3C API’s, probably because there is no standard for many of the things that mobile devices can do. The W3C API’s are primarily useful to Web browsers because of restrictions on what they can access locally. But PhoneGap apps, via its plugin system, don’t have those restrictions, which makes me wonder if it was such a good idea to use these W3C APi’s in the first place just because they were there.

  • What Apple is doing here is basically making sure they remain in control. I seem to remember financial times making an app that (for some reason) rubbed apple the wrong way (probably selling subscriptions) – as a result they were booted out of appstore. In response they created a full app using HTML5 – using local storage to speed things up. Since HTML5 is now so powerfull (www.op4js.com), you can create full blown apps that bypasses apple’s cash cow. Hence they have started to disable or remove key elements from Safari mobile. Not big enough changes to create an outroar – but large enough to block serious development of persistent apps.

    At the same time – it’s a risky game. I for one have become somewhat annoyed at their methods and will look more and more to android and windows phone in the future. I hope apple changes their policy (not to mention how they ruined the html5 audio api) because it will impact their support.

  • Phonegap – is really a necessary evil, and is hopefully only a moment in time thing. It is definitely and sadly a symptom of the slow moving W3C spec.

    The ideal scenario is that all browsers implement the spec in as similar way as possible, and that the spec evolves quickly enough to keep up with platform advances, and agrees common API’s to new capabilities.

    The first thing has not happened in the past, with I.E undoubtedly the worst contender. Now there is an ascendancy of much more compliant browsers, particularly on mobile, with WebKit clearly dominant. But things are still slow wtr. access to native platform capabilities, hence Phonegap.

    It not only makes sense for Phonegap (cordova whatever) to do as little as possible, and allow the core browser layout, and javascript engines to do as much as possible, but also to deprecate its own API’s as and when it can, if they are well supported in Javascript.

    localStorage is one of those API’s that Phonegap should not have to mess about with, its mature enough.

    Regarding developer best practice, and allowing the customer to choose to remove data, well yes that is something that should be in any good app. Agreed iOS provides good options for this, I also agree that Apple could refuse apps that dont exhibit responsible data management.

    You ask if any PhoneGap apps provide the option to delete user data stored in localStorage, I know of one…ours.

    http://f.cl.ly/items/3Z1Y191b1U3K0D2i2y2F/Screen%20Shot%202012-04-06%20at%2021.05.21.png

    and http://f.cl.ly/items/0Q3P0y2S1V1o2w090F03/Screen%20Shot%202012-04-06%20at%2021.07.10.png

  • Jon

    I created a web app that uses localstorage and SQLite to store everything offline. You could use the app entirely offline once the initial app was loaded. iOS 5.1 pretty much ruins the app because the data can be deleted at any time.

  • Timtimtimtim

    Apple gives people what they want. The user does not care one bit if something is done natively or as a web app as long as its discoverable. These days it’s not any harder finding a web app on google searches vs a native one in the app store.