Summary:
Safari and full-screen web apps (a.k.a. web-app-capable) have separate in-memory write-through caches of the localStorage data. Each time the full-screen app becomes active, it reloads the localStorage from disk (allowing it see Safari's changes). However, when Safari becomes active, it doesn't reload the localStorage data from disk, so it won't see changes made in the full-screen app unless you kill Safari and restart it.
Full Explanation:
There are only two hard problems in Computer Science:
- cache invalidation
- naming things
- off-by-one errors
The buggy behavior in localStorage is a result of problem #1. Here's why:
When the iOS browser engine loads, it reads the data for localStorage from disk and caches it in memory. Then each time you read data (e.g. getItem), the data is read from memory, not from disk; and when writing (e.g. setItem) the data is written to memory, and then (asynchronously) flushed to disk. Since localStorage is synchronous, this implementation is a totally reasonable. If it went to disk for all reads and writes, your javascript would be blocked on every read/write to perform expensive disk IO.
The problem is that a full screen web app (let's call it a FSWA) uses a separate instance of the iOS browser engine, and although a FSWA shares the same location on disk for the localStorage data, it does not share the in-memory cache of localStorage data with Safari.
When you add the fact that FSWA completely reloads (which means the localStorage data is reloaded from disk) each time they become the active application, you get the behavior that you are seeing.
Here's the behind the scenes...
- user makes a change that writes data to localStorage in Safari
- Safari writes data to Safari's in-memory localStorage cache
- Safari flushes localStorage data from cache to the disk
- user leaves safari and launches the FSWA
- FSWA loads and reads localStorage data from the disk into in-memory cache
- user sees the data that was changed (in step #1) in Safari
- user makes a change in the FSWA that writes data to localStorage
- FSWA writes data to its localStorage cache (Safari's cache is not updated)
- FSWA flushes its localStorage cache data to disk
- user switches back to Safari
- Safari was already running, and it does not reload the localStorage data from disk
- Safari reads the old data from its existing in-memory cache
- user does not see changes made in step #7
To prove this, you can kill Safari between step #4 and step #10. Then when you relaunch Safari in step #11, it will reload the localStorage from disk and you will see the data written by the FSWA.
