Apptaura – the app development agency

Android AABs

What are Android App Bundles and what do they mean for my apps?

From next month (August) Google will require all apps in the Play Store to be supplied as Android App Bundles, rather than as APK files. But what is an Android App Bundle? What does this mean for any of you who are looking to submit a new app to the Play Store? Do you need to resupply your app if it is already on the app store?

Easy stuff first. An Android App Bundle (AAB) is essentially a replacement for Android Application Packages, more commonly known as APKs. It is Google’s official publishing format for apps, and AABs have actually been around for a while, initially rolling out back in 2018.

So what has changed?

Well, from August 2021, all apps being supplied to the Google Play Store need to be supplied as AABs. Google is officially retiring the venerable APK format. Unfortunately,  that could mean that if you’ve got an old app happily pootling along on the Play Store you’ll need to resupply it in the new AAB format.

Why the sudden move to Android App Bundles?

It might feel sudden, but this is anything but that. Android App Bundles have been around since 2018. There are already over a million apps using app bundles in the store, including most of the really big hitters in the App Stores. Although it’s probably not much of a surprise that big tech and app firms have already adopted AABs. They knew the change was coming and Android App Bundles are particularly suited to big consumer apps with a wide range of demographic and device requirements. In other words, if you want your app to appeal equally to someone with a 5-year old battered phone and to someone with the newest, flashiest smart phone… you’ll probably want to roll your app out as an AAB as quickly as possible.

What is so great about Android App Bundles?

This is the clever bit. When you submit an AAB Google Play will use it to build and serve bespoke APKs for specific device configurations. ARGH! But what does that really mean in practice Apptaura? Well… phones, particularly Android phones are a varied lot. They come in all shapes, sizes, screen resolutions etc. Historically when you built an APK you had to supply a range of assets for every possible configuration, from tiny screen sizes up to larger ones. That meant you often had to supply the same stuff over and over again. Simple stuff. Like a photo. If you used a smaller photo on a big screen it would be blown up and look shoddy. So you’d supply the image numerous times. All of which would come together and bloat out your app. Bigger to download. Slower to download. Taking up more precious storage space.

With old APKs customers would have to deal with bigger file sizes. So more customers lost during the download process. More customers choosing not to download your app then and there because of concerns about download limits etc. A greater chance of customers deleting your app if they don’t use it regularly as it’s taking up a larger chunk of storage space.

Supplying an app via AABs means that your app will be perfectly optimised for the device you’re actually using. Less bloat. Faster to download. Better for your customers.

Sounds cool!

Yep, that’s what we thought. There are some other neat features knocking about though – one of which is the ability to be able to customize feature delivery and user experience based on the devices and users that you choose. So you can build out new feature sets dedicated to specific devices or devices running a specific version of Android. That’ll allow you to test features – say for example with a 5G phone… or will serve as an upsell to encourage users to upgrade their OS by offering new features only to new OS versions. If you’re a global organisation you can roll out country-specific features – no need for multiple instances of an app based solely on geographic location.

From a more techy perspective we’ve found the speed up our development velocity and our ability to roll out updates and new versions.

So why all the angst about Android App Bundles?

Well obviously it is a change, so you’re venerable app will need to be resupplied. But that’s actually a pretty straightforward task. New apps will also have to packaged up differently… but again it isn’t much of a change and the benefits certainly pay off.

However, what has got a few people riled up is the change to the way you cryptographically sign your app. Historically as an app developer you essentially signed your app – it was a certificate of authenticity proving that the APK being downloaded did come from who it said it came from. Which protected your customers from bad guys delivering a pretend (and malicious) update under the guise of your app. That’s changed. Google are now responsible for the AAB and delivering the ultimate APK to the user. They sign that APK. Which means as developers it can feel like you’re losing control.

It sounds worse than it is. Google is actually bringing themselves in line with standard practice. Apple already do this. So do Microsoft. We actually see this as a benefit – you won’t lose your signing key! We’ve taken on a number of clients with heritage apps who no longer have access to their signing key and it causes no end of issues. You’re unable to update your app and have to basically rebuild and relaunch your product, with all the cost, hassle and issues regaining customers that causes. Now Google hold it, so there is a process you can go through to regain access to your app.

What else do we need to know?

Good news… and possibly some bad news about AABs. The great thing about Android is that it isn’t a completely closed ecosystem. You can still sideload apps from other sources. From other app stores. And your old APKs will still work for that. The flipside is that all the cool customisation that Google does with your AABs is locked into the Google Play store. So to allow clients to download your apps from third party stores you’ll need to supply an APK, not an AAB.

Conclusions…

AABs are coming. And they are great for your users and your customers.

Useful resources:

Got a legacy app that you need to replace or upgrade? Give us a shout. We can help.