Storage Issue with iOS-5 And iCloud - AasimNaseem.com

Storage Issue with iOS-5 And iCloud;

Aasim Naseem,
Category: My Tutorials > iOS

Hello everyone ..

Now a days, we are noticing that many people are getting rejection from AppStore due to storage issue; I looked into this issue and here are my findings regarding iOS-5 and iCloud;

When we install our application in device, we have three main directories in our application space

  • <Application_Home>/Documents
  • <Application_Home>/Library/Caches
  • <Application_Home>/tmp


Applications normally store their data in the/Document directory and everything work normally. Applications can also store their temporary data in /tmp and /Library/Caches directories, and it get deleted when user uninstalls the app from device; Apple accepted such applications in past that store application-specific data, as well as downloadable content in the /Document directory. Examples are magazine app etc.


In iOS 5, the iCloud was introduced; It keeps users’ applications and data synced among different devices. In actual, iCloud sync everything that present in /Document directory for an application. As this data may be large (including downloadable content), Apple has now start rejecting such apps that store their data in the /Document directory, saying that as iCloud backups are performed daily over Wi-Fi for each user’s iOS device, it’s important to ensure the best possible user experience by minimizing the amount of data being stored by your app. In addition to purchased music, apps, books, camera roll, and device settings, everything in your app’s home directory, including its Documents folder, is backed up to iCloud.

Many developers store all of application’s data in /Document directory. So due to iCloud issue, the option of storing our data at this place has been eliminated.

The alternate was /tmp and /Library/Caches directories, as we all knew that they are intact by iCloud and OS; But in iOS 5, there’s an important change with these two directories –the only two directories that aren’t backed up — are now “cleaned” out without any notification or alert to user, when the device is low on space; If someone have never observed files being removed from these directories in the past, that is not a guarantee that it will not change in the future. Especially when the change is in accordance with documentation;

So at this point, all possible places are not reliable to store downloadable data;

  1. using /Document directory will surly lead our app to rejection.
  2. Cache and/or tmp directories are afraid of being cleaned out at time if device has low storage space; Worst aspect is user won’t be notified for both low storage and for cleaning process.

Apple suggest two possible solutions for this issue:

  1. Mark the files “do not backup” if you dont’ want your file to be backed up by iCloud.
    Issue: This may be a possible solution but this flag is available from 5.0.1, Not even in 5.0.
  2. Your application should store all downloadable data in the cache or tmp directory, and keep watching them keenly if some important data is deleted by OS. In such case, user should ask to download them again.
    Issue: But even with available, fast, unlimited internet connectivity, randomly deleting an app’s data is still a problem; User may feel annoy by downloading the content time and again.

What I did with my application is

  • Start storing all downloadable contents in /Library/Cache
  • For existing users, I moved all their contents from /Document to /Library/Cache;
  • /Document directory has now only a database file (which is treated as application specific data) All downloadable contents has moved to /Library/Cache.

Here are two links that discuss the whole story in a very nice way:

First read http://www.marco.org/2011/10/13/ios5-caches-cleaning
and then http://iphoneincubator.com/blog/data-management/local-file-storage-in-ios-5

If anyone has more info on this topic, kindly share;

Author Profile

Aasim Naseem
Hey, Thanks for your interest. I’m a PMP, AWS Solutions Architect, and Scrum Master certified professional with 17+ years of hands-on experience leading projects, building teams, and helping organizations deliver software solutions better, faster, and smarter.

Outside of work, I’ve got a deep curiosity for history — especially ancient civilizations like Egypt. I also enjoy reflecting on the everyday moments that shape how we live and work. This blog is my space to share insights, lessons, and thoughts from both my professional journey and personal interests.

Thanks for reading — and I hope you will find something here that matches your interest.
iOS

Related Posts

Comments (3)

  1. This does seem quite serious, especially to those of us whose applications use large amounts of paid-for, downloadable content because of their nature. It seems a special problem for those whose iPad applications are intended to be used mainly offline.

    Surely there must be many developers facing this issue. Do you know what approaches they are taking?

    Bruce

    Reply

    1. There are two possible ways to get ride of this issue; First is: Move all of your downloadable contents to Library/Cache; But issue is if user is offline (while flying to/from different states) then deleting his/her contents will surly lead to very unhappy situation; Second solution is use “do not backup” flag with your contents, present in /Document director; It will prevent them to be backed up with iCloud; But I’m not sure still if Apple accept this approach and accept the application having heavy data in /Document directory; I used the first approach; Add a routine which moved all existing contents to /Library/Cache directory, and turned every next download to Cache, not /Document;

      Reply

      1. In my case, it is specially modified versions of licensed audio songs that are involved. The user purchases these one by one and might have a dozen or more. Each is anywhere from 2MB to 30MB. They would be very disappointed if they had paid for their purchases and then tried to use them offline and found them missing, for instance within a car on an iPad that did not have 3G. So I suppose the second solution is perhaps best for me, though it would presumably mean that I’d have to requiring or at least recommending 5.01. And from what you said, my data would still be susceptible to unexpected deletions if space were at a premium. (And how many of us haven’t loaded devices to near memory capacity?)

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *