How to Reduce iOS App Size: Optimize Images and Asset Catalogs

App size matters on iOS for reasons beyond storage. Large downloads take longer, cellular download limits prompt users to wait for Wi-Fi, and a heavy app is more likely to be deleted when someone needs space. For most apps that ship rich interface, images are the largest piece of the bundle that you directly control. This guide covers how to find out where your size comes from, how Apple's app thinning works, and the concrete steps that reduce the footprint of images and asset catalogs without hurting the way your app looks.

Step 1: Measure where the size comes from

Guessing wastes time. Xcode can tell you what each build contributes, and there are two views worth knowing.

App Thinning Size Report

When you export an archive for distribution, Xcode can produce an App Thinning Size Report. It lists the compressed and uncompressed size of the app for each device variant that the App Store would generate. This is the number that approximates what users actually download and what they have installed, rather than the size of the single universal build. Always compare sizes using this report rather than the size of the IPA on disk.

Inspect the bundle

You can also unpack an exported build and look at the contents. An IPA is a ZIP archive. Extract it, open the Payload folder, and show the package contents of the app. Sort by size. Asset catalogs compile into a file named Assets.car, and loose image files sit alongside it. If Assets.car or a folder of loose PNGs dominates the listing, images are your target.

Step 2: Understand app thinning

App thinning is Apple's collective name for features that reduce what a device downloads. Three parts matter for images.

• Slicing. The App Store creates variants of your app for specific devices and delivers only the assets that device needs. This works for assets in an asset catalog, where you provide 1x, 2x and 3x versions. A device with a 3x screen does not download the 1x or 2x files.
• Bitcode and other compilation changes affect code rather than images and are not covered here.
• On-demand resources. Assets can be tagged and downloaded only when needed, for example level packs or tutorial videos.

The practical consequence: images in asset catalogs benefit from slicing automatically, while images dropped loosely into the bundle as files do not. Move anything you can into an asset catalog.

Step 3: Move images into asset catalogs

An asset catalog, the xcassets folder in your project, lets you declare an image set with variants for different scale factors and device idioms. At build time Xcode compiles them into an optimized format. Using catalogs gives you slicing, named image lookup and support for dark appearances and other variants.

• Add 2x and 3x versions for raster images. Current iPhones use 2x and 3x. Avoid shipping a 1x image unless you support an old device that needs it.
• Prefer vector assets, such as PDF or SVG supported by your Xcode version, for simple icons. A single vector asset scales to every size and is usually smaller than several PNGs.
• Use named colors for flat backgrounds rather than a PNG filled with one color.

Step 4: Remove what you do not use

Large apps accumulate dead images. A feature was redesigned, the old art stayed in the catalog and nobody noticed.

• Search the project for the name of every image set. Zero references means it is a deletion candidate.
• Use a third-party or scripted unused-asset finder if you have hundreds of assets, then verify manually, because images can be loaded with dynamically constructed names.
• Delete unused fonts, sample content and debug-only artwork from release targets.
• Check for duplicates: the same image saved under two names is common after a rebrand.

Step 5: Right-size your images

The most common cause of heavy iOS asset catalogs is shipping images far larger than the space they occupy. A background image that is 2000 points wide displays on a 430 point wide screen. At 3x that is 1290 pixels, so anything beyond that is wasted.

Work backwards from the largest place the image is displayed. Take the width in points, multiply by 3 for the 3x variant and by 2 for the 2x variant, and export exactly that. Provide artwork at the exact size rather than letting the system downsample, which wastes download size and memory.

Step 6: Compress the source images

Once the images are the right size and format, compress them. Asset catalog images are PNG or JPEG files in your repository, and compressing those source files directly reduces the size that goes into Assets.car.

Lossless first

Lossless optimization strips metadata and re-encodes the PNG with stronger settings, with pixel-identical results. It is safe for every asset and a good first pass, especially for design exports that carry extra metadata.

Lossy where it is invisible

Lossy PNG quantization reduces the palette and often makes flat illustrations, onboarding art and interface graphics much smaller. Review the output at full size, particularly on gradients, before committing it. For photographs, use JPEG or HEIC where your deployment target allows rather than PNG.

Be careful with Xcode's own processing

Xcode runs its own image processing during the build, including PNG optimization for loose files in some configurations. That does not replace compressing your sources: the quality of the optimizer matters, and dedicated tools generally give a better result than the build step alone. Measure the size of the compiled app after compressing to confirm that the saving survives the build.

Step 7: Choose the right format

Check the minimum iOS version you support before adopting newer image formats. If your deployment target supports it, formats such as HEIC can be considerably smaller than PNG or JPEG for photographic assets.

Step 8: Move big, rarely used content out of the bundle

Not everything has to ship in the download. Tutorial videos, high-resolution galleries and downloadable content packs can use on-demand resources or be fetched from a server on first use. The trade-off is added complexity and a loading state, so apply it to assets that are large and used by a minority of users.

Automate it so the size does not creep back

App size grows slowly: a designer exports a new onboarding screen, a developer drops it in the catalog and the build gains two megabytes. Manual compression only works until someone forgets. Automation closes the gap.

TinyPixels includes a watch-folder feature. Point it at the folder that holds your exported artwork or your xcassets sources, and every new PNG or JPEG is compressed locally the moment it lands, with no build plugin and no Run Script phase. The engine runs on your Mac, so unreleased artwork never leaves your machine, and Pro is a one-time purchase rather than a subscription. See the TinyPixels guide for Xcode assets for a walkthrough.

Step 9: Check the result

1. Archive the app and export with the App Thinning Size Report enabled.
2. Compare the report with the previous release for the device you care about most.
3. Install both builds on a test device and compare the Settings storage figure.
4. Run through the screens that use compressed images and compare against the original at actual size on a real device.
5. Keep the numbers in your release notes or CI output so regressions are visible.

Common pitfalls

• Looking at the IPA size instead of the thinned size. The universal build is larger than any individual download.
• Shipping 1x images that no current device uses.
• Compressing an image that is displayed much smaller than its pixel size, instead of resizing it first.
• Using PNG for full-screen photographs.
• Over-compressing gradients and noticing banding only after release.
• Forgetting about Mac Catalyst or iPad variants that need larger assets.

A realistic checklist

1. Generate an App Thinning Size Report and note the baseline.
2. Delete unused image sets and duplicates.
3. Replace simple icons with vector assets.
4. Resize large images to their real display size at 2x and 3x.
5. Compress sources: lossless for everything, lossy for flat artwork.
6. Convert photographic content to JPEG or HEIC where your deployment target allows.
7. Move big optional media out of the bundle.
8. Set up a watch folder so new assets are compressed automatically.
9. Re-measure and record the result.

Dark mode, localization and other variants

Variants multiply asset size quietly. If an image set has separate light and dark appearances, both are shipped, so only add a dark variant where the artwork genuinely differs. Where a single image works in both, use a template rendering mode and tint it with a color. Localized screenshots and artwork multiply by the number of languages, so ask whether text really needs to be baked into the image or can be drawn natively on top of a shared background.

Similarly, check whether iPad-specific or other idiom-specific variants of an image are visibly different. If the iPad version is just a scaled copy, remove it and let the system use the universal image. Every variant you delete is a file that nobody downloads.

Keep a size budget

Pick a target for the thinned download size and treat it like a performance budget. Record the number for every release, and investigate any jump larger than a threshold you agree on. Teams that track size per release find regressions within days instead of discovering them after users complain.

When a size reduction is not worth it

Not every saving is worth the effort. If a screen shows a hero image that defines your brand, a barely visible quality loss may cost more in perception than it saves in bytes. Focus first on the large, low-visibility wins: unused assets, oversized files and metadata. Reserve aggressive lossy settings for assets where users will not notice, and review hero artwork on a real device with your design team before approving a change.

Conclusion

Reducing iOS app size is rarely about a single trick. It comes from measuring first, letting app thinning do its job through asset catalogs, deleting what you do not use, shipping images at the size they are shown, and compressing the sources with a good encoder. Do those in order and images stop being the heaviest part of your bundle. Keep the process local and automatic, and the savings last.

Frequently asked questions