No doubt you’re aware that bigger is not better for downloads on the App Store, especially if you hit the dreaded 100 MB cellular download limit, but were you aware that even if you haven’t there’s a marked disadvantage to download size increasing? Well, here it’s quantified by way of an actual, real-life experiment:
… we estimate a linear change in install conversion rate below the 100MB cutoff of -0.45 percent install rate per MB. Above the 100MB cutoff, we estimate a linear change in install rate of -0.32 percent per MB. To our best estimate, the gap between the two lines is covered by a 10 percent instantaneous install rate drop across the cellular download limit.
Although Apple says the cellular download limit is 100MB, we found in practice that a 101MB IPA did not trigger the cellular download block. The actual limit was somewhere between 101MB and 123MB, and it varied depending on the exact build.
Increasing the size of our app from 3MB to 99MB reduced installs by 43 percent, and the increase to 150MB reduced installs by 66 percent in total…
Sooo, how do we get our size down? If you’re shipping to iOS 9 and later, there are great options:
- Slicing is the process of creating and delivering variants of the app bundle for different target devices…
- Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the store…
- On-demand resources are resources—such as images and sounds—that you can tag with keywords and request in groups, by tag. The store hosts the resources on Apple servers and manages the downloads for you…
Those are generally pretty straightforward to adopt, although you may have occasion to refer to
But if you’re still shipping for iOS 8, none of those help your iOS 8 users at all. Ah well.
First thing is to make sure you’re stripping debugging symbols and dead code with Xcode build settings. Also, make sure that Xcode isn’t bloating your asset catalog behind your back. The setting for that is “Optimization” aka ASSETCATALOG_COMPILER_OPTIMIZATION — and if you haven’t set anything, apparently it defaults to “time” which undoes all your compression and bloats up wildly besides. So set it to “space” instead.
If you need to dig deeper than that, here’s some useful tools for messing with your binary and asset catalog to figure out just what’s going on:
- Bloaty McBloatface: a size profiler for binaries
- Crunch: “Extract resources from iOS apps. Make iOS icons.”
- cartool: “Export images from OS X / iOS .car CoreUI archives.”
- AssetCatalogTinkerer: “An app that lets you open .car files and browse/extract their images.”
- iOS-Asset-Extractor: “A tool to extract image assets from the iOS SDK.”
- And if you need to go still deeper into smallerizing those graphics, well then you’ll have to go to some work. Possibly useful approaches include:
- Or you could use SVG files as resources — Macaw is a new library that looks particularly good for that.
- TexturePacker is your goto tool for creating sprite sheets, if that suits your resource usage profile.
- ImageAlpha + ImageOptim is an effective strategy for reducing PNG sizes.
- JPEGmini is particularly good at making JPEGs smaller.
- Or, you could go with the generally well regarded WebP image format, supported by iOS-WebP for instance.
Any more tips? Share and enjoy!