This is a great win for developers. One of the worst things that can happen to us as developers is to miss out on sales because the user wasn’t connected to WIFI to download our app. Now, Apple is helping eliminate these types of problems using a concept they are calling “App Thinning”.
With App Thinning, users will only download parts of the binary that are relevant to the user. For instance, if the user has an iPhone 6+, the download won’t download the @1x or @2x images since they will not be used and only download the @3x images.
App Thinning has three main components:
- App Slicing: This is the process of only downloading what’s needed. So App Slicing will allow your device to download only those files required by our device. Example: you don’t need the 3x iPhone 6 Plus assets if you’re running a 4-inch model.
- On Demand Resources (ODR): Resources hosted by the App Store that can accessed after the user has downloaded the app. For instance, new levels in a game via in app purchase. It works on the idea that an App probably doesn’t need its entire library of resources at any given time, so parts of it can be downloaded or deleted as needed. Developers will be able to specify what code is needed at what times by tagging sections of code as ODRs. These portions will be automatically downloaded from the App Store when they are required and deleted when they won’t be needed again.
- Bitcode: Allows Apple to re-optimize the app’s binary in the future without having to submit a new version. It refers to an “intermediate representation” of an app that developers will upload to the App Store rather than a pre-compiled binary. This works hand-in-hand with App Slicing, allowing the bitcode to be compiled on demand as 32-bit or 64-bit, depending on the downloading device. This will also allow any compiler improvements made by Apple to be implemented automatically, rather than having developers resubmit their apps.
Perhaps the best part about App Thinning is that two of it’s components are practically done, App Slicing and Bitcode. I personally think it’s a fantastic idea, as developers have been doing this independently for a long time.
To use, tag resources in the app with keywords. Then these resources can be downloaded at a later time by using those tags. Even better, this can be debugged in Xcode. Using the new
NSBundleResourceRequest class, call
beginAccessingResourcesWithCompletionHandler(_:) to access the requested resources.
What is BitCode in ios
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 App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store.
When you archive for submission to the App Store, Xcode will compile your app into an intermediate representation. The App Store will then compile the bitcode down into the 64 or 32 bit executables as necessary.
For iOS apps, bitcode is the default, but optional. If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode. For watchOS apps, bitcode is required.
So, basically if I talk of ENABLE_BITCODE which is introduced in iOS 9, is a part of App Thinning process.
And it is a part of problem which answers “How did Apple manage to reduce the storage size of iOS 9 to 1GB from 5 GB in iOS 8?”
This is due to a new technology called ‘App Thinning’
& what exactly is App Thinning ?
App Thinning brings down the iOS 9 OTA(Over-The-Air) update from 4.6GB to 1.3GB, a 71% size reduction. Not only will this help with future OTA updates, but the technology will be available for developers to reduce the storage required by third party apps.