IOS Storage Quick Guide
Many people have this problem, and it often seems that the review team automatically claims that your application does not comply with iOS storage rules. In any case, you need to document where your application store data is stored and what data is stored there. Here is a quick guide to get you started.
Your application can store files in / Documents, / Library or / tmp.
Documents /
Use this directory to store custom content. The contents of this directory may be accessible to the user through file sharing; therefore, its directory should contain only files that you might want to provide to the user. The contents of this directory are created by iTunes.
Library /
This is the top-level directory for any files that are not user data files. Usually you place files in one of several standard subdirectories. IOS applications typically use application and cache support subdirectories; however, you can create your own subdirectories. Use the library subdirectories for any files that you do not want to use for the user. Your application should not use these directories for user data files. The contents of the library directory (excluding the Caches subdirectory) are created by iTunes.
TMP /
Use this directory to write temporary files that should not be saved between starts of your application. Your application should remove files from this directory when they are no longer needed; however, the system may clear this directory when your application is not running. The contents of this directory are not copied by iTunes.
Put user data in Documents. It is supported by iTunes / iCloud
Put created application support files to the library / application support / This is supported by iTunes / iCloud
Place temporary data in the tmp / directory. It is not supported by iTunes / iCloud
But how do I know where my files are stored?
Put the script below in the func application: didFinishLaunchingWithOptions in the appDelegate file. NSSearchPathDirectory is an enumeration and represents different folders / locations. Here is some of them.
public enum NSSearchPathDirectory : UInt { case DocumentDirectory case LibraryDirectory }
Change the NSSearhPathDirectory (.DocumentDirectory) file to the desired location and check which files you store there.
let paths: NSArray = NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory.DocumentDirectory, NSSearchPathDomainMask.AllDomainsMask, true) if let documentDirectory = paths.firstObject{ do{ let documents = try NSFileManager.defaultManager().contentsOfDirectoryAtPath(documentDirectory as! String) for files in documents { let urlForm = NSURL.fileURLWithPath((documentDirectory as! String) + "/" + files) do{ try print("\(files): \(urlForm.resourceValuesForKeys([NSURLIsExcludedFromBackupKey])), with filepath: \(urlForm)") //Prints out folder and files in the desired location } catch let error as NSError{ print("Can't find key: \(error)") } } }catch let error as NSError{ print("Can't retrieve contents: \(error)") } }
My application doesn’t save anything
You are lucky ... Write a document to the Apple expert group and document the use of your application in the repository. Take screenshots from the logs made from the script above.
My application saves a lot of user data
If your application saves user data in the “Documents”, and that’s good, and write down a document documenting that this is done by the user, and follow the iOS Storage Guides.
If your application downloads data and saves it in the wrong place
Just follow the iOS Storage Guides and submit the new binary.
I have files in Documents / or Library / but I do not want to back them up
Starting with iOS 5.1, applications can use the NSURLIsExcludedFromBackupKey or kCFURLIsExcludedFromBackupKey properties to exclude files and directories from backups. Applications that need to exclude a large number of files can exclude them by creating their own subdirectory and marking this directory as excluded. Applications should create their own directories to exclude, and not exclude directories defined by the system. Any of these APIs are preferable to the old, deprecated approach that directly sets the extended attribute. All applications running on iOS 5.1 and later should use these APIs to exclude data from backups.
I created a quick script to handle files that you do not want to back up.
func addSkipBackupAttributeToItemAtPath(filepath: String)-> Bool { if let url: NSURL = NSURL(fileURLWithPath: filepath) { let exist = NSFileManager.defaultManager().fileExistsAtPath(String(url)) if exist{ do { try url.setResourceValues(["YES" : "NSURLIsExcludedFromBackupKey"]) return true } catch let error as NSError { print("\(error)") return false } } else { print("File does not exist") return false } } else { print("Path not recognized") return false } }
If you think that rejecting your application is false, write a review group and explain the situation and your storage usage
Simple recommendations
Bandwidth, network availability and storage are limited resources and have real financial implications for your users. When you design your circuit, only store information in iCloud that cannot be recreated.
Core Data applications that support iCloud not only know the data created on the device, they know the data on other devices. It is a good idea to consider this fact when developing the Core Data stack.
When you save the managed entity context, Core Data creates a set of transaction changes in the ubiquity container that are guaranteed to be applied together on other peers. The size of this set of transactions and the frequency with which you save your context directly affect the performance of your application.
Resources
IOS Storage Guide - Apple Developer
ICloud Programming Guide for Master Data
File System Programming Guide