I have an application that is currently in the App Store.
It has approximately 500mb of data that it needs in order to run.
I was fighting and fighting various methods to install this data after the app was downloaded, including AFNetworking and WhiteRaccoon, to no avail... the deadline was coming fast, so I decided to just ahem bundle the content into the App Bundle, and worry about it later. This meant the size of the app dictated that people downloaded it while on WiFi, but ... whatever.
Now, I have discovered NSURLSession, much to my delight, and it does everything that I need that I couldn't make the others do (see my answer to this question).
So... I am ready to push a new update to the App Store, and my Archive size has been reduced from 491.2mb to 32.2mb (!!?woohoo?!!).
I am curious how Apple manages this. I have read this document that mentions techniques that they use to keep the app bundle size down by detecting what hasn't changed, but it doesn't explicitly mention anything about the scenario that I am facing.
Now, if 460mb or so of obsolete bundle/code is going to be stored in the user's device, I'd like to be able to recommend to them that they delete the app entirely and reinstall... but I am curious if I/they need to do this, or does anyone know how Apple will handle this scenario ?
Thanks.
That document you reference, Technical Q&A QA1779: Reducing Download Size for iOS App Updates, covers what Apple does to optimize the size of the app update. But the net effect is the same as if the app bundle on the user's device was entirely replaced. As that document says:
In addition to new content, the update package contains instructions on how to transform the prior version of the app into the new version of the app. New files will be added, modified files will be replaced with their updated counterpart, and deleted files will be removed as part of this transformation. As far as the developer and user are concerned, this process is entirely transparent and the resulting updated app will be indistinguishable from a full download of the corresponding updated version of their app.
So, no, you don't have to tell users to delete the old app unless there's anything in persistent storage (Documents, NSUserDefaults, etc.), that need to be reset. And you should probably handle that programmatically, anyway.
Related
I have an app that stores documents in iCloud. iOS seems to regularly purge the local copies of the ubiquitous documents, forcing my users to re-download from iCloud. I had assumed this was due to low storage on the devices but I’ve experienced it myself when my device has more than 3GB of free space.
I also see the same behaviour in the Apple Books app. On the other hand in the Apple TV app on the same device, purchased movies I download don’t ever seem to be automatically purged. This has been the case for me since around the launch of iOS 13, but some of my users have complained of the issue on earlier iOS versions.
Is there a flag I’m missing somewhere that would prevent iOS from purging my documents? The biggest these files get is around 5MB.
Edit based on following Warren Burton's link: After reading the document at https://developer.apple.com/icloud/documentation/data-storage/ , I'm wondering if what I'm looking for is the "do not back up" attribute. I'd previously interpreted this as meaning that if a user reinstalled from a backup, all my app's documents would be lost. But if documents are stored in iCloud, I suppose they would still be available in the same way after a backup is restored, so they don't actually need to be in the user's backup? To further add to my confusion, the docs at https://developer.apple.com/documentation/foundation/urlresourcekey/1408756-isexcludedfrombackupkey specifically say not to use this attribute on user documents, so maybe this isn't the right attribute. Can anyone clarify?
I’ve come to the conclusion that there’s no way to get the behaviour I want by just relying on the iCloud file management itself.
What I’m going to attempt to do is to copy files manually from the ubiquity container to the local documents and work with them there, saving back to the ubiquity container as necessary. It seems a bit inelegant but should get the experience I want.
When submitting an update to an app to the app store (via iTunes Connect?), is the update necessarily a whole binary? Can an update come in the form of a patch? If a second version of an app shares a lot of assets and logic from the previous version, does all that logic/resources get reinstalled wholly regardless?
There are no patches. It's installed as an entire read-only bundle. The old bundle is replaced with the new bundle.
Application data is retained (ie. documents folder, NSUserDefaults).
As everyone said before me Apple does not supply a way to hot-patch native apps, moreover it has a clear restriction - "No remote code injection".
The only thing I can add is that hybrid apps which use a javascript platform allow you to remotely replace the JS file, so you can actually change functionality remotely.(without having to release a new version) other solutions I have seen are in the gray area and allow you to run Lua Script remotely to change app functionality.
We # Rollout.io have a different approach, we allow you to hot-patch production apps without code injection on native applications, you can read more on how the tech works here
Rollout is meant to help mobile developers solve production quality issues, hot-patching production apps, debugging production env, adding/removing analytics, etc.
Disclosure: I'm from the Rollout.io team.
iOS 6 now supports delta app updates. This is awesome, and makes Real Racing 3 (a 1.1GB app) update in about 30 seconds instead of 20 minutes!
https://developer.apple.com/library/ios/#qa/qa1779/_index.html
Q: How can I reduce the downloaded size of my app update for users
that already have the previous version installed?
A: Starting with iOS 6, the app store will automatically produce an
update package for all new versions of apps submitted to the store.
This package is optimized for updating an app from one version to
another, and contains files that have changed between the prior
version of an app and the new version of the app, excluding files that
have not changed.
When used optimally, an update package is significantly smaller to
download than the full package of the app and the update will install
more quickly. Also, in many cases, this mechanism allows updates to
large apps to be downloadable over cellular networks where app
downloads are subject to a size limit.
In addition to new content, the update package contains instructions
on how to transform the prior version of the app into the new version
of the app. New files will be added, modified files will be replaced
with their updated counterpart, and deleted files will be removed as
part of this transformation. As far as the developer and user are
concerned, this process is entirely transparent and the resulting
updated app will be indistinguishable from a full download of the
corresponding updated version of their app.
Further instructions for developers available at the link above.
My application that will be posted soon is going to dynamically download images and resources that have to do with art when something is unlocked in the app. This will keep down on app size and the app will only download resources when it is needed. Very similarly to Droid development since they cap at 50mb sizes.
Does anyone know if this could potentially harm the approval process to apple? The expansions that will be downloaded could be around 30mb and could be very slow if the user decides to do this on data. Any advice or prior issues with apple on some type of process like this would be very helpful.
Thanks in advance.
You should be good. I have an app that downloads every new XKCD webcomic when it is released. Each being an image, this has added considerable size to the app.
To play it safe, I would suggest including something in the app description (within the app and on the iTunes store) that tells users the app dynamically downloads content. There is no rule against it, but letting the user know is always good.
Today while investigating how/where to download and save audio/image files from a URL in a project I am working on, I stumbled upon a potential app rejection possibility if we save large audio/image files in the documents directory in iOS.
The issue here is related to 'iOS Data Storage Guidelines' published over here https://developer.apple.com/icloud/documentation/data-storage/
- "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."
On further reading, I found that many people had their apps rejected because of storing too much data in the documents directory (since a user has a limited amount of 5GB in his iCloud account) and the documents directory for all apps on a users device is automatically backed up to iCloud.
An option given to developers is to store data in the '/Library/Caches' directory. However data present in caches directory can be deleted anytime the OS is low on memory and there is no guarantee that the data will be present always which is not an acceptable solution to our project since we cannot expect our app's user base to download large files more than once.
The solution which I found according to this link http://developer.apple.com/library/ios/#qa/qa1719/_index.html#//apple_ref/doc/uid/DTS40011342 is to specifically mark the files you store in Documents directory for not being backed up and the process is described therein.
However, it is only applicable from iOS 5.0.1 onwards. It is not possible to exclude data from backups on iOS 5.0 and below.
So, my question over here is:
'Since the project I am working on has a sufficiently large number of images/audio to be stored and re-downloading them is not an option , would it be advisable to support installations only on iOS 5.0.1 and above because of the above mentioned issue or keep backward compatibility with iOS 4.3 and investigate other ways to store the data without the app being rejected? Approximately what percentage of users do we stand to lose if we go with the former approach? Are there any statistics for the same?'
Please let me know your thoughts on this
Several things:
iOS 5 is more than 80%, possibly more than 90%. (The site I watch has had a surge in iOS 4 % recently, but I believe that's being caused by not counting iOS 6 devices.)
You should explain the nature of your data a bit more. If your data is difficult enough to download, it may qualify for backing up anyway. (This happened to my app.)
The users who are still running iOS 4 are less likely to download your app anyway, unless you have an existing iOS 4 installed base.
iOS 4 support is going to cause you more and more pain and suffering.
References:
http://www.game4mob.com/index.php/tech-articles/67-ios-5-penetration-percentage
http://tewha.net/2012/06/dont-write-new-apps-that-target-ios-4/
Prior to iOS 5 the /Library/Caches directory isn't cleared by iOS. The Do Not Backup feature was added to iOS 5.0.1 because the new cache clearing in 5.0 broke a lot of apps, such as instapaper - see Marco Arment's blog post on this issue: http://www.marco.org/2011/10/13/ios5-caches-cleaning
Maybe you can use /Library/Caches for those users below ios 5.0.1 and move over to using the Do Not Backup marker after they upgrade.
In response to Apple's changes in iOS data storage guidelines I recently reconfigured an iPad app to store its documents (50MB+) in the library/caches folder.
During testing in the iOS simulator I didn't see any problems with this cache when I simulated an update (following Brad Larsson's suggestion). I also tried deleting all of the contents of the library/caches folder to make sure that my app could recover.
However, when I released the app upgrade I found that my users complained of problems that were traced back to the iPad partially deleting this cache. It seemed like sub-folder structure was at least partially left intact, but sub-folder contents were deleted.
I've redesigned the app to deal with this situation during an upgrade, but I'm worried about what will happen when the iPad decides to clear the library/caches.
Does anyone have any experience or insight into the time when the iPad would try and delete items in this cache?
Thanks
There is no 100% clear answer to this question, because Apples iOS Data Storage Guidelines are very vague … They don't explain in which cases iOS 5 will delete data inside the cache dir …
In most cases iOS starts to kill files when it's getting low on disc space, but sometimes my app lost data for no good reason. So I had do implement some kind of recovery modus to redownload/-generate files the app needs.
This article is interesting: http://iphoneincubator.com/blog/data-management/local-file-storage-in-ios-5
The documentation states the following:
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.
The part about it never occuring while the app is running is crucial for our app, and is a really good insurance that we won't get unexpected behaviour.