What a new publishing format means for the future of Android

The Android App Bundle is a better way to package your app

Android’s first 10 years

  • Step 1: You write the code for your app in an IDE, such as Android Studio.
  • Step 2: When you’re ready to test or release the app, you build it as an APK, Android’s app format. As part of building the APK, you digitally sign it with an app signing key. Signing an app means securely attaching a unique certificate to it. This is a mechanism that ensures you’re the only one who can continue to update installed copies of this app. How does this work? Before updating an app, Android always checks that the unique certificate of the update matches the unique certificate of the app on the device. It will be clear later why I’m spelling this out.
  • Step 3: You upload your signed APK to a testing track using the Google Play Console. When you’re ready, you release your app to the production track and to the world.
  • Step 4: Google Play distributes your signed APK, precisely as you uploaded it, to each user’s device when they install it.

The ‘big’ problem

The ‘small’ solution

Smaller installs

  • Step 1: You write all your code for your app in an IDE such as Android Studio or a games engine such as Unity as you normally would.
  • Step 2: Now, when you’re ready to test or release the app, you build it as an Android App Bundle, Android’s new app publishing format. You still sign the app so that Google Play can verify it’s from you.
  • Step 3: If you haven’t already, you opt in to Play App Signing. If you’re releasing a new app, you can do this in a one-click process when you upload your app. When you opt in, Play designates the first key you used to sign your app bundle as the upload key. This is just for security identification purposes and, if you ever lose it, you can contact Google to verify your identity and reset it. For existing apps, you need to visit the app signing page in the Play Console and securely transfer your app signing key to Google Play. Why do you need to do this? Continue to step 4 to find out.
  • Step 4: When you upload your app bundle to Google Play, Play processes it and generates split APKs signed with the app signing key for every possible device configuration and language that you support. Split APKs are an Android platform feature introduced in Android L. As long as each split APK is signed with the same key, the Android platform will treat them as one app. You can think of a split APK as ‘part’ of an APK: to run the app, the device treats all the parts as a single app.
  • Step 5: When a user installs the app, Play delivers the base split APK (all the code that’s common for every device), the language split APKs (for the languages the user speaks), and the device configuration split APKs (for the device’s screen size and the CPU architecture). This means the device gets just what it needs without wasted space. For updates to be accepted by the device, every release’s split APKs must be signed with the same app signing key as the original app install.
  • (Step 6: Once your app is installed on a device, Play will deliver additional split APKs on demand when, for example, a user changes their device language or when a user wants to use a dynamic feature module, I’ll talk about these later in the post.)

We switched to the app bundle and uploaded our first internal release within an hour.

Swiggy ~23% size saving

The app bundle saves us time now that we don’t have to use multi-APK.

redBus ~22% size saving

Including assets for 20+ languages was increasing our app size and noticeably reducing our visit-to-install conversion rate before we started using the Android App Bundle.

Riafy ~37% size saving

Dynamic features

  • Large features not needed at install: You can load these on demand or tell Google Play to defer installing them, which means installing them in the background. You can load features up to 100MB this way. Advanced features or add-ons that aren’t core to your app experience at launch are good candidates here such as premium features for paying users, personalization options, AR functionality, and so on.
  • Features for specific audiences: Instead of including features for every audience using your app, you can carve them out as dynamic feature modules. For example, commerce apps could isolate selling functionality in a dynamic feature module so only the buying functionality gets delivered to every user at the point of install. The small percentage of the audience who need selling functionality can download and access it when they need it. Some developers are also exploring dynamic features as a way to avoid having many variants of an app targeting slightly different audiences. Instead, they can consolidate and offer one app while moving the tailored functionality for each audience into dynamic feature modules.
  • Rarely used features: Another good use of dynamic feature modules is for functionality that’s rarely used or used once. For example, if your app has a one-time ID verification or credit card scan, then loading this on demand and uninstalling it immediately after its use is an efficient way to avoid adding to the size of your app at install. It also avoids taking up space for something that’s not being used for the lifetime of your app (remember larger apps are more likely to get uninstalled).

Instant discovery

Faster updates

Smaller, better, faster, fresher

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store