Stop Whining About Android App Bundles, They’re Great
Google have announced a change in the way that developers will upload apps to the Play Store. It may sound like a small, overly technical policy change but it actually has real-world impact. As the press euphemism goes, it has been met with mixed reactions…
As of August 2021, Google will no longer allow developers to upload their apps using the venerable APK format — the format that has been used since the very start of Android as an app installer. Instead apps will need to be sent to the Play Store by developers using Google’s proprietary Android App Bundle (AAB), and the Play Store will use the AAB to build APKs to send to devices.
This level of indirection, which technically gives Google the power to do what they want to your app, is what is causing the consternation. But it’s a decision that makes sense. AABs are better, because they allow you to deliver a better experience to your app users without any extra development work.
So what is an AAB?
An Android App Bundle is a file which explains how to build an APK for your app. When a user presses “Install” on your app, the Play Store builds and sends your device an APK, and your device installs it. The phone, for its part, has no idea on how the APK was built, and nor should it care: it just gets an APK installer like normal.
So why is this better than just providing a single APK to Google? Because with an AAB, Google gets to customise the APK to the device requesting it. And that really is beneficial.
A little explanation on what’s inside an APK is needed here. An Android app is essentially a box full of everything your app needs to run. This includes, amongst other bits, the programming code which tells it what to do, and resources such as icons, images and sound files.
Different Android phones require different sized resources. It’s all down to resolution and screen size. A modern phone with a 4K screen needs so much more detail in its images than a phone from 5 or 6 years ago, otherwise it’ll look pixelated in comparison to everything around it. On the other hand, an older or lower-spec phone won’t be able to cope with such large images (the app would run out of memory when in use), and so a separate set of images is required for them. In all, an APK typically contains 5 or more sets of images, of which your phone will only ever use one.
Other parts of the APK are similarly redundant; it’s not just about images. Sometimes for example we have to write specific code to support old versions of Android. If your phone has a newer version of Android, that code will never be needed.
So those parts can get pretty heavy, particularly if an app has a wildly different look to stock Android. With a static APK your phone will have to download and store all those redundancies. But with an AAB, Google gets to serve you a customised APK without them. That makes apps lighter to download and install, and smaller when installed. To the end user, there are only advantages.
This is, needless to say, all very good news for app store optimisation.
How about security and APK signing?
APKs have a very valuable feature: they can be cryptographically signed by their authors. This is the digital equivalent of a certificate of authenticity, proving that the APK you are downloading really does come from who it says it does. This is important, because it prevents bad guys from delivering a pretend update to your users.
With AABs, the cryptographic signature on any APKs built has to be performed by Google. That means developers have to pass their app’s cryptographic signing key to Google, and it’s this which is causing some consternation. Google has to be trusted, because it can now use that certificate to produce its own version of your app, or make changes without your consent. And of course if Google’s key store is ever exposed in a hack, then anyone else could do the same.
This is pretty normal in the industry, though. Apple sign all their releases, not the developers, so there’s even less control on that platform. Microsoft do the same. It only affects apps distributed through the Play Store, so if you distribute your app via other means then you’re perfectly welcome (in fact, encouraged) to use a different signing key for that purpose.
It sucks to have to put your trust in any third party. I get that. But in distributing your app through the Play Store, there’s a lot you have to trust Google for anyway, and I’m not convinced that the signing key issue is a particularly big jump. You arguably already put more trust in your back end provider like Firebase, Azure or AWS.
And there’s an added, fairly significant, benefit to storing your signing key with a third party. Which is that you won’t lose it! On more than one occasion we’ve taken on a client whose signing key has been lost to time, and it’s a massive problem. We are not able to produce any new versions of their app; instead, we have to start again from zero with a brand new app and brand new audience. This applies even when we’ve got all the source code. With an AAB, Google holds the relevant signing key, so there is a process to go through to get it back (or to change it).
This only affects the Play Store
Of course, Google’s decision only affects apps uploaded to the Play Store. The thing I truly love Android for is that it isn’t inextricably controlled by any particular app store, or indeed any particular large corporation. If I wanted to build you an app, then I will always be able to build an APK and send it to you, all without Google’s involvement.
The technical changes you need to make
All apps, including updates to existing apps, will need to be delivered as an AAB to the Play Store. For most developers that’s as easy as choosing the right option during build in Android Studio. If your app developers don’t use Android Studio, they will need to ensure their toolchain supports building AABs.
In conclusion…
Uploading your app to the Play Store as an AAB will produce a better experience for end users, particularly those with older devices. Apps will download faster and take less storage space once installed. There is a process to follow if you lose your signing key, ensuring the future continuity of your app. You have to allow Google a moderate trust level for it to work, which is of course undesirable, but I don’t see it as a huge risk.
Tom Colvin is CTO of UK app development agency Apptaura. Together with his team of developers he builds apps for businesses across a range of industries, from SMEs and Start-ups through to multi-national global organisations.
