iphone - Application rejected because of not following iOS Data Storage Guidelines

Question

We're storing data into Document directory of application and we got rejection of application. We've tried with "do not back up" attribute for storing data in current version with below code.

- (BOOL)addSkipBackupAttributeToItemAtURL:(NSURL *)URL{

    const char* filePath = [[URL path] fileSystemRepresentation];

    const char* attrName = "com.apple.MobileBackup";

    u_int8_t attrValue = 1;

    int result = setxattr(filePath, attrName, &attrValue, sizeof(attrValue), 0, 0);

    return result == 0;

}

We've used it as per iOS Data Storage Guidelines.

In earlier version we've also tried with storing data in Private directory. But, we were not able to get approval of application.

Can you please give us some more description regarding why we are not able to get approval of application? or yet, we need any other changes in code regarding data storage? So, that we can get approval and we've new version of application on iTunes.

Answer 1

I think @Jasarien's comment is the right answer, but there was no further comm, and this question is relatively new, so I'll expand.

For others to see the rejection you get:

The iOS Data Storage 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.

4. Use the "do not back up" attribute for specifying files that should remain on device, even in low storage situations. Use this attribute with data that can be recreated but needs to persist even in low storage situations for proper functioning of your app or because customers expect it to be available during offline use. This attribute works on marked files regardless of what directory they are in, including the Documents directory. These files will not be purged and will not be included in the user's iCloud or iTunes backup. Because these files do use on-device storage space, your app is responsible for monitoring and purging these files periodically."

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.

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.

Data that can be recreated but must persist for proper functioning of your app - or because customers expect it to be available for offline use - should be marked with the "do not back up" attribute. For more information, please see Technical Q&A 1719: How do I prevent files from being backed up to iCloud and iTunes?.

So I see why you would use "do not back up" and expect to be in compliance, but I think like @Jasarien said - They mean for you to move to more discrete directories like cache or temp.

In fact what would definitely pass the review is switching to Core Data and using the internal SQLite - but that's probably too much work.

So to wrap up - a post on how to save to caches or tmp - Where to save files in iOS 5 applications? (actually, maybe this was all a duplicate of that one... :-/)

GL! Oded

-- Edit --

Another good post: https://stackoverflow.com/questions/8164868/ios-data-storage-guidelines-available-since-when

-- Edit #2 --

And another good post: iOS 5 does not allow to store downloaded data in Documents directory?

Guess I should've just pointed out the duplicates... :)