Android App Bundles: Why You Should Have Switched Already

What you actually need to know

• App bundles cut average install size by twenty to fifty percent.
• Smaller installs mean fewer abandoned downloads, especially on slower networks.
• Switching is a one sprint engineering task for most teams.
• Play app signing is required and is the right tradeoff for most teams.
• In my experience, the install rate lift after switching is the easiest performance win Android shipping has offered in years.

The core argument

Mobile install size matters more than founders think. A user clicks install on the Play Store. The app starts downloading. If the download is large and the network is slow, the user has time to change their mind. The bigger the install, the higher the abandonment. Google has published numbers on this. So have many large publishers. The pattern holds across markets.

App bundles fix this by serving each user only the parts of the app they need. Their device locale, their screen density, their CPU architecture. The user downloads a smaller file. The install completes faster. The abandonment rate drops. The store rating improves because more users complete the install in the first place.

This is not a controversial technology choice. It is a default. New apps have required bundles since 2021. The teams still shipping universal APKs in 2026 are usually doing it for legacy reasons, not technical reasons. Once the team understands the migration is a sprint and the gains are permanent, the case for delay disappears.

The friction that remains is mostly cultural. Some teams are nervous about Play app signing because Google holds the signing key. The risk is real but small. Google publishes detailed key management practices. The convenience for the team is significant. For most products, the calculus is in favor of switching.

What the migration looks like

The build pipeline changes from producing APK to producing AAB. Most build tools, including Gradle and Fastlane, support this with a single flag change. The CI pipeline uploads the AAB instead of the APK. Play does the rest.

If the app is older than 2021 and has never used bundles, you may need to opt into Play app signing. The process takes a few clicks in the Play Console and a few hours of waiting for the certificate update. Once it is done, future releases just work.

Testing the migration is straightforward. Upload the bundle to a closed track. Install on real devices via Play. Verify nothing is missing. The behavior is identical because the bundle contains everything the universal APK contained, just split across delivery slices.

What it actually costs

Total elapsed time for most teams is one to two sprints. Engineer time inside that window is usually under a week. The payoff in install completion rate is permanent.

Features to enable while you are migrating

• Dynamic delivery for rarely used features. Keeps the base install small.
• Asset packs for large media. Lets the app deliver media on demand instead of bundling it.
• Locale on demand. Ship only the locales the device needs. Most apps see real savings.
• Density slicing. Ship only the image density the device needs.
• Architecture slicing. Ship only the native libraries for the device's CPU.

Expert opinion

Switching to app bundles is the easiest performance win available to Android shipping. The migration is a sprint, the lift is permanent, and the user experience is better on every device. Teams that have not done it yet have no good reason to keep delaying.

>

Yashveer Singh, founder of Yashveer Labs

How this plays out in practice

On a client Android app I worked on last year, switching from universal APK to app bundle reduced average download size from eighty four megabytes to thirty seven megabytes. The install completion rate jumped by roughly fifteen percent in the first month after the switch. The Play Store rating moved up slightly, partly because more users were completing the install and rating the app, partly because the perceived install experience improved.

The opposite story is teams I have advised to migrate who chose to wait. Each quarter they had a reason. Each quarter they were paying a tax on every install. The migration is the kind of work that pays back in week one and keeps paying back forever. Delaying it is not a strategy.

For more on the broader mobile shipping topic, see the mobile build pipeline Fastlane EAS and the path of least pain and app versioning strategy why force update is a last resort. For app store optimization, app store optimization for founders who hate marketing covers the broader install funnel.

Common mistakes teams make

1. Treating the migration as a major project. It is a sprint.
2. Avoiding Play app signing for fear of losing control. The control loss is small and the convenience is large.
3. Skipping dynamic delivery for features that would benefit from it. The lift in base install size is real.
4. Not testing on real devices through the Play closed track. Local installs do not exercise the bundle path.
5. Forgetting to update the CI pipeline to upload AAB instead of APK. The pipeline failure is annoying, not catastrophic.
6. Continuing to support old APK only branches of the build long after the migration. Delete the old paths.

Where to start, a 7 day plan

1. Day one. Update Gradle or your build tool to produce an AAB. Verify it builds locally.
2. Day two. Opt into Play app signing. Wait for the certificate update.
3. Day three to five. Upload to a closed test track. Install on three to five real devices spanning Android versions and OEMs. Verify everything works.
4. Day six. Roll out to ten percent of production users. Watch crash reports and ratings.
5. Day seven. Full rollout. Update your release documentation. Delete the legacy APK build path.

For related reading, react native new architecture what founders should know covers the cross platform side, and the mobile app privacy manifest what apple now requires covers the iOS analog of similar shipping discipline.