First, export an App Thinning Size Report in Xcode 27, then compare its estimates with the processed build’s variant sizes in App Store Connect. Do not use the Archive or exported IPA file size as a stand-in for what every user downloads.
This guide is for independent iOS developers preparing a release after an unexpected size increase.
It also helps small teams managing multiple device variants, languages, or optional content.
If you repeatedly archive builds on a remote Mac, use the same export settings and keep each report with its source revision.
Xcode 27 iOS App size optimization starts with the right measurement
“App size” can refer to several different artifacts. They are related, but they are not interchangeable:
- Archive size: the local Xcode archive bundle, which can contain material used during development and distribution.
- Exported IPA size: the file you create for a distribution workflow. It is an upload artifact, not a universal measurement of the final download.
- Variant download size: the estimate for the device-specific app package delivered through the App Store.
- Installed size: the storage occupied after installation. It can differ from the download size because the installed app is expanded and managed on the device.
Apple describes the App Thinning Size Report and app-size measurement workflow and notes that App Store Connect provides more accurate size information for processed builds. The practical consequence is simple: use the report to investigate, then use App Store Connect to verify what the store expects to deliver.
A single exported IPA can include content that a particular device does not need. App thinning can produce variants with different combinations of resources and binary components. The App Store Connect result, not the local file you happen to inspect, is the appropriate release cross-check. Apple explains where to view build information and app-size details in App Store Connect.
Keep the measurements separate: a large Archive may point to build or diagnostic material, while a large store variant points to content delivered to users. Neither conclusion follows from the Archive’s total size alone.
The report is an estimate for a specific archive and export configuration. App Store Connect reflects the build after Apple has processed it. If the figures differ, first check that you are comparing the same build and equivalent device variants. Do not delete assets or change compiler settings until the comparison identifies which measurement is actually above your target.
02Start with the export and evidence trail
Use a repeatable sequence so that a size change can be tied to a code or asset change rather than to a different build setup.
Step 1: Fix the build being measured
Choose the release configuration and create an Archive from the project revision you intend to compare. Record the commit or source revision, build configuration, Xcode version, and export choices. If dependencies, build settings, or included resources changed since the previous release, note that too.
The point is not to collect every possible build detail. It is to make the next comparison meaningful. Comparing a development build with a release archive, for example, can mix configuration differences with genuine app growth.
Step 2: Export with the thinning report enabled
In Xcode’s distribution workflow, select the option to generate an App Thinning Size Report when exporting the archived app. Keep the report with the export output. The report gives you a basis for comparing the universal package with device-specific variants.
Treat the exported IPA as evidence about that export, not as the final App Store download figure. Avoid comparing an IPA from one export method against a report generated from another without recording the difference.
Step 3: Inspect the report before editing the project
Look for which variants are materially larger and whether the report points toward resources or the app binary. Compare like with like: the same archive, the same distribution path, and the same device variant where possible.
If a variant is larger than expected, write down the suspected category before changing anything. For example, a growth concentrated in image resources suggests a different investigation from growth across the executable or embedded frameworks.
Step 4: Verify the processed build in App Store Connect
After uploading and processing the build, open its details in App Store Connect and inspect the size information for relevant variants. Apple’s build details documentation is the reference for finding build metadata and size information.
This is the step that answers a common release question: where should you check the download size for each device? Check the processed build’s variant details, not just the local export folder. If the build has not finished processing, wait for the relevant information to appear rather than treating a missing value as zero or as a failed upload.
Step 5: Keep a comparable baseline
Save the report, the processed-build reference, and a short note about the revision and export settings. For the next release, compare the same variant and same measurement type. A useful baseline is not just “the app was smaller”; it records whether the earlier figure was an estimated download size, an installed-size estimate, or an upload artifact.
This lightweight record helps distinguish an actual regression from a changed export path or a different set of device resources.
03Resource growth: inspect what ships with the first install
When the report points toward resources, inspect the app’s asset catalogs, bundled media, and localized content. Start with the resources that are both large and included in the initial app delivery. Look for duplicate images, obsolete files still referenced by the target, oversized source assets, and content that users do not need at first launch.
Asset catalogs can contain device-appropriate variants rather than forcing every device to receive every image. Apple describes how Asset Catalogs manage asset variations. That does not mean every catalog automatically reduces every app’s delivered size. The result depends on how assets are organized and referenced, so confirm the effect in the report and processed variant data.
For media or substantial content that is not needed immediately, evaluate whether it can be delivered later. Apple’s advanced app-size guidance covers techniques such as asset compression and on-demand resources. These approaches have trade-offs: deferred content requires a reliable download and caching experience, while compression can affect visual or audio quality. Test the actual content and user flow before deciding that either method is suitable.
A practical case: suppose a release adds several language packs and a set of tutorial videos. The report shows the growth is concentrated in resource-heavy variants. First confirm which locales and assets are included in the target. Then decide whether all users need the videos at first launch. If some content can be fetched later without harming onboarding, test that delivery approach. If the report shows no meaningful reduction for the relevant variants, revert rather than adding complexity for a negligible gain.
Apple’s basic app-size optimization guidance is a good reference for common asset and project checks. Treat it as a set of options to validate, not a promise that a particular change will reduce every device variant.
04Binary growth: separate shipped code from diagnostic files
If the report points toward the executable or embedded frameworks, inspect the release target’s linked code and the frameworks included in the app. Check for unused dependencies, duplicate framework copies, and targets that embed components they do not need. Confirm the final build settings for the target being archived, not just a similarly named project-level setting.
Apple’s build settings reference describes optimization settings, while its guide to checking the effective build settings for a target helps you inspect values applied to the actual target. A setting visible in the project interface may be overridden at another level. Verify the resolved release value before changing it.
Do not count dSYM files as if they were part of the user’s App Store download. They are symbol files used for diagnostics, not a proxy for the delivered app variant. Likewise, the Archive directory can include more than the package users receive. If the Archive is large but the report and App Store Connect show acceptable variant sizes, clean up build storage separately; do not make risky code changes to solve a storage problem that users do not have.
Apple documents a 4 GB maximum build file size for applicable App Store uploads in its maximum build file size reference. That is an upload ceiling, not a target download size and not evidence that an app below the ceiling is small enough for your audience. Keep the upload constraint separate from user download and installed-storage decisions.
05Device variants and cellular download warnings
A universal package and a device-specific variant can contain different combinations of assets and binary components. That is why one local export cannot establish what every supported device will receive. Check the report for the variants it presents, then inspect the processed build in App Store Connect for the device types relevant to your audience.
When App Store Connect shows a size warning, first identify which figure triggered it. Then check the affected variant, the release’s target audience, and Apple’s current guidance on cellular downloads. Apple’s app-size guidance discusses cellular download considerations. Do not assume a warning means the uploaded IPA crossed a fixed universal limit: the applicable behavior can depend on Apple’s current rules and the user’s device settings.
An App Store Connect App File Sizes check should inform the release decision, not replace it. Download size matters to users with limited connectivity or storage. Installed size matters after the app and its required data are on the device. A large optional media pack may be worth deferring; a large core model or offline map may be essential to the product. Reduce what is unnecessary, not what makes the app work.
06Choose the next action by evidence
Use these conditions to choose a response. If none of the report or store measurements is above your target, do not optimize for a number that does not affect your users.
- If the IPA is large but the relevant App Store variant is within your target, keep the release artifact and record the result. Do not remove content based only on the IPA’s file size.
- If the report and App Store Connect both show resource-heavy variants above your target, inspect asset catalogs, duplicate resources, localization payloads, and content that could be delivered later.
- If the growth is concentrated in the executable or embedded frameworks, inspect linked dependencies and the final release build settings before changing assets.
- If the universal result is high but device variants are acceptable, confirm that the supported devices receive the expected variants. Do not optimize the universal package at the expense of a valid device-specific result.
- If the store’s cellular guidance affects your target users, prioritize content that is optional at first launch and test the revised delivery experience. If the content must be present offline, document why the larger download is an intentional product decision.
- If the figures disagree, verify the build identity, processing status, export options, and measurement type before making changes. Re-export only after you can explain what the next run is meant to test.
The comparison below keeps the measurement and decision distinct:
| Evidence | What it measures | What to do next |
|---|---|---|
| Archive directory | Local archive contents | Investigate build storage; do not equate it with a store download |
| Exported IPA | The selected export artifact | Use it for delivery workflow checks, not as the sole user-size metric |
| App Thinning Size Report | Estimated universal and device-specific results | Locate resource or binary growth and identify variants to compare |
| App Store Connect build details | Processed build and variant size information | Use it to verify the store-facing result |
| Device storage after installation | Installed app and its local data | Test on representative devices if storage pressure is the concern |
Build a size regression check that can be repeated
A size check is useful only if successive results are comparable. For every release candidate, keep the same basic sequence: archive the chosen revision, export with the report option, save the report, upload the build, and record the processed variant values. Store these artifacts where the team can find them with the release notes.
If the team uses a remote Mac for repeated archives, keep the project revision and export choices explicit. A remote machine does not change what the size measurements mean; it gives you a macOS environment in which to run the same Xcode release workflow. Avoid comparing reports created with different settings unless that difference is the subject of the test.
| Regression-check item | Record this | Why it matters |
|---|---|---|
| Source revision | Commit or release tag | Connects a size change to the code and assets being tested |
| Build and export setup | Release configuration and export choices | Avoids confusing settings changes with app growth |
| Xcode report | Report file with the artifact | Preserves local estimates by variant |
| App Store Connect result | Processed build reference and relevant variant values | Confirms the store-facing measurement |
| Change note | Assets, frameworks, or content delivery changed | Focuses the next investigation |
For release acceptance, choose a target based on your app and users rather than adopting a universal “good size.” An offline-first app may intentionally bundle substantial content. A small utility with no offline requirement has a different trade-off. What matters is whether the delivered variant is justified, whether users can download it reliably, and whether installed storage remains acceptable for the experience you promise.
08Common questions
Is the uploaded IPA the same size users download?
No. The IPA is an export artifact. App Store delivery can provide device-specific variants, and installed storage is another measurement. Compare the Xcode report with the processed build’s App Store Connect size information before deciding that users receive the full IPA contents.
How do you generate an App Thinning Size Report in Xcode 27?
Archive the release build, then enable the App Thinning Size Report option in Xcode’s distribution and export workflow. Save the report with the source revision and export settings. Use App Store Connect to verify the processed build afterward.
Where do device-specific download sizes appear in App Store Connect?
Open the processed build’s details and inspect its size information. Check the variants relevant to your supported devices. A universal export alone does not show what every user’s device will receive.
What should you check when a cellular download warning appears?
Confirm the size of the affected App Store variant first. Then check Apple’s current cellular-download guidance and the user’s device settings. If the variant is close to the relevant threshold, inspect large assets and optional content before changing code.
If you maintain builds on your own computer, that can be the simplest option when the Mac is already available and you do not need a separate always-accessible build environment. A generic hosted build workflow can reduce local hardware needs, but may limit control over the macOS environment or make repeated investigation harder; buying a Mac gives you direct access, but ties up capital and requires you to maintain the machine. If you need to Archive, export, and compare reports without buying another Mac, review VpsMesh Mac rental options and the available remote Mac environment. A rented Mac is most useful when you need a temporary or repeatable macOS workspace; if you require permanent heavy workloads or physical peripherals, owning local hardware may be the better fit.