iOS 8 wasn't kind to users of 8GB and 16GB iPhones and iPads. Its over-the-air updates required multiple gigabytes of free space, and installing it reduced the amount of free space available on your device. It brought with it the iPhone 6 Plus, which introduced a new "3x" asset size that made apps even larger than they already were. Luckily, iOS 9 should help.
Apple already talked in the keynote about how it had reduced the amount of space required by the iOS 9 OTA update from around 4.6GB to 1.3GB, but a more transformative technology only got a passing mention: App Thinning. In short, apps in iOS 9 will leave your phone or tablet with more free space in the first place.
There are three different mechanisms that developers can use to make these apps smaller. The first, App Slicing, is the most significant. Each iOS app binary you download contains a whole bunch of code for a whole bunch of devices—assuming it's an up-to-date, universal iOS app that supports the iPhone 6 Plus and runs on 32-bit and 64-bit devices, the app contains assets for literally every supported iOS device whether your device needs all that code or not.
Say you have an iPhone 5C, which uses a 32-bit CPU and a GPU that doesn't support the Metal API. Download a modern universal game, and that binary includes 64-bit code, iPad and "3x" iPhone 6 Plus assets, and Metal API code that it doesn't need. It only needs the 32-bit code, "2x" iPhone-sized assets, and the OpenGL graphics code. App Slices will let your device download just the chunks your device needs.
It's important to note that this shouldn't require a ton of additional work from developers—all they need to do, according to the documentation, is put artwork in an Asset Catalog and tag it for individual platforms. Devs will still upload complete versions of their apps to the App Store just as they do now, and the App Store does the work of compiling and delivering device-specific versions of those apps (more on that later).
The second feature is a bit more complicated. On-Demand Resources (ODRs) are chunks of apps that are only downloaded when they're needed and are cleared from your device when you're done with them. Apple has lots of details about the implementation of ODRs on its developer site, but the basic pitch is that you don't need to be using all the assets in your app at any one time.
For example, in a game with multiple levels, Apple suggests that your app only really needs to have the data for the level you're on and the levels immediately following it, not necessarily levels you've already beaten. For an app with a tutorial, it might download the assets for that tutorial the first time you use it but delete them from your device after it's clear that you're not going to need the tutorial again. An app with in-app purchases could decline to download those assets until you actually make the purchases.
While coding their apps, developers who want to use ODRs will have to assign tags to different chunks of code. Apple's example, again a game, suggests tagging assets for individual game levels. That data will be downloaded from the App Store (or from your test Mac, if you're a developer) when it's needed and purged when the OS needs to make space for something else. Developers will be able to specify what code is needed for the app's first-time launch, when the app is done with those assets, and which tags should be deleted first if it needs to make space.
Apple has a full list of what app content can be tagged as an ODR here—images and media files are included, among a few other things—but actual executable code cannot be marked as an ODR.
It all sounds slightly more effort-intensive than App Slicing, but in aggregate it could still save quite a bit of space. It's also not clear what problems this could create for, say, apps that need to grab these assets while your device doesn't have an active Internet connection or whether it will introduce lagging or load times while the app downloads assets.
The final piece of the puzzle is something Apple calls "Bitcode." When developers upload apps to the App Store, they'll no longer be submitting pre-compiled binaries, but an "intermediate representation" of those apps that is compiled on demand depending on the device you're downloading it to. This enables some of the App Slicing functionality—it determines whether your device downloads a 32-bit or 64-bit binary.
Since Apple is compiling the app on-demand, it also implements any compiler improvements that Apple makes without requiring a developer to resubmit their applications. Conceptually, this is not entirely dissimilar from Android's just-in-time (JIT) and ahead-of-time (AOT) Dalvik and ART runtimes, which compiles code for your particular CPU architecture when you run or download the app (respectively).
Using Bitcode is enabled by default but still optional for iOS apps (expect it to become required in the future, though). It is, however, required for native Apple Watch apps.
We're continuing to dig through the developer documentation for iOS 9 and OS X 10.11, and we'll continue covering particularly interesting features ahead of our full reviews in the fall.
reader comments
178