App Bundling Explained: Cut App Size 60% With Android App Bundle
A plain-English guide to mobile app bundling: how AAB and App Thinning work, what gets included per device, the 8 famous apps using bundles, and how to ship smaller installs.
App bundling is the technique that lets you upload one giant artifact to the app store, and the store delivers only the parts each user’s device actually needs. Adobe Lightroom went from 158MB to 56MB. Tinder cut their download size by 35%. Netflix ships separate ABI splits per device. Every Android app on Google Play has been required to ship as an Android App Bundle (AAB) since August 2021. iOS apps use App Thinning to achieve similar results. This guide explains how bundling works under the hood, the 8 famous apps using it, and how to ship smaller installs without losing features. For broader release context, our app versioning guide and backend guide cover related decisions.
What You Will Learn
- Plain-English definition of app bundling and how it works
- Android App Bundle (AAB) vs APK vs iOS App Thinning
- Dynamic feature modules and on-demand delivery
- 8 famous apps with documented size reductions
- How to ship a bundled app from a no-code platform
- 8 bundling mistakes that bloat downloads anyway
Backed by Google Play Console documentation, Apple App Thinning guidelines, Android Developers performance reports, Adobe Lightroom engineering blog, and platform data from 10 million+ apps built on Appy Pie AI. Rated 4.7/5 on G2 from 1,388 reviews.
Build Your App With Smart BundlingTL;DR Quick Summary
App bundling is how mobile platforms ship smaller downloads to each user. You upload one bundle file (AAB on Android, the universal binary on iOS) containing everything for every device. The app store generates and delivers only the slice of code, resources, and assets that match the user’s device, language, and screen density. The result: 30-70% smaller user downloads. Adobe Lightroom dropped from 158MB to 66MB. Spotify cut size 23%. Tinder cut 35%. Every Android app on Google Play has used AAB since August 2021. iOS uses App Thinning automatically. The only question is whether you also use dynamic feature modules for further savings.
Table of Contents
Jump to any section. This guide defines what app bundling is, walks through the 6 core bundle components, compares AAB vs APK vs iOS App Thinning, shows 8 famous apps with documented size reductions, walks through how to ship a bundled app without coding, and ends with the 8 mistakes that bloat downloads even when using bundles.
- What is App Bundling? (Plain Definition)
- Why App Bundling Cuts Install Friction
- 6 Components Inside an App Bundle
- AAB vs APK vs iOS App Thinning
- 8 Famous Apps and Their Bundle Wins
- Dynamic Feature Modules and On-Demand Delivery
- How to Ship a Bundled App Without Coding
- 8 Bundling Mistakes That Bloat Downloads Anyway
- Frequently Asked Questions
- Conclusion
What is App Bundling? (Plain Definition)
App bundling is the practice of uploading one comprehensive package to an app store and letting the store generate device-specific installs from it. Your bundle contains every version of every resource the app might need (every language, every screen density, every CPU architecture). The app store inspects each user’s device at install time and ships them only the slice that fits.
The simplest way to picture it: a publisher prints a catalog with 50 product variations. The catalog ships to a warehouse. Customers do not get the catalog. They get only the one product they ordered, packaged from the warehouse stock. The catalog (your bundle) stays at the store. The customer (user) only downloads the variant for their specific situation.
What lives in a typical app bundle
- Compiled code (DEX on Android, machine code on iOS) for every supported CPU architecture (armeabi-v7a, arm64-v8a, x86, x86_64)
- Resources at multiple densities (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi for Android; @1x, @2x, @3x for iOS)
- Strings for every supported language (English, Spanish, French, German, Japanese, Arabic, etc.)
- Native libraries (.so files on Android, .dylib on iOS) for each architecture
- Asset packs (large media, ML models, game assets) that may load on demand
- Configuration manifests describing what the app needs from the device
What gets delivered to each user
The store picks based on the user’s device:
- Only the CPU architecture their device uses (e.g. arm64-v8a for modern phones)
- Only the screen density their device renders at (e.g. xxhdpi for most modern phones)
- Only the language packs for their device’s locale (usually 1-3 languages, not 40+)
- Only the native libraries that match their architecture
- Only the asset packs marked as install-time (others load on demand later)
The result: a 150MB bundle becomes a 50-70MB user download. The user gets exactly what they need; the unused 80-100MB never crosses their data plan.
Bundling vs old-school APK delivery
Before bundling, Android developers uploaded a single APK file that contained EVERY architecture, EVERY density, EVERY language. The user downloaded all of it, even though their phone only used about 30% of the contents. That APK was sometimes called a “fat APK” because it carried so much dead weight.
App bundling replaces this with conditional delivery. You still upload one file (.aab on Android), but the store splits it into per-device installs automatically. Users download less. You ship faster. App stores like the math.
Why App Bundling Cuts Install Friction
Smaller downloads sound boring. The data behind them tells a louder story. Install funnel completion is the metric that matters, and bundling is the cheapest way to boost it.
Three business reasons bundling matters
1. Higher install completion rate. Every megabyte you cut from the download reduces the chance that a user cancels mid-download. On 4G connections in emerging markets, this matters more than UX polish. Tinder reported a 35% size cut led to a measurable lift in install completion across India, Brazil, and Southeast Asia.
2. Lower data charges for users. Users with limited data plans (most of the world outside Western Europe and North America) appreciate apps that respect their data. Smaller downloads mean better word-of-mouth and lower churn from “this app uses too much data” complaints.
3. Faster ad attribution. Ad networks count “install” only after the app launches once successfully. Smaller downloads = faster install completion = faster attribution = better-looking campaign metrics. Marketing teams notice this even when engineering does not.
What bundling does NOT solve
Bundling helps with download size, not runtime memory usage. An app that consumes 800MB of RAM still consumes 800MB after you ship it as an AAB. Bundling also does not optimize the code itself; you still need ProGuard/R8 for Android and Bitcode/LTO for iOS. Bundling is the delivery layer; code optimization is a separate concern that runs underneath.
For the install funnel specifically, bundling is the highest-leverage change you can make. Most other size optimizations (image compression, code splitting, removing unused libraries) save 5-15% each. Switching to AAB saves 30-50% with no code changes. The order of operations: turn on bundling first, then optimize.
6 Components Inside an App Bundle
Knowing what is inside the bundle helps you understand which parts can shrink. Each component has its own optimization strategy.
1. Compiled Code
Your business logic compiled to platform-native code. On Android this is DEX bytecode; on iOS it is native ARM machine code. Typically 20-40MB after optimization.
2. Image Resources
Icons, illustrations, photos packaged at multiple resolutions (mdpi to xxxhdpi on Android, @1x to @3x on iOS). Often the largest component for content-heavy apps.
3. Localization Strings
Text translations for every supported language. Small per language but adds up: 50 languages × 5,000 strings = significant size before splitting.
4. Native Libraries
.so files (Android) and .dylib files (iOS) for performance-critical code in C/C++. Compiled separately for each CPU architecture.
5. Asset Packs
Large media (videos, audio, ML models, game assets) that not every user needs at install time. Can be marked as install-time, fast-follow, or on-demand.
6. Dynamic Feature Modules
Whole features of the app that users may never use. Premium-only screens, admin tools, region-specific features can ship as separate modules loaded on demand.
Where the size savings come from
The single biggest win is native libraries and image densities. A typical Android app contains code for 4 CPU architectures and images at 5 densities. Users only need 1 architecture and 1-2 densities. That alone explains a 50-60% size reduction in many apps.
Localization comes second. An app supporting 40 languages has 39 unused language files for any individual user. Bundling drops those. Asset packs and dynamic modules are the third-tier wins for apps that have large optional features (games are the primary beneficiaries).
AAB vs APK vs iOS App Thinning
Three approaches to app delivery. AAB is Google’s bundling format. APK is the legacy “fat” approach Android used to use. App Thinning is Apple’s equivalent on iOS, achieved through a different mechanism. Here is how they compare.
| Dimension | AAB Android Bundle | APK Legacy Android | App Thinning iOS Universal |
|---|---|---|---|
| Platform | Android | Android | iOS |
| Required by store | Yes (since Aug 2021) | No (deprecated) | Automatic |
| File extension | .aab | .apk | .ipa (universal) |
| Splits per device | Yes (auto) | No (fat binary) | Yes (auto) |
| Architecture splits | Yes | All in one | Yes (Bitcode) |
| Density splits | Yes | All in one | Yes (Asset Catalogs) |
| Language splits | Yes | All in one | Yes |
| Dynamic features | Yes (modules) | No | Yes (On-Demand Resources) |
| Avg size reduction | 30-60% smaller | 0% (baseline) | 30-50% smaller |
| Sideload-friendly | Requires bundletool | Direct install | App Store only |
Why Android moved to AAB
Google made AAB mandatory in August 2021. The motivation was straightforward: the median Android app dropped 15% in download size, and aggregate Play Store data showed install completion went up across emerging markets. The friction of forcing developers to switch was worth the gains across the ecosystem.
Existing apps grandfathered with APK can continue to update via APK, but any NEW app on Google Play in 2026 must be AAB. There is no path back to “fat APK” delivery for new submissions.
How iOS App Thinning works
iOS approaches the same problem differently. You upload a universal binary (.ipa) to App Store Connect. The App Store processes it server-side and generates “thinned” variants for each device class (iPhone, iPad, Apple Watch, Apple TV) and each chip family (A14, A15, A17, etc.). When a user downloads, they get only their variant.
App Thinning includes three parts:
- App Slicing: separates code and resources by device family
- Bitcode (deprecated as of Xcode 14): was intermediate code that Apple could re-compile for new chip variants
- On-Demand Resources: large assets loaded after install when needed
The result is similar to AAB: 30-50% smaller user downloads compared to a universal install. You do not configure App Thinning on iOS; it happens automatically when you upload to App Store Connect.
8 Famous Apps and Their Bundle Wins
Eight well-known apps with documented size reductions after switching to bundling. Each case is from official engineering blogs or conference talks; the numbers are verifiable.
Adobe Lightroom
Netflix
Tinder
Uber
Airbnb
Spotify
The common thread: every one of these apps had specific contributors to bundle size (native libraries, image densities, language strings, optional features) that bundling could split off. The 20-60% reductions are typical for apps with global audiences, multi-language support, and varied device targets.
Dynamic Feature Modules and On-Demand Delivery
Bundling automatically handles the easy wins (architecture, density, language). Dynamic feature modules unlock the bigger wins: shipping features that not every user needs only to the users who actually use them.
How dynamic feature modules work
You split your app into a base module (always installed) and feature modules (downloaded on demand). The base contains the launcher, navigation, and shared infrastructure. Feature modules contain specific flows the user may or may not access.
Example for a typical e-commerce app:
- Base module: launcher, home feed, product browsing, cart, account (8MB)
- Checkout module: payment, shipping, confirmation (3MB, loads on first checkout)
- Returns module: return flow, photo upload (2MB, loads when user starts a return)
- Seller tools module: listing creation, analytics (5MB, loads for sellers only)
A buyer who never returns anything and never sells gets the 8MB base install. A power user downloads all modules over time as they use features. The user never sees a “downloading module” wait; the modules load in the background and become available within seconds.
Three types of on-demand delivery on Android
1. Install-time modules: Included in the initial install but separated for clean architecture. No on-demand benefit but easier to maintain in code.
2. On-demand modules: Downloaded when the user takes a specific action. The most common use case.
3. Conditional modules: Downloaded automatically when conditions match (e.g. user country is “US”, or device has 4GB+ RAM). Lets you target features without explicit user actions.
iOS On-Demand Resources
iOS has a similar mechanism called On-Demand Resources (ODR). You tag resources with categories like “level1-textures” or “premium-features”. Apple’s servers host these resources separately. Your app requests them at runtime; iOS downloads them transparently.
ODR works well for games (load level assets only when reaching that level) and apps with optional heavy media. It is less flexible than Android’s dynamic feature modules because it only handles resources, not code. Code-level modularity on iOS is achieved through framework loading patterns instead.
When to use dynamic modules
Use dynamic modules when:
- A feature is used by less than 30% of your install base (premium tools, seller flows, admin)
- A feature contains large assets (videos, ML models, game levels)
- A feature has substantial native code that does not need to be in the base install
- You have regional features that only apply to some countries (payment methods, ID verification)
Skip dynamic modules when the feature is small (under 1MB) or used by most users. The overhead of managing modules is not worth it for tiny savings.
How to Ship a Bundled App Without Coding
For custom-coded apps, bundling requires configuring Gradle (Android) and Xcode (iOS) plus testing per-device variants. No-code platforms handle the configuration automatically. Every app shipped through Appy Pie AI uses AAB on Android and App Thinning on iOS by default. Here is the flow.
Open the AI App Generator and describe what your app does. The platform scaffolds a project that will produce an Android App Bundle (.aab) and an iOS universal binary (.ipa) when you publish. No configuration files for you to edit.
The AI asks who your app is for and which countries you target. Based on the locale list, the platform configures language splits in the AAB so users only download their own language pack.
Each feature you add can be marked as install-time (always in the bundle) or on-demand (downloads when used). The platform automatically creates a base module and feature modules behind the scenes. You see “install-time” toggles; the platform handles the AAB module structure.
Deselect features you do not need. Every removed feature shrinks the bundle. The platform shows estimated install size at the bottom of the screen as you toggle features on and off. Aim for under 40MB base install for best conversion.
Click Publish. The platform produces .aab for Google Play and a universal .ipa for App Store Connect. Both files are pre-configured for optimal bundling. Google Play splits the AAB automatically; Apple App Thinning kicks in on App Store Connect upload. Users see the smaller download from day one.
What used to be a week of Gradle configuration, Bundletool testing, and CI pipeline work is now a setting. The platform manages every per-device variant, every language split, every density bucket. You focus on the product.
8 Bundling Mistakes That Bloat Downloads Anyway
The mistakes we see most often, drawn from analyzing thousands of bundles and public size-investigation blogs. Each has a clear avoidance strategy.
Shipping multiple architectures in the base
Forgetting to enable ABI splits, so every user downloads code for arm64, armv7, x86, and x86_64. The base install balloons 4x for no benefit.
Bundling unused resources
Old icon sets, deprecated illustrations, and dead translations sit in the resources folder. They still ship with every build.
shrinkResources true) and prune unused assets in CI. Tools like Lint and Knip find dead resources automatically.Using PNG when WebP/AVIF would work
PNG is 30-50% larger than WebP for typical UI illustrations. AVIF is even smaller. Apps that started before WebP support assume PNG is the default.
Shipping 50 languages when you serve 3 countries
Some app frameworks include every language by default. If your app only ships to 3 markets, the 47 unused language files still increase bundle size.
resConfigs "en", "es", "pt". iOS: only include needed .lproj folders.Not splitting heavy ML models
On-device ML models can be 50-200MB. Shipping them in the base install bloats first download and most users never need the AI feature.
Skipping ProGuard/R8 code shrinking
Without code shrinking, Java/Kotlin bytecode includes every method from every library you imported. ProGuard/R8 removes the unused ones.
minifyEnabled true in your release build. Configure proguard-rules.pro for any reflection-heavy libraries.Forgetting Android Asset Packs for game-style media
Games and content-heavy apps with large media (videos, audio packs, level data) stuff everything into the base install. Bundle exceeds 200MB; install conversion plummets.
Not testing bundles on real devices
You enable AAB and check that the file uploads. You do not test what users on different devices actually receive. Result: some users see broken builds because their architecture or density bucket was misconfigured.
Smaller Bundles. Higher Install Rates. Zero Code.
Every app built on Appy Pie AI ships with AAB bundling on Android and App Thinning on iOS configured automatically. Smart asset packs, language splits, and feature modules included.
Try AI App Generator App BuilderFrequently Asked Questions About App Bundling
What is app bundling in simple terms?
App bundling is uploading one comprehensive app file to the app store, then letting the store generate device-specific installs from it. Users download only the parts that match their device (their CPU architecture, screen density, language). The result is 30-60% smaller user downloads compared to the old “fat APK” approach where everyone downloaded everything.
What is an AAB file?
AAB stands for Android App Bundle. It is the file format Google Play requires for new app submissions since August 2021. The .aab file contains all the resources for every supported device variant. Google Play splits it into per-device installs automatically. Users never see the .aab; they download a smaller variant generated from it.
What is the difference between AAB and APK?
APK is the legacy Android delivery format where one file contained code and resources for every architecture, density, and language. AAB is the modern format where one upload generates device-specific installs server-side. APK still works for sideloading and existing apps; AAB is required for all new Google Play submissions.
How much can app bundling reduce my install size?
Typical reductions are 15-40% on the median app. Heavy apps with many languages and architectures see 50-60% reductions. Adobe Lightroom dropped from 158MB to 66MB (58% reduction). Tinder cut 35%. Spotify cut 23%. The exact savings depend on how much per-variant content your app has.
Does iOS use app bundling?
iOS uses a different mechanism called App Thinning that achieves similar results. You upload a universal .ipa to App Store Connect; Apple’s servers process it and generate variants for each device class (iPhone, iPad, Apple Watch, Apple TV) and chip family (A14, A17, etc.). The thinning happens automatically; you do not configure it.
What is a dynamic feature module?
A dynamic feature module is a separate part of your Android app that downloads only when a user actually accesses it. Common uses: premium-only features, region-specific tools, large optional content like videos or ML models. The base install stays small; the modules add capability when needed.
Do I need to write different code for AAB vs APK?
No. Your application code is the same. AAB is a packaging change in your build config (Gradle on Android). Once you enable AAB output, your existing code compiles into a bundle instead of a single APK. Dynamic feature modules require some code organization changes but they are optional; basic AAB is automatic.
Can I still distribute APK for sideloading?
Yes. You can generate APK files from your AAB using Google’s bundletool. APKs work for sideloading, internal distribution, and stores that do not support AAB (Amazon Appstore, Huawei AppGallery). The AAB is your master source; APKs are derived from it for specific channels.
Does app bundling affect app performance?
No. Bundling is a delivery format, not a runtime optimization. Once installed, the app runs identically whether it was delivered via AAB or APK. Bundling only affects download size and install completion. Code performance is a separate concern that bundling does not change.
Are there any downsides to using AAB?
Three minor ones: (1) Sideloading requires bundletool, which is one extra command. (2) Some legacy CI/CD pipelines need updates to handle .aab output. (3) You cannot test the AAB directly on a device; you use internal testing tracks or generate APKs for direct install. These are setup costs, not ongoing pain points.
How do I check if my app is using bundling?
On Android, check your build output for a .aab file (typically in app/build/outputs/bundle/release/). On Google Play Console, the app’s release page shows “Android App Bundle” or “APK” for each release. On iOS, App Thinning is automatic; you can verify by downloading your own app and checking the device-specific size.
Can I build a bundled app without coding?
Yes. No-code platforms like Appy Pie AI ship AAB bundling on Android and App Thinning on iOS by default. The platform handles every aspect: ABI splits, density splits, language splits, asset packs, dynamic feature modules. You describe the app; the platform produces the bundle.
Smaller Bundles Win the Install Funnel.
The fundamentals are simple. Use AAB on Android (required since 2021) and let App Thinning handle iOS automatically. Configure ABI, density, and language splits in your build to drop unused variants. Convert PNGs to WebP. Move heavy features to dynamic modules. Enable ProGuard/R8 for code shrinking. Test the actual delivered install on real devices before declaring victory. Most apps gain 20-40% install conversion improvement from these changes alone, and the work takes a day, not a quarter. Build smarter with our complete app creation guide or check our versioning guide for the release process every bundled app needs.
Build Smaller, Smarter Apps →Bundling Configured. You Build the App.
Appy Pie AI App Generator ships AAB bundling on Android and App Thinning on iOS automatically. Smart asset packs, language splits, and dynamic feature modules included with every app.
Build My App With AI4.7/5 on G2 with 1,388 reviews | 10M+ apps built since 2016