Slicing: What It Is, How It Works, and How It Relates to App Thinning

What Is Slicing

Slicing is a component of App Thinning responsible for creating variants (slices) of the application binary on the App Store side. When a developer uploads a universal fat binary containing code and resources for all supported configurations, the App Store analyzes it and generates multiple slices: separately for iPhone with A17 processor, separately for iPad with M4, separately for Apple Watch. Each slice contains only those code fragments and resources that are necessary for that particular combination of architecture and resolution.

Before iOS 9, developers manually created separate binary files for different devices or shipped a universal fat binary that contained everything at once. Slicing fully automated this process: the developer prepares one project in Xcode, uploads one archive to App Store Connect, and Slicing on the server side creates the optimal number of variants. The user never sees the slicing process — they receive a ready .app optimized for their device.

Slicing applies not only to code and images but also to Metal shaders. Apple GPU uses its own instruction set (Metal Shading Language), which differs from PowerVR or ARM Mali instructions. Slicing includes in the slice only shaders for the GPU family of the target device. This is especially important for games with custom shaders — for example, high-detail post-processing effects are compiled only for devices with powerful GPUs (iPad Pro M4, iPhone 16 Pro Max).

Difference Between Slicing and Simple Architecture Compilation

The Xcode compiler creates a fat binary with multiple architectures (armv7, arm64, arm64e), but does not remove resources — all images for all resolutions remain inside the .app. Slicing goes further: it analyzes Asset Catalogs, Metal shaders, and Swift libraries, removing from each slice what is not needed for the specific target. For example, @3x graphics do not end up in the slice for iPhone SE, and iPhone-specific controllers (if extracted into separate resources) do not end up in the slice for iPad Air.

How Slicing Works

The Slicing process starts after uploading the build to App Store Connect and consists of three stages: analysis, slicing, and packaging. At the analysis stage, the App Store server parses the binary file, extracts information about supported architectures, devices, screen resolutions, and iOS versions. The App Store uses a mapping of all commercial Apple models to their technical specifications — the Device Database is updated with each iOS release.

At the slicing stage, the server creates separate copies of the binary file for each unique combination. To do this, the App Store extracts images from Asset Catalogs with specific tags (idiom, subtype, scale), selects only those that match the target device, and assembles a new resource bundle. The Swift standard library is also subject to slicing — unused symbols and methods are removed from it (dead code stripping).

At the packaging stage, each slice is placed into a separate distribution package and linked with metadata — a list of device models for which this slice is intended. When the user downloads the application, the App Store selects the appropriate slice based on the device model, iOS version, and connection type. If there is no exact match, the server uses the closest slice in terms of characteristics. Apple stores all variants in the CloudKit CDN network for fast delivery worldwide.

Slicing in the Context of App Thinning

Slicing is one of three mechanisms of App Thinning, but it contributes the most to reducing download size. Bitcode handles machine code optimization, On-Demand Resources handles resource management on the device, and Slicing handles removing redundant resources at the distribution stage. Without Slicing, the first two mechanisms still work, but users receive resources for all devices, increasing size by 20–40% depending on the number of Asset Catalogs.

The difference between Slicing and Bitcode lies in the point of application: Slicing works at the resource level (images, shaders, NIB files), Bitcode works at the machine code level. Slicing divides code by architectures (arm64 vs arm64e), Bitcode allows Apple to recompile code for new architectures. Bitcode + Slicing together provide maximum optimization: Bitcode generates code for a specific architecture, and Slicing removes unnecessary resources for that architecture.

The relationship with On-Demand Resources — Slicing and ODR do not overlap. Slicing determines which resources will even reach the device distribution, while ODR manages when these resources are loaded and unloaded. The developer can tag a resource with an ODR tag, and Slicing will include it in the slice if it matches the device. Apple recommends using all three mechanisms simultaneously for the minimum installation size.

Slicing Variants for Different Devices

Slicing creates separate slices based on several dimensions: processor architecture, screen size (resolution), iOS version, and GPU family (for Metal). Architecture determines the CPU instruction set: arm64 — basic 64-bit set (iPhone 5s — iPhone X), arm64e — extended set with Pointer Authentication and PAC support (iPhone XS and newer, iPad Pro with A12X+). The slice for arm64e includes code with memory protection instructions not available on arm64 devices.

Screen resolution — the second key dimension of Slicing. Apple uses scales @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus and newer) and iPad-specific (2x and 3x with additional metrics). Slicing includes in the slice only images with the scale matching the target device. With proper Asset Catalog organization in Xcode, this eliminates the need to manually manage resource sets — just add an image to the catalog, specifying the supported device types.

GPU family — the third dimension, critically important for Metal applications. Apple classifies GPUs by generations: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Metal shaders are compiled for each family separately, as the Metal Shading Language instruction set expands with each GPU generation. Slicing includes in the slice only shaders for the GPU family of the target device, significantly reducing the size of games and applications using Metal for rendering.

Impact of Architecture on Slice Size

CPU architecture directly affects slice size: arm64e code contains additional Pointer Authentication (PAC) and Signed Return Address instructions, which increase the binary file by 5–10% compared to arm64. However, this increase is compensated by the fact that Slicing includes arm64e code only in slices for devices with A12+ processors. For iPhone SE (third generation) with A15 Bionic, Slicing creates a separate slice optimized for the capabilities of this chip.

Configuring Slicing in Xcode

Configuring Slicing in Xcode is minimal — the main configuration is done through Asset Catalogs and Build Settings. Asset Catalog should contain resources organized by device type (Any, iPhone, iPad, Apple Watch, Apple TV) with correct scale and display mode specified. Xcode automatically includes in the build only those resources that match the target devices specified in the Deployment Target settings.

The key Slicing setting in Xcode is the Build Setting App Thinning. Available values:

• None — Slicing is disabled, the application is shipped as a universal fat binary
• Automatic — Xcode enables Slicing with default settings
• Manual — the developer selects specific combinations for Slicing

Targeted Device Families in General → Deployment Info determines which device types the application is built for (iPhone / iPad / Universal). Slicing relies on this parameter during slicing — if the application supports only iPhone, a slice for iPad is not created. Deployment Target (minimum iOS version) also affects Slicing: older iOS versions may require armv7 slices, which are not needed for iOS 13+. Apple recommends setting the Deployment Target to the latest stable iOS version — this reduces the number of slices and the binary size.

Asset Catalog Parameters for Slicing

For maximum Slicing efficiency, Asset Catalogs should use specific tags for each resource. Xcode provides in Attributes Inspector for images: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). By combining these tags, the developer controls which slices each image ends up in. For example, an iPad image tagged Regular Width + Regular Height will only appear in slices for iPad in landscape orientation.

# Export slice for a specific device
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild with the -thinning parameter and model identifier creates a slice only for that model. The list of identifiers can be found in Apple’s Device Database (format: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). This method is useful for checking slice size before submitting to App Store Connect. CI/CD can use this command for automatic verification — if the slice size exceeds the limit (for example, 100 MB for mobile download), the pipeline issues a warning.

Verifying Slicing Results

After uploading the archive to App Store Connect, Apple provides detailed statistics on slice sizes. App Store Connect → Activity → select build → App Thinning — displays Estimated App Store Size for each device category: iPhone, iPad, Apple Watch, tvOS. Sizes are broken down by iOS versions and processor types. If any slice exceeds the expected size, App Store Connect marks it with a yellow warning.

Local verification through Xcode Organizer: after archiving, open Window → Organizer, select the archive, and click App Thinning Profiles. Xcode will show sizes for each possible slice based on the current project configuration. The Export option is also available for creating an IPA with a specific Slicing profile. Xcode generates an .app-thinning.plist with information about which resources are included in each slice.

To automate Slicing verification in CI/CD, use xcodebuild with -thinning and analyze the size of the created .app files. Apple provides the command-line utility app-size (installed via Xcode Command Line Tools), which outputs a detailed report: code size, resource sizes by category (images, shaders, NIB), Swift library sizes. Comparing slice sizes before and after Asset Catalog optimization helps identify resources not participating in Slicing due to incorrect configuration.

# Analyze slice size
app-size -m "sliced/App.app" \
  --format json

App-size outputs a JSON report broken down by resource categories. If Slicing is configured correctly, the "images" section will contain only one scale set (@2x or @3x), not all variants. An Asset Catalog configuration error manifests when all scales (@1x, @2x, @3x) are present in the slice — this means Xcode could not determine the target device for these images, and Slicing did not work.