The common wisdom is that the arrival of iCloud and iOS 5 will let us store our stuff on the cloud and buy an iPhone and iPad with less memory. However, a recent developer blog post warns that more memory is the better choice.
The issue was presented by developer Marco Arment, the maker of the useful Instapaper, the off-line content reading service and application. The post says the problem arrived with iOS 5 and its automatic backups to iCloud.
It happens that developers have stored data in several temporary caches. This was data that was useful to the application (and for the user experience) but wasn’t backed up in the iTunes sync cycle.
Now the data could be redownloaded, but that might take a long time depending on the available bandwidth (think Wifi vs. Edge) as well as the size of the cached files (the very reason that this data is not included in the usual backup and sync). Apple didn’t flush the caches so everything was fine and developers began to rely on storing their data in the caches.
However, now with iOS 5 and iCloud, Apple wants developers to reduce the amount of data overhead for their apps. If data can be redownloaded, it should be. Arment quotes some developer notes and memos:
1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the <Application_Home>/Documents directory and will be automatically backed up by iCloud.
2. Data that can be downloaded again or regenerated should be stored in the <Application_Home>/Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.
The problem as Arment explains it is that the cached data is now cleared when capacity falls to some low point. For Instapaper, this means content stored for offline reading, but it could effect apps that deal with map data, e-books and podcasts. If the user fills up the device with content, the caches with the content might be flushed.
He reports that one of his customers recently packed her iPad full of games, video and materials to read for a long-distance flight — a natural action — only to discover that her actions had triggered the cache cleaning routine. No reading for her.
Of course, downloading large amounts of data in the wild may not be practical or possible.
But even with available, fast, unlimited internet connectivity, randomly deleting an app’s data is still a problem:
When customers save an article with Instapaper, get a book in iBooks, or download a podcast with Instacast, they expect it to be there next time they launch the app. Even though it’s technically redownloadable, customers see that as their data — they put it there, and it’s theirs to remove if and when they see fit.
When the cleaner wipes it out, it appears that the app has failed and deleted their data. And customers won’t know that it’s an iOS 5 behavior — they’ll understandably blame the app developers. Even though it’s not our fault, it’s certainly going to become our problem.
There needs to be a file storage location that behaves the way Caches did before iOS 5: it’s not backed up to iTunes or iCloud, it’s not synced, but it’s also never deleted unless the app is deleted.
My guess is that Apple will fix this issue for developers shortly. Still, buying the iPhone and iPad SKU with more memory appears to be the best choice for performance and productivity.
