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.
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 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.
I am developing app for studying foreign languages, and I'll need to ship 80000 little audio files in my app.
To reduce the size of my app I decided to ship only part of them in the bundle, on the zip archive, and then un-archive it to documents directory. Then, when iPhone will be in Wi-Fi network, I'll little by little download all the others.
But the problem is that Apple says, that we are not allowed to store big files in the Documents Directory. Flagging files for not backing up works only since 5.0.1
So I see two ways for me:
Ship all the files without zipping them and storing them in the app bundle – but that's too huge.
Ship a zip, un-archive it to the cache directory and then check, if they are (not deleted by system), and download one, if it's removed.
What should I choose or is there any other way for me to work it out?
Zipping audio files isn't a good way. I'm sure that saved space will not play any role.
Best solution is to use AAC encoded audiofiles.
Choose suitable quality between 64-128 kbps. And probably mono.
iPhones 3Gs and higher have hardware support for this codec.
There isn't much point in zipping files in the app bundle if you will just decompress them to the documents directory. When app bundles are delivered to iOS devices from the app store they are zipped up anyway (.ipa file), so unzipping to documents will make your app actually take up much more space on the user's device (once in the app bundle and once in the documents directory).
Automated way:
If you want to download them without using too much documents space you can write a predictive cache which has a maximum allowed size. You can keep track of when each file was last accessed and when you need to download a new file remove the oldest-accessed files until you have enough space. Your app can predict which files are needed next based on progression through the lessons, but even if they access a not-present file you can download it just-in-time and add it to the cache for future re-use.
Manual way:
You could provide a user interface to show the user how much space the different lessons are using and split it into lesson packs. Allow the user to control which packs remain cached and show how much space they use. They can decide when to download new packs as they progress through the lessons and when to remove old ones (if they want to save space). If the user wants to keep the files locally then you should let them, even though it uses lots of documents space.
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.