iOS App size analysis

One of the most crucial pain points especially in building an enterprise mobile application is to constraint the app size well below the size limit. And by size limit, I mean the cellular download size limit(i.e. 200 MB) by Apple. Although this is just a warning after iOS 11 was launched, however keeping the app size slimmer increases user retention.

App Download Size limit warning

Now as your app grows in terms of features you offer because you’re always required to cater to your product needs, It’s sometimes difficult to make your app below the expected size limit. Doing an app size analysis is not only important but equally critical as Apple has stopped providing the App download size per device break-up information since February 2017 on iTunes Connect. You would only get the App install size per device break-up information and a warning denoting if one or more of your binaries(marked in bold) is/are above the eligible download size limit.

App install size information of an app uploaded on iTunes Connect

You must always remember, your customers might not have access to WiFi always. And so downloading over the cellular network is the worst-case analysis that should be considered foremost. This is a concern and is not only important while you’re designing your app but also when you distribute your app on the AppStore.

So what should you do?

Well, there’re a few best practices that you should follow to make sure you tighten your App’s waistline.

1. Deployment Target: Change this to 9 if you’re still supporting the older versions. As of June 5, 2017, 97% of the Users are using iOS 9 and up… So I believe there’s no good reason to still support the older iOS versions. And this is because Sliced apps are supported on devices running 9.0 and later; otherwise, the store delivers universal apps to customers. And if you’re thinking what sliced apps are: So they are just the individual IPA(s) that are part of the Universal IPA that supports a non-simulator iOS architecture viz. arm64, armv7 or armv7s. These are the processor architectures of your iPhone/iPad.
2. File changes: Do not make unnecessary modifications to the files. Compare the contents of the prior and new versions of your app with diff or another directory comparison tool and verify that you've only changed what you expect within your app bundle.
3. Content changes: Content that you expect to change in an update should be stored in separate files from content that you don’t expect to change. This reduces the size of the update package and increases its install speed.
4. Remove unnecessary resources: You may reduce the size of a resource by a lot, but after producing an .ipa file, you may discover the compressed size of that resource has not changed as dramatically. The most effective technique for reducing the size of an .ipa file is to remove unnecessary resources.
5. On-Demand Resources: On-demand resources are just the app contents(any kind of resources) that are hosted on the App Store and are separate from the related app bundle that the user downloads from the AppStore initially. On-Demand resource also has sizes limits per platform on the AppStore and that can be found as below:

On-Demand size limit and slicing eligibility on AppStore

On-Demand resources are specifically important if you’re building a game because a game will have multiple levels and it makes more sense not to ship the resources(that will be required for the higher levels of the game) along with the IPA itself and make it bulky. This technique is analogous to having the app resources on the App server itself. If you’re shipping a preloaded DB with your App, make sure it has the minimum or rather important data that you think your Customer should have access to when he installs the app and has no Internet connectivity(again the worst-case analysis).

6. Asset Catalog: Asset Catalog organizes resources according to the relevant device traits viz. screen-size, screen-resolution, graphic capabilities(from iOS 9 Onwards), and memory level(from iOS 9 Onwards). Use of asset catalogs means Use of 1x, 2x, and 3x — image sets and data sets. One important thing to note is: App Slicing will not be performed on loose resources. It must be a part of the Asset Catalog. Content.json in the Asset Catalog contains all the markup information for slicing the app resources based on the device traits.

7. iOS 9 APIs: has a new class: NamedData to thin any file not necessarily from Asset Catalog. It stores arbitrary file content. Classify according to the hardware capabilities. Use NSDataAsset class to retrieve content in the application.

8. Framework(s) sizes: You should always ensure that the Frameworks you’re using in your app are being created following the best practices as well. And while releasing a new version of your app or even releasing a new app altogether you should always unwrap the IPA file and check how much does the frameworks contribute to the actual size of the app. The download size is actually the worst-case scenario and is applicable only for first time users. For the existing Users, this doesn’t apply as they would always be required to download only the update package from the AppStore for every new release of the App, and the size of the update package will be much smaller than the download size of the app.

9. Use common asset catalogs: If your app uses multiple components, it’s very likely that they might have some or more of the assets in common. It is then very important to keep all the common assets in a shared area(asset catalogs), thereby not duplicating in multiple frameworks hence reducing the overall size.

10. Remove unnecessary code: This is similar to #4 with the difference that this is applicable to the source files, with a proper design and refactoring this is achievable. Removing the unwanted code will help you with reducing the size of the Unix executable file, thereby decreasing the overall size of the application.

Additional Pointers

• The AppStore IPA size is always larger than the estimated IPA size because of the inclusion of the .dSYM file for crash reporting and On-Demand resources.
• The App size reduction analysis should only be performed on the thinned IPA and not on the Universal IPA.
• App Thinning Size Report gives information about the thinned IPA size and its characteristics. See an example below:

An App Thinning report for iPhone 6s Plus

Now, this is the data of your interest. If you see in the App Thinning Size Report above, the App size has two values: compressed and uncompressed; the former denotes the App OTA(Over The Air) download* size for a fresh install from the AppStore whereas the latter denotes the App install size on the device, now this also varies based on the device and hence Users will see different sizes of the App while downloading the app from the AppStore. iTunes Connect will provide you the install size per device break-up information as I showed in an excerpt before.

(*)A very important point to note here is the compressed size shown above is always smaller than the actual download size of the App as on the AppStore. And this is because the AppStore performs encryption on the app binary thereby increasing the overall size of the App. The encryption does not change the size of the binary, but the encrypted binary will have different compression characteristics, resulting in .ipa files from the App Store being larger than the size listed in the App Thinning Size Report. The size change is not unique to App Store’s encryption algorithm but is instead one of the normal consequences of any strong encryption algorithm. By design, strong encryption algorithms produce output that cannot be efficiently compressed.

Conclusion

The three main components of App Thinning are Slicing, Bitcode, and On-Demand resources. And carefully examining each of these can help you keep your app slim.

In addition, this also requires you to take better architecture and design decisions for your app, which will give your several benefits viz. better code maintenance, code reuse, code modularity, scalability, and all these will lead you to gain: Happy Customers!