Apple iOS HTML5 localStorage is Broken.

Posted on by Dan

One of the things I have admired about Apple has been their commitment to supporting web standards, or at least interpreting the recommendations intelligently and in the spirit of the W3C’s good intentions.

With the most recent release of iOs, version 5.1 (and in previous beta and developer releases since 5.0) they have purposefully hobbled one of the most useful features in the recent set of recommendations… Localstorage.

The current set of recommendations form the draft HTML5 specification and whilst each version of HTML takes many years to finalise, many recommendations dont change much during those years, and many appear in browsers long before the final version is published. This is the case with Localstorage.

In iOS 5.1 Apple have moved the location of localStorage files into a Caches folder which is subject to occasional clean up, at the behest of the OS, typically if space is short. It is likely that Apple have done this to stop localStorage being backed up to iCloud.

The real problem here is not to do with Apples choice to have the OS move files or where they are stored, or any other implementation detail. All the things Apple’s iOs is doing is their business. Whether WebKit local storage gets backed up to iCloud is up to Apple, and has nothing to do with the HTML5 recommendations.

The problem is simply that the recent changes have a disastrous breaking side effect.

Webkit on iOS no longer has persistant localStorage

By moving localStorage to the Caches folder, they have allowed localStorage to be cleaned up whenever iOS wishes.

Persistance is one of the two things that the localStorage recommendation makes explicit, even if by obvious implication….

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

A reasonable interpretation of that line would be the following two specifications.

1. Users should expect localStorage to be persistant, unless there is a security problem.
2. Users can explicitly delete localStorage.

Going into settings and deleting the database or localStorage is a valid implementation of the second requirement. Having the OS deleting localStorage is not.

So in summary, I don’t care that Apple wanted to back up less data to iCloud, I dont care where they store the data for their implementation, or if they move it around.

I simply care that there is a standard localStorage API available to my javascript code that is consistent with the recommendations and accepted behaviour for that API.

iOS 5.1 now has a broken implementation of localStorage, rendering it useless for its intended purpose.

In a recent forum discussion another commenter suggested that because the recommendation only says ‘SHOULD’ then iOS clearing out localStorage as it wishes does not mean the implementation is broken.

I replied that I don’t think ‘SHOULD’ should be quite such an easy get out clause…

Looking at RFC 2119, should is defined as:

3. SHOULD This word, or the adjective “RECOMMENDED”, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

In the case of iOS the ‘full implication’ of the changes is that localStorage can clearly not be considered persistent, and is therefore no more than a temporary cache, subject to garbage collection, which is definitely not what localStorage was conceived for.

Mobile device or not, systematic non deterministic removal of persistant data is bad form. There are much more sensible policies to mediate shortage of space.

If this is a case of Apple loosely interpreting the spec to mean localStorage should be treated as a temporary cache, then I think they have made a naive mistake. If they have taken the spec as it was clearly intended then their implementation is very broken.

This is the kind of interpretation that led Internet Explorer into a cul-de-sac of hate, so I hope it is just a slip up on Apples part, though they knew about it in 5.01, and allowed it to make its way into 5.1!

This issue affects Phonegap apps (like ours) but Shazron had released a patch a while ago…

Having a wrapping framework mitigates this kind of breaking change, but thats not really the point, discussed further on Tim Andersons blog


In fact on re-reading the recommendation, it is clear that it states that localStorage is an API for persistent storage of data, the *SHOULD* referred to above is actually should clear localstorage when there is a security risk.

This entry was posted in Uncategorized. Bookmark the permalink.
  • Pingback: Quora

  • Pingback: Quora

  • Pingback: Apple iOS HTML5 localStorage is Broken. | Money Toolkit | HTML5 News |

  • Sam

    It’s a pity. I really hope Apple will fix that.

    • Dan

      Yeh, I’m not sure they will. A lot of the comments from the Apple camp, appear to think it is an OK implementation.

  • Dan Mullineux

    Yeh, I’m not sure they will, a lot of the commenters from the Apple camp, appear to think it is a reasonable implementation.

  • Oscar Campos

    Its way more clear with the webkit sqlite database… Whats the whole point of it? Just some fancy temporal selects? You cant rely on it keeping the data, and you would need to populate it everytime iOS arbitrarily chooses to delete it…

    Completely broken

    • Anonymous

      Yep, agreed. In fact when you look at the spec closely its pretty clear for localStorage as well. Not good at all!

  • Derryl Carter

    The unfortunate truth here is that Apple actively denies functionality to web-apps. Whether it’s media playback or content caching, they’re always hobbling web-apps so that (supposedly) folks will be more likely to develop them natively. It’s a shitty business strategy, and it ends up hurting everybody.

    • Dan Mullineux

      Its such a shame, their webkit implementation is otherwise ahead of the pack.

  • Gogi

    Thanks for sharing this tutorial.Great help

  • airheart

    Yep. Local Storage is broken for iOS 5.1 and later. :-(