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.
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… https://issues.apache.org/jira/browse/CB-330
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.