AIR iOS- Solving [Apps must follow the iOS Data Storage Guidelines]

IMPORTANT: With Adobe AIR 3.6 beta, Adobe has introduced an API for cacheDirectory. They also included a property called "preventBackup" to prevent the file from being backed up to iCloud. Please check out the beta and Release notes. You can also Discuss the feature feedback here.
Many thanks to Pahup for posting the update here.

There are some AIR for iOS applications which got rejected due to following error.

Rejection: 2.23 Apps must follow the iOS Data Storage Guidelines or they will be rejected

Recently with the release of iOS 5, Apple updated the Data Storage Guidelines which are mentioned here(Only for the registered developers). The rejection details are similar to the one mentioned at this post. Just to keep you guys reading this article I am quoting the details from the post.

We found that your app does not follow the iOS Data Storage Guidelines, which is not in compliance with the App Store Review Guidelines.

In particular, we found magazine downloads are not cached appropriately.

The iOS Data Store Guidelines specify:

"1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the /Documents directory and will be automatically backed up by iCloud.

2. Data that can be downloaded again or regenerated should be stored in the /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.

3. Data that is used only temporarily should be stored in the /tmp directory. Although these files are not backed up to iCloud, remember to delete those files when you are done with them so that they do not continue to consume space on the user’s device."

For example, only content that the user creates using your app, e.g., documents, new files, edits, etc., may be stored in the/Documents directory - and backed up by iCloud. Other content that the user may use within the app cannot be stored in this directory; such content, e.g., preference files, database files, plists, etc., must be stored in the /Library/Caches directory.

Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app.

It would be appropriate to revise your app so that you store data as specified in the iOS Data Storage Guidelines.

So, to summarize AIR developers may face this problem if they are using Local Shared Objects or AIR File.applicationStorageDirectory API to write/save the data for their application.

UPDATE: I think above mentioned APIs are used on iOS for varied use-cases ranging from using them as a disk cache to using them for storing App preferences, configuration to saving user's work (Like XMLs, Game state etc.) So before you think that following solution is for you, follow this thumb rule. 


"If you are using above mentioned APIs to store any kind of file that 

• Can not be re-downloaded or regenerated by your application 
•  Presence of this stored file is essential for correct functioning your application(For eg. Progress a player has made in your game). 

In such case DO  NOT to use following solution, instead provide additional explanation about the nature of files and align their purposes with the reasons mentioned above."


Let me take one more para to explain why. Caches directory is supposed to be used to store files that are actually used as caches and hence those files, if deleted, should not have any impact on the functioning of your application. iOS takes liberty to

• Empty the caches directory in case it finds that device is under low disk space.
• If a user updates to new version of your application. Caches directory is not retained.

All these changes are made so that only the essential and necessary files are backed up to iCloud or iTunes backup. Hence, if current version of your application was uploaded before iOS 5 release. You may face a rejection in your next release (Even if you upload almost the same application.)

There is a quick and clean workaround available for this problem if you were writing to applicationStorageDirectory. Before starting you need to decide the place where the files should go as per the guidelines. I recommend scrolling up again and reading the 3 points in Apple Rejection note, they precisely define the directory you need to use based on the kind of file you are creating.

If you have used Local Shored Objects. The solution is little trickier, because we can not control the location where LSOs are stored. Hence the only way we currently have is to "Not to use LSO" or you may want to create some class like MyLSO which provides the similar functionality using File APIs(which in turn use the following solution)

Following is the code segment that will help you solve the problem. I will, as always, post the code first and then try to explain.

        
 // If the File falls under point 2 of rejection note
 public var cacheDir:File= null;
 // If the new File falls under point 3 of rejection note
 public var tempDir:File=null;
 
 //Initialize the Objects with proper paths.
 var str:String = File.applicationDirectory.nativePath;
 cacheDir= new File(str +"/\.\./Library/Caches");
 tempDir = new File(str +"/\.\./tmp");

Here, instead of using the static Directory paths populated by File class' properties, I am creating global File objects that point to the corresponding directories as per the Apple Data Storage guidelines.Now to create/write to any file you can use code that looks similar to following.

 var fr:FileStream=new FileStream();
 fr.open(cacheDir.resolvePath("myCache.txt"),FileMode.WRITE);
 fr.writeUTFBytes("works");
 fr.close();

I think this is it. You can use the code snippets at proper places in your applications.and I you should be good to go.

Just for completeness, here you can find the Apple Documentation about Data Handling Categories.