Why App Size Matters
App size directly affects user acquisition. Research from Google has shown that for every 6 MB increase in APK size, install conversion rates drop by approximately 1%. On the App Store, Apple imposes a 200 MB limit for downloads over cellular data — apps above that threshold require Wi-Fi, which means users who discover your app on the go may never complete the install.
Beyond downloads, large apps consume valuable storage on the device. Users running low on space are prompted by both Android and iOS to delete infrequently used apps, and bloated apps are the first to go. In markets where budget devices with 32 GB or 64 GB of storage are common, every megabyte counts.
The Google Play Store also enforces a 150 MB limit for APKs (though Android App Bundles can be larger with on-demand delivery). Apple allows up to 4 GB for App Store submissions, but review guidelines strongly encourage keeping app sizes small. Reducing image asset weight is one of the most effective ways to stay well under these limits.
How Much Space Do Images Actually Consume?
In a typical mobile app, image assets — icons, illustrations, backgrounds, onboarding graphics, and photos — account for 30% to 50% of the total APK or IPA size. This is partly because mobile platforms require multiple copies of every image at different density levels. An Android app that supports mdpi through xxxhdpi bundles five copies of each raster asset. An iOS app supporting @2x and @3x bundles two or three.
You can verify this yourself using the Android APK Analyzer or Xcode's App Thinning report. The results are often surprising: a single uncompressed background image at xxxhdpi can exceed 2 MB, and a set of 50 icons across all densities can add up to 10 MB or more.
Choosing the Right Image Format
Selecting the correct format for each type of asset is the single highest-impact optimisation you can make. There is no universal best format — the right choice depends on the content of the image.
PNG is the standard for app icons, small UI elements, and any asset that requires transparency with hard edges. It uses lossless compression, so quality is perfect, but file sizes can be large for photographic content. For a detailed comparison, see the PNG vs WebP vs SVG guide.
WebP offers both lossy and lossless compression and typically produces files 25-35% smaller than equivalent PNGs. Android has supported WebP since API 14 (Android 4.0), and iOS added support in iOS 14. WebP is ideal for photographic content, large background images, and onboarding illustrations where a small amount of lossy compression is acceptable.
SVG and VectorDrawable are resolution-independent formats that render perfectly at any density without multiple file copies. On Android, VectorDrawable (an XML-based vector format) replaces the need for five density variants with a single file that is often under 1 KB. On iOS, PDF vectors serve a similar purpose in Asset Catalogs. Use vectors for simple icons, logos, and geometric shapes — but avoid them for complex illustrations with many gradients or effects, as rendering performance degrades with path complexity.
Compression Tools and Techniques
Even after choosing the right format, applying proper compression can reduce file sizes by another 30-70%. The following command-line tools are widely used in mobile development pipelines:
pngquant — Lossy PNG compression that reduces 24-bit PNGs to 8-bit paletted images. Quality loss is usually imperceptible for icons and UI elements. Typical savings: 60-80%.
optipng — Lossless PNG optimizer that re-compresses the DEFLATE stream without altering any pixel data. Smaller savings (5-25%) but guaranteed zero quality loss.
cwebp — Google's official WebP encoder. Converts PNG or JPEG sources to WebP with configurable quality. At quality 80, most images are visually indistinguishable from the original.
TinyPNG — A web-based service (and API) that applies smart lossy compression to PNG and WebP files. Convenient for one-off optimisations or integration into CI/CD pipelines via its REST API.
# Lossy PNG compression (60-80% smaller)
pngquant --quality=65-80 --output optimized.png input.png
# Lossless PNG re-compression
optipng -o7 input.png
# Convert PNG to WebP at quality 80
cwebp -q 80 input.png -o output.webpFile Size Comparison: PNG vs WebP vs VectorDrawable
The table below shows typical file sizes for a simple 48 dp app icon exported at each Android density bucket. The PNG column uses standard Photoshop "Save for Web" output. The WebP column uses cwebp -q 80. The VectorDrawable column shows the size of a single XML file that replaces all density variants. For more detail on how these density buckets work, see the Android drawable sizes guide.
| Density | Pixels (px) | PNG | WebP | VectorDrawable |
|---|---|---|---|---|
| mdpi | 48x48 | 1.1 KB | 0.7 KB | 0.6 KB |
| hdpi | 72x72 | 1.4 KB | 0.9 KB | — |
| xhdpi | 96x96 | 1.7 KB | 1.0 KB | — |
| xxhdpi | 144x144 | 2.1 KB | 1.3 KB | — |
| xxxhdpi | 192x192 | 1.9 KB | 1.1 KB | — |
| Total (all densities) | ~8.2 KB | ~5.0 KB | ~0.6 KB | |
For this simple icon, switching from PNG to WebP saves about 39%. Using a VectorDrawable saves over 92% and eliminates the need for density-specific folders entirely. The savings multiply across dozens or hundreds of icons in a real app.
Android App Bundle: Deliver Only What Each Device Needs
The Android App Bundle (AAB) format, required by Google Play since August 2021, fundamentally changes how density assets are delivered. Instead of shipping a single APK containing every density variant, Google Play generates optimised APKs for each device configuration. A user with an xxhdpi screen receives only the xxhdpi assets — the mdpi, hdpi, xhdpi, and xxxhdpi variants are stripped out.
Google reports that apps distributed as App Bundles are on average 15% smaller than universal APKs. For image-heavy apps, the savings can be significantly larger. To take full advantage of this system, include all density variants in your project — the build system and Play Store handle the rest.
# Build an Android App Bundle
./gradlew bundleRelease
# Verify bundle contents and per-device sizes
bundletool build-apks --bundle=app.aab --output=app.apks
bundletool get-size total --apks=app.apksiOS App Thinning and On-Demand Resources
Apple's equivalent is App Thinning, which comprises three technologies: slicing, bitcode (deprecated in Xcode 14), and on-demand resources (ODR).
Slicing works automatically when you distribute through the App Store. Xcode tags each asset in your Asset Catalog with its target traits (scale factor, device family, memory class), and the App Store generates device-specific variants. A user downloading on an iPhone with a @3x display receives only the @3x images.
On-demand resources go a step further: you tag certain assets (such as game levels, tutorial content, or region-specific images) as downloadable after install. The operating system fetches them when needed and can purge them when storage is low. This is particularly effective for apps with large media libraries or localised image sets.
Using Vector Drawables Instead of Bitmaps
For icons, logos, and simple illustrations, vector formats eliminate the largest source of image bloat: density duplication. A single VectorDrawable XML file on Android or a PDF vector in an iOS Asset Catalog replaces five or more raster files.
Android Studio can convert SVG files directly to VectorDrawable format via File > New > Vector Asset. The resulting XML is typically 200-800 bytes, compared to several kilobytes for the equivalent set of PNGs. At runtime, the framework rasterises the vector at the exact resolution needed, producing pixel-perfect output at every density.
Caveats: vector rendering has a CPU cost proportional to path complexity. Assets with hundreds of paths, complex gradients, or embedded raster effects (drop shadows, blurs) should remain as bitmaps. A good rule of thumb is that if the SVG source file exceeds 5 KB, benchmark the vector version against the raster equivalent before committing to it.
Identifying the Largest Assets with APK Analyzer
Android Studio includes a built-in APK Analyzer (accessible via Build > Analyze APK) that visualises the contents of your APK or AAB by file size. Navigate to the res/ directory to see every drawable folder and its contribution to the total size.
Sort by Raw File Size to identify the heaviest assets. Common offenders include uncompressed PNG backgrounds, large launcher icon sets, and placeholder images that could be replaced with solid colour drawables or shape XML. You can also compare two APK builds side-by-side to measure the impact of your optimisation efforts.
# Command-line equivalent using aapt2
aapt2 dump resources app-release.apk | grep -i "drawable"
# List files sorted by size inside the APK (it is a ZIP archive)
unzip -l app-release.apk | sort -rn -k1 | head -20Removing Unused Density Variants
Not every app needs to target every density bucket. The ldpi bucket (120 dpi) is effectively extinct — no mainstream device manufactured after 2014 uses it. Similarly, mdpi (160 dpi) devices represent a tiny fraction of the active install base.
You can exclude unused density configurations in your build.gradle file using the resConfigs property. This instructs the build system to strip those resources from the final APK or AAB:
android {
defaultConfig {
// Only include these density resources
resConfigs "hdpi", "xhdpi", "xxhdpi", "xxxhdpi"
}
}Check your analytics to confirm which density buckets your users actually have before removing any. The Android Vitals dashboard in Google Play Console shows the distribution of screen densities across your user base.
On-Demand Image Loading for Non-Critical Assets
Not every image needs to be bundled in the app binary. Assets that are not required at first launch — such as tutorial illustrations, promotional banners, seasonal themes, or user-generated content placeholders — can be downloaded on demand from a CDN.
On Android, libraries like Coil and Glide support efficient image loading with memory and disk caching. On iOS, frameworks like Kingfisher and SDWebImage provide the same capabilities. By moving non-critical assets to a remote server, you reduce the initial download size and can update images without shipping a new app version.
For assets that must be available offline, consider using Android's on-demand delivery modules (via Play Feature Delivery) or iOS on-demand resources. Both systems let the OS manage the lifecycle of downloaded assets, including automatic cleanup when the device runs low on storage.
Best Practices Checklist
Use WebP instead of PNG for photographic and complex images — saves 25-35% per file.
Use VectorDrawable (Android) or PDF vectors (iOS) for icons and simple shapes.
Run pngquant or optipng on all PNG assets before including them in the project.
Distribute via Android App Bundle to deliver only the matching density assets.
Enable App Thinning and asset slicing for iOS builds.
Remove unused density buckets (ldpi, mdpi) via resConfigs in build.gradle.
Move non-critical images to a CDN and load them on demand with Coil, Glide, or Kingfisher.
Use the APK Analyzer to identify and address the largest image assets after every release.
Design all raster assets at the highest required density and scale down — never scale up.
Audit third-party libraries for bundled image assets you do not actually use.
Generate Optimised Assets Automatically
Manually resizing, converting, and compressing images for every density bucket is time-consuming and error-prone. App Image Kit generates all density variants from a single source image — correctly sized, properly named, and ready to drop into your Android or iOS project. All processing runs in your browser; no images are uploaded to any server.
Combine automated asset generation with the compression and format selection techniques described above, and you can reduce your app's image footprint by 50-80% with minimal effort. Your users get a faster download, less storage consumption, and the same visual quality.
Ready to export your assets?
App Image Kit generates all density variants from a single source image — free, private, and instant.