App Thinning — що це, з яких компонентів складається та як працює

Що таке App Thinning

App Thinning is a comprehensive iOS app distribution optimization technology introduced by Apple with iOS 9 (September 2015). The goal of App Thinning is to minimize the size of the application that a user downloads to their device without changing the source code or functionality. The technology works on three levels: at build time (compilation), on the App Store side (delivery), and on the device (resource management).

Before App Thinning, developers included resources for all possible devices in the binary file — @2x and @3x images, 32-bit and 64-bit code, Metal shaders for different GPUs. This led to app size bloat: a user with an iPhone 6 Plus with a Retina HD display received vector resources for iPad Pro that were never used. Apple solved this problem by moving part of the compilation work to App Store servers.

According to Apple research (WWDC 2015, Session 412), a typical app supporting multiple architectures and resolutions can be reduced by 30–50% after applying App Thinning. For games with a large number of high-detail textures, the gain can reach 70–80%. Apple continues to improve the technology: iOS 17 added optimization for ARM64e and improved On-Demand Resources for apps using Swift Package Manager.

Проблема, яку вирішує App Thinning

The size of mobile applications is constantly growing. According to Sensor Tower (2025), the average iOS app size has increased by 45% over the last 5 years. For users with limited data plans or slow internet, every megabyte matters. App Thinning solves this problem without developer involvement — simply enable support in project settings and upload the build to App Store Connect.

Як працює App Thinning

The App Thinning process begins after uploading the app archive to App Store Connect. App Store analyzes the binary file and splits it into segments by architecture (armv7, arm64, arm64e), screen resolutions (iPhone, iPad), and iOS versions. A separate variant is created for each combination. When a user taps “Download,” the App Store determines the device model, iOS version, and connection type (Wi-Fi / cellular) and sends only the corresponding variant.

For the user, the process is transparent — there is no “легка версія” selection or settings dialog. App Store automatically selects the most suitable variant based on device metadata sent to the server during the download request. If the device is on Wi-Fi, the App Store may send a variant with higher quality resources (e.g., ProRes video for iPhone 16 Pro). When downloading over a cellular network, the smallest possible set is used.

The second level of optimization is Bitcode. When the ENABLE_BITCODE option is enabled, Xcode compiles the application not into machine code but into an intermediate LLVM representation. The App Store recompiles Bitcode for the specific user’s processor architecture, allowing Apple to apply compiler optimizations for new chip generations (A17, M4) without the developer updating the app. Bitcode is required for watchOS and tvOS but optional for iOS.

Компоненти App Thinning: Slicing, Bitcode, ODR

App Thinning consists of three independent mechanisms, each responsible for its own aspect of optimization. Slicing splits the binary file into variants by architecture and screen resolution. The developer configures Slicing through Asset Catalogs — Xcode automatically includes in the slice only those resources that match the target device. For example, an iPhone SE (third generation) will receive only @2x images and arm64 code, while an iPad Pro M4 will receive @3x images and arm64e code.

Bitcode is LLVM IR (Intermediate Representation) — a machine-independent representation of the program. When Bitcode is enabled, Xcode does not generate final machine code but saves the intermediate representation. App Store Connect receives the Bitcode when the build is uploaded and recompiles it for the architectures of all supported devices. Bitcode allows Apple to apply optimizations unavailable at the developer’s compilation stage — for example, using new processor instructions (SME, SVE) on M4 chips.

On-Demand Resources (ODR) is the third mechanism, which allows unloading app resources after use. The developer tags resources (game levels, onboarding images, videos) with ODR tags. iOS downloads tagged resources on demand in the background and unloads them when memory is low or after use. ODR is especially effective for games with large amounts of content — the first levels can be shipped with the app, while the rest are downloaded as the player progresses.

Коли вибирати кожен компонент

The choice of App Thinning mechanisms depends on the type of application and its target audience. Slicing is recommended to always enable — it requires no additional developer actions beyond proper Asset Catalog organization and provides a consistent 20–30% size reduction. Bitcode should be enabled if the app uses custom Metal shaders or plans to support new Apple architectures without rebuilding. ODR is justified for applications with large amounts of content — games, photo editors, streaming apps.

For a typical business application (data feeds, forms, REST API), Slicing and minimal ODR setup for onboarding images are sufficient. Games with 3D graphics benefit from all three mechanisms: Slicing removes unnecessary shaders, Bitcode optimizes rendering for the GPU, and ODR unloads completed levels. According to Apple (WWDC 2024), the combination of all three mechanisms reduces the initial install size by an average of 45–55% compared to a universal binary.

Налаштування App Thinning у Xcode

To enable App Thinning in an Xcode project, several steps are required. Slicing is configured via App Thinning in build settings: Build Settings → App Thinning. Three values are available: None (no optimization), Automatic (default automatic configuration), and Manual with selection of specific variants for testing. Apple recommends Automatic for most projects.

For Asset Catalogs, it is important to organize resources correctly: images are placed in a universal catalog with width/height specified, and Xcode automatically creates @1x, @2x, and @3x variants. Xcode during build includes only those resolutions used in the project. Metal shaders are compiled separately for each GPU family — Apple GPU, PowerVR, Mali — which is also managed through Asset Catalogs.

Bitcode is enabled with the ENABLE_BITCODE = YES flag in Build Settings. For iOS, this flag is optional (disabled by default since Xcode 14), but for watchOS and tvOS it is mandatory. When Bitcode is enabled in a project that uses third-party libraries, all of them must also be built with Bitcode, otherwise the build will fail. Bitcode increases compilation time by 20–30% but provides full compatibility with future architectures.

Перевірка результатів App Thinning

After uploading to App Store Connect, you can check slice sizes in the Activity → Build Metric section. App Store Connect displays the Estimated App Store Size for different devices. For local verification, Xcode provides the xcodebuild command with the -exportArchive flag and the thinning option to create slices on the local machine. Slicing results can be viewed in the Organizer (Window → Organizer) after archiving — the App Thinning Profiles tab shows sizes for different devices.

# Локальна перевірка Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild with the -thinning flag creates .app files for each combination of architecture, bitness, and GPU. The <thin-for-all-variants> parameter creates all possible variants — useful for testing. For CI pipelines, a specific combination can be specified, such as iPhone14,4 (iPhone SE 3). The resulting .app files can be analyzed using the app-size utility.

Переваги та вплив App Thinning

The main advantage of App Thinning is reducing download size for the end user. According to Apple (WWDC 2024), a typical app using all three App Thinning mechanisms downloads on average 40% faster over a cellular network and takes up 35% less disk space. This directly affects installation conversion: according to Sensor Tower, every 10 MB of app size reduces conversion by 1%.

The second advantage is optimization for future devices through Bitcode. Apple can recompile Bitcode apps for new architectures without developer involvement. For example, during the transition from Intel to Apple Silicon (M1), Bitcode apps worked on macOS via Rosetta 2 without additional builds. Developers who did not enable Bitcode had to rebuild their apps for arm64.

The third advantage is that ODR (On-Demand Resources) reduces the burden on device storage. Games with dozens of levels, such as Asphalt 8: Airborne, use ODR to load new tracks as the player progresses. The developer can set Initial Install Tags for resources that are downloaded with the app and Prefetch Tags for content that loads in the background after installation. Apple controls ODR limits: up to 512 MB per request and up to 20 GB total cache on the device.

Обмеження App Thinning

App Thinning has several important limitations to consider when designing an application. First, Slicing does not apply to apps distributed via Enterprise (in-house) or Ad Hoc — these builds contain all variants and do not go through the App Store. For testing Slicing, developers can use TestFlight, which also processes Slicing on Apple’s servers.

Second, Bitcode increases build time and the size of the .xcarchive by approximately 30–50%. Not all third-party libraries support Bitcode — if even one dependency is built without Bitcode, the project build with ENABLE_BITCODE will fail. Apple recommends checking library compatibility before enabling Bitcode. Additionally, Bitcode does not fully support Swift Package Manager — some Swift packages can break Bitcode builds.

Third, On-Demand Resources do not guarantee instant content availability — ODR loading happens in the background and may be delayed if the device is in low battery mode or has a weak network signal. The developer must implement ODR loading status handling through NSBundleResourceRequest and show a progress indicator to the user. An ODR loading failure should not block app functionality — a graceful fallback is required.