Recently, I have came across many apps which "Clear Cache" on iPhone. They also specify that you may lose some saved data and temp files.
What I know is that Apple doesn't allows you to access data of other Apps neither directory. So, how they are cleaning cache data? Can anyone put some light on it?
Reference: Magic Phone Cleaner
Power Clean
They simply fill the free space on iPhone temporarily with random data leaving the system with no free space at all.
This forces iOS to clear all temp data, caches and iCloud Photos -if you enabled storage optimization- to clear space. So basically they are tricking the system to force it to clear temp and cached data.
No app can access anything outside of it's sandbox environment. In other words, technically it's impossible to clean cache on an iPhone unless it's jailbroken. Most of these apps doesn't do what they say, they just give an illusion to user. Loading up the memory can force iOS to terminate other apps in the background but, I it's unlikely that it will give any performance boost.
It doesn't clear data in external apps, it clears external data left by apps. Clearing the cache basically deletes all the temporary files.
Related
The Situation
I have an app that stores a core data database in the documents directory. It seems to work well for the most part, except for the fact a few users (of a very large number) are complaining their data just 'disappeared'.
It's a carefully/well coded app, no weird errors or crashes coming from Core Data.
My Suspicion
iOS sometimes shows the word 'cleaning' beneath app icons when storage space is low. This cleans some directories to free up space.
Help!
Could this be the cause? If so, how can I stop this? Any light that can be shed on this would be much appreciated.
The documents directory is the recommended place to store a core data database and iOS will never "clean up" anything stored there.
Users can manually delete files in the Documents directory, by uninstalling the app or (if you've enabled it in info.plist) browsing their phone from in iTunes.
Most users do not expect their data to be destroyed when they uninstall an app (Macs and PCs would leave the data in place for example), so this is probably what's happening.
You should consider storing a second copy of the data on your server, or on the user's iCloud account. That way it won't be destroyed by an uninstall. If it's your server, then you can justify charging money for this feature (recurring revenue is good right?).
Backups to iTunes and iCloud will both include your database, so you can instruct users to restore to a recent backup to get their data back.
Also double check your code to see how it handles an out of disk space error when attempting to save changes to the database. Depending how you're using Core Data, this could go bad.
These days Core Data in iCloud or some other cloud solution is the best approach.
My app downloads data from the internet and then stores it somewhere on the device, so when the user has no internet connection the data will still be available. I know about the cache folder, but according to Apple this directory will be removed if the device runs out of disk space. This is really a problem for my app, since this might break the app for users with low disk space and a bad internet connection.
My question: Where do I save those files without the risk of them being deleted by the system due to low disk space or whatever. I can't place it in the documents directory because Apple will reject my application.
I have tried storing it in the documents folder, and then using the following line of code to disable iCloud backups.
try? NSURL.fileURLWithPath(self.path).setResourceValue(true, forKey: NSURLIsExcludedFromBackupKey)
But that doesn't work at all, it returns "()".
From the doc:
HANDLING ERRORS IN SWIFT: In Swift, this method returns Void and is
marked with the throws keyword to indicate that it throws an error in
cases of failure.
So () is the expected result. The real test of "working" is whether the file contents are retrievable and whether they don't synch to the cloud.
As an aside, I like better your original idea to use the NSCaches directory. It is exactly for content that can be regained with a fetch, but too expensive to fetch all the time. And having it emptied to keep the device running well sounds like exactly the right behavior.
The requirement that you've given yourself to deliver rich content, have a low memory impact on the device and work well with little or no network is a commendably high bar... too high in my opinion, compared to anyone else.
It seems to me reasonable to detect a no cache, low memory, disconnected situation and just apologize to the user. Tell them its their fault.
We're using Parse in our iOS app and we've discovered that our app is using an enormous amount of space -around 2.3GB in some devices- in storage. After downloading app data to my Mac, I've realized almost all of that data is the cached images in a folder called PFFileStaging, it contains highest resolution PNGs of all the PFFiles that the user has viewed in our app, ever. How can we disable this behavior, at least limit it? Is that the intended behavior? I heavily doubt using GBs of space is the intended behavior. Is this a bug?
Unfortunately this is not cache related (as per Parse's engineers: "this is used to ensure that no concurrent modification happens to the file after you request uploading").
They're planning to implement automatic trimming of PFFileStaging folder on every app start (as per road plan this should appear in next version 1.8.2).
See the the whole thread on GitHub.
I am developing an application where the user will not have WiFi and needs to save their data until they have WiFi and then upload their data. Is there any temporary uploading programs I could use?
Why not use the localStorage? It's becoming more reliable. I've used it in my own applications and the API is easy enough to pick up.
When using it with the iPad TumbleCow has one or two things to keep in mind.
Yes, the storage-limit is still 5Mb. Since characters are stored UTF16, only 2.5M characters can be stored in localStorage.
In contrast to other localStorage implementations, localStorage.setItem() doesn't delete any previous items with the same key before storing the new item. In other words: When overwriting an item, one should always call localStorage.removeItem() before calling localStorage.setItem(), or you'll quickly run out of space.
Is localStorage reliable on an iPad?
Apple's data storage guidelines state the following:
2) Data that can be downloaded again or regenerated should be stored
in the /Library/Caches directory.
...and (emphasis mine):
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.
The page that Apple links to with a more detailed discussion of this topic does not mention anything about the attribute doing anything to prevent cached data from being purged.
So does anyone know if the "do not back up" attribute actually works like "do not backup and do not delete" for items placed in /Library/Caches, or if files still need to be stored inside of the application's Documents directory to ensure that they are not deleted when the device is running low on space?
I've made a quick test on iPhone 5 iOS 7.1.1:
I put some files to “/Library/Caches” (NSCachesDirectory) and mark them with NSURLIsExcludedFromBackupKey attribute. Then I put some more big files to the same directory in a normal way.
I then made a low disk space warning by taking a long video with the camera app.
After the warning, files marked with “do not backup” was not deleted from Cache, but the other files was! So, this attribute is really working and made two different things in spite of its name – excludes from backup and preserves from being purged on low space warning.
To me this is very clear, and the directory structure is the one I would follow first, just as Apple says. If you both want to save the file and not back it up, put it in Documents, preferably in a folder that you mark.
Even if you observe some behavior today using Caches, it may change in the future.
Currently researching this same question and also made the assumption that adding that attribute will prevent a file from being purged in a low disk space scenario (You know, because apple's documentation literally says that). I thought I would update this with my findings since it has been a few years since the accepted answer. I have a database that can be recreated and contains no user generated data, so I store it in caches, but contains some data that can affect the proper functioning of the application, so I don't want it to be purged when running out of disk space (currently happening and logged as a bug). I have experimented with adding the NSURLIsExcludedFromBackupKey to the file itself and file is still being removed after purge happens. So it does not seem to prevent purge as of iOS 11.3. Not sure what the next move is as I really don't want to move the database for all our users, but that's probably the next step so it will be safe in Documents. Please correct me if someone has a different experience.