Like many developers, my iOS app was just rejected for having downloadable content that was being backed up to iCloud. I've searched for a clear answer to this question but have not been able to get one.
Apple says that you should implement a 'do not backup' attribute to your files, however, they also state (https://developer.apple.com/library/ios/#qa/qa1719/_index.html):
The new "do not back up" attribute will only be used by iOS 5.0.1 or later. On iOS 5.0 and earlier, applications will need to store their data in /Library/Caches to avoid having it backed up. Since this attribute is ignored on older systems, you will need to insure your app complies with the iOS Data Storage Guidelines on all versions of iOS that your application supports.
My app supports iOS 4.0 and later. Does this mean if I want to maintain support for iOS 4.0-5.0, I have no choice but to put all my content into the Caches folder? Or, can I just add the 'do not backup' attribute and keep the files in /Documents? If I have to keep the content in the Caches folder, can I prevent these files from being purged in low storage situations? Finally, are there any developers who have put files in the Caches folder and know how often they do get purged?
Any advice or help would be greatly appreciated. Thanks a lot!
The concern area is the iOS 5.0, which supports iCloud, but does not recognizes “do not backup” attribute. In this case, all the data of the app inside documents directory is likely to get backed up to iCloud. For the iOS versions below 5.x:
the iCloud backup is not valid.
the "do not back up" flag is not relevent. It would not produce any warnings during compilation.
Hence the data can be kept in the documents directory, with "do not back up" flag appropiately added to the contents (files/folders), for all the versions. The problem is for the version 5.0 only.
i think you can find similar question like this :
What is suitable location for creating sqlite file?
and as per my thinking it is better to store files in library with new directory rather than document directory..
No it's wrong that tou say. I've solved your same problem in that way. I saved my database and directory images in directory Documents/.. flagons those As do not backup as suggest by Apple. In that way for devices that are updated to 5.x or more that files are not backup to iCloud; for others there are no changes because there are no support to iCloud.
This is a best practice because files that are not concerning user we do not backup in iCloud. All other files that you don't want to redownload must be saved in Documents flagging it as do not backup. If you save it in Caches folder those are deleted in a short time when you close the app and must be redownloded when you open it again.
Related
There're 2 folders in ~/Library/Caches in our iOS APP:
com.crashlytics.data
io.fabric.sdk.ios.data
It seems that they're used by Fabric?
I want to add a feature to delete all contents in the Caches folder, and I'm wondering if it's safe to delete these 2 folders?
If I delete the 2 folders when APP is running, what will happen if there're crashes in APP? Will the crash reports still be sent to Fabric?
Any advice would be appreciated.
Todd from Fabric here. It is not safe to delete these programmatically as they contain our crash report data. The folder Library/Caches/com.crashlytics.data/ is where crashes are uploaded from when your app relaunches. Thanks!
As per Apple Docs:
Put data cache files in the Library/Caches/ directory. Cache data can be used for any data that needs to persist longer than temporary data, but not as long as a support file. Generally speaking, the application does not require cache data to operate properly, but it can use cache data to improve performance. Examples of cache data include (but are not limited to) database cache files and transient, downloadable content. Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed. (c)
So it means, that these folders can be removed even without any additional features in you app. Feel free to do it by yourself.
In my iOS app I am downloading a bunch of image files and saving them on disk in Library/Caches. Do I need to delete those files given iOS automatically clears them when its running low on disk space.
It depends where you save them. Read the File System Programming Guide for detailed discussion.
In Summary, If you are saving the files to:
Temp: You don't need to worry about cleanup, but you need to be aware that these files will not persist between app launches
Library/Caches Generally iOS won't delete these files but can clear them when running on low disk space. So developer has to make sure these files can be regenerated when required.
All other folders yes, you need to make sure the files are properly cleaned up when they are no longer needed.
UPDATE: Now that you have specified that you are saving to Library/Caches, From Apple Docs about Caches directory:
Use this directory to write any app-specific support files that your app can re-create easily. Your app is generally responsible for managing the contents of this directory and for adding and deleting files as needed.
In iOS 2.2 and later, the contents of this directory are not backed up by iTunes. In addition, iTunes removes files in this directory during a full restoration of the device.
On iOS 5.0 and later, the system may delete the Caches directory on rare occasions when the system is very low on disk space. This will never occur while an app is running. However, you should be aware that iTunes restore is not necessarily the only condition under which the Caches directory can be erased.
To be specific Your app is generally responsible ... for adding and deleting files as needed., You should always clean up after yourself. If you know you are done with the files, keeping them on disk and waiting for the device to run on low disk space so that the OS deletes them is a bad idea.
btw, if you are downloading files from the internet, why don't you use an already build library (so that you don't have to worry about these things).
If you are developing for iOS 8.0+ and using Swift, you could use AlamofireImage as an embedded framework. It comes with a very good caching system. I think you can use it on iOS 7 as well by copying the Swift files.
If you are using Objective C, you could use SDWebImage which comes with its own caching system. You could also use AFNetworking and enable basic caching, this blog post should get you started.
I want to know what iOS can do with my app data when the disk free space become very low. Can iOS delete some files to free disk space?
It depends on what you are doing. To be a good citizen, you should do the following:
Any files that you can reproduce yourself should be marked as "don't backup". That saves lots of traffic to the cloud when there is no need to backup a file that you can just download again when needed.
Any files that you can afford to lose at any time should be in the temporary directory. These files will be deleted automatically (but you should not wait for them to be deleted automatically) at certain times and when the phone runs out of space.
Any files that you can reproduce should be in a "cache" directory to allow iOS to delete them.
The user can always delete all the files belonging to your application. Much better to mark anything that can be restored as "cached" so only what is essential is displayed in Settings as belonging to your app, and the user isn't tempted to throw it away.
It wont delete it, although it can delete your caches in Library/Caches. You need to conform to specs detailed in the link above, as your app might be rejected if you'll store something not where it should be (for example some caches in Documents).
NO , iOS will not delete some files or data in your app. iOS will not delete user data automatically.
I got my app rejected due to violation of 2.23
After inspection, it would appear that I was indeed not a correct path for storing downloaded images and data files (i.e. files that I would prefer to have available for offline usage, but which the app can re-download again if removed by iOS)
However, after looking at:
https://developer.apple.com/library/ios/qa/qa1719/_index.html
It appears it may not even be enough to proper "cache" path for iOS > 5? Example:
/var/mobile/Applications/00000000-0000-0000-0000-000000000000/Library/Caches/'
Will using above make my app pass this requirement? Or am I forced to using the API for making files not to be backed-up?
Using the caches directory is correct if you can re-download the files. They will not be backed up. You only need to use the "do not backup" flag if the files exist in a location that normally is backed up (e.g. the documents directory).
I created magazine reader app that uses png images as pages. When user downloads magazine, all png images are downloaded and stored in Caches folder.
Problem with Caches is that files in there can be apparently deleted anytime. Since app is designed to be used in offline mode as well, re-downloading of missing pages is impossible.
I tried to save it into Documents folder but my app got rejected, this apparently is not proper place for them.
So my question is, where can I put them to make that iOS won't delete them? I don't need them to be backed up to itunes or synced or anything like that, I just need them to stay there until I remove them.
I tried looking into the documentation but I could not find a category that would fit my needs, am I missing something trivial?
EDIT: I need to support iOS 4 as well
http://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html
Put it in the Libary Folder
Handle support files
—files your application downloads or generates and can recreate as needed—in one of two ways:
In iOS 5.0 and earlier, put support files in the /Library/Caches directory to prevent them from being backed up
In iOS 5.0.1 and later, put support files in the /Library/Application Support directory and apply the com.apple.MobileBackup extended attribute to them. This attribute prevents the files from being backed up to iTunes or iCloud. If you have a large number of support files, you may store them in a custom subdirectory and apply the extended attribute to just the directory.
Apple has a tech note that addresses this at http://developer.apple.com/library/ios/#qa/qa1719/_index.html
It shows sample code for setting a no-backup attribute on files.