In part 4 of my “Making Apple TV Apps” series, we dive into the restrictions Apple has placed on tvOS app size and local data storage.
Does This App Make Me Look Fat?
Apple first introduced the concept of app thinning, or ways to reduce app sizes without eliminating functionality, in iOS 9. App thinning consists of app slicing, on demand resources, and bitcode. Apple declared support for these new features as being optional in iOS 9. However, bitcode is required for tvOS, and on demand resources might as well be. I will explain why later in this article, but first I’ll describe the app thinning processes.
App Slicing
App slicing splits your app into versions needed by different devices based on their display resolution and processor architecture. App slicing is handled automatically by the App Store when you submit your app, making it an easy win.
Since the new Apple TV is the first model to support tvOS, app slicing isn’t needed for this platform, at least not yet. When UHD 4K video support is made available, image assets will be needed in both 1x (1080P) and 2x (4K) sizes.
On Demand Resources
On-demand resources allow us to break up our app’s assets into smaller pieces that can be retrieved from Apple’s servers as they’re needed. One example of this would be dividing a game’s assets up on a “per level” basis.
On demand resources only apply to data and assets. Your app’s executable code must be completely contained in the app bundle.
The first step in setting up on-demand resources is assigning one or more tags to them. These tags are just string labels, and you can assign tags in whatever way you think makes the most sense, but keep in mind that you’ll be requesting access to resources by the tags when you need them. Likewise, you also release resources via tags, which makes all resources associated with a given tag eligible for local deletion if the OS need to free up space.
Xcode takes care of gathering and bundling your resources together into optimized asset packs. It will create up to 1,000 asset packs per app. When you request resources by tags, the OS is responsible for insuring all the assets tagged with that label are retrieved and made available locally.
You can also specify preservation priorities for tagged resources. While there are no guarantees as to what resources the operating system will keep around, it is generally understood that the OS won’t delete resources unless the device is running out of space. At that point, your app’s assets will be considered for deletion based on a combination of how often (or recently) your app is being used and the preservation priorities that you’ve assigned to them.
Apple recommends that you keep each tagged resource’s size limited to 64 megabytes or less. Doing so will provide the OS with more fine-grained control when resources need to be deleted to free up space. This is just a recommendation though, as Apple allows a resource to be as large as 512 megabytes.
An app is allowed to have up to 2 gigabytes of on demand resources available to it at any given time, and up to 20 gigabytes of on demand resources in total. Keep in mind that you will have to submit all of your on demand resources as part of your submission to the App Store.
Bitcode
Bitcode takes the app slicing process down to the binary level. In the past, when our app’s source code was compiled into an executable, optimizations for all the target processors were injected into the output by the Xcode LLVM compiler. While these additions are smaller than differently-sized graphical assets, they still add up.
Apple is addressing this issue and others by shifting the final compilation of our app from our local development systems to Apple’s servers. If the bitcode feature is enabled in our project, the Xcode LLVM tool chain no longer builds multiple processor-specific executable instruction sets for inclusion in our app bundle. Instead, it produces a “virtual instruction set” that can be translated to (and optimized for) a particular processor architecture as it is needed.
The process of converting the bitcode into executable code for a specific processor happens on Apple’s servers somewhere between the time your app is added to the app store and it is being downloaded by a user. Shifting this responsibility to Apple delivers several benefits:
- Only optimizations needed for the customer’s hardware are included in the executable code delivered to their devices
- Support for new processor architectures can be automatically added without us having to rebuild and resubmit our apps
- Optimization of both app size and performance can be continually improved based on the analysis of real world compilation results, i.e., the building of everyones’ apps
- All code-signing is performed by Apple—no sharing (and potential exposure) of encryption keys among team members needed
App Thinning and tvOS
With the introduction of tvOS, Apple requires the bitcode feature to be enabled in our projects. Fortunately, we don’t have to do anything beyond enabling the feature in our tvOS project. Xcode handles the rest for us.
While on demand resources are still considered optional, Apple restricts our tvOS app size to just 200 megabytes. For many types of apps, this limited size will make on demand resources a necessity. If you absolutely need more than 200 MB of data/assets available in order for your app to launch, you can indicate that some (or all) of your on demand resources should be retrieved as part of the initial app install. Taking advantage of this option means the 200 megabyte limitation can be expanded up to 2.2 GB, which is the maximum app size plus the maximum amount of on demand resources that can be accessed by an app at any given time.
Of course, you should obviously avoid making the size of your app plus its needed assets at any given time any larger than they have to be. In a worse case scenario where an Apple TV user has exhausted almost all of their storage space, they could be forced to download your on demand content every time they launched your app. Bad reviews (and karma) will surely be heading your way if that happens!
Stay Tuned…
Coming up next in the “Making Apple TV Apps” series, we’ll learn about the new, cool looking 3D parallax images that are a prominent part of the new Apple TV’s user interface. I hope you’ll visit again for that article and the rest of this series or even easier, sign up for articles to magically appear in your inbox as soon as they’re available. Thanks as always for dropping by!
Leave a Reply