4. Strategies for Release

Written by Fuad Kamal

In the previous chapter, you learned how to distribute your app internally to your team and expand your distribution through Closed tracks or Alpha testing. In this chapter, you’ll complete the app publishing process and discover additional ways to distribute your app. You’ll also go through the Beta testing process to make sure your app is ready to share with the world, and finally, release your app to production.

Version codes

Before moving on to Beta testing, take a quick look at using version codes through the different release phases. Typically, you want your Internal release to have the highest version code since it should be testing the most recent changes. Your Alpha release will have the next highest version code, followed by Beta release. Production will have the lowest version code.

Note that some users may be in the Alpha group only, Beta group only or in both tester groups.

Here’s a typical lifecycle an app might follow through the first few releases:

1. Release version 1 to internal testing.

2. Internal testers install version 1 and complete testing.

3. Promote version 1 to Alpha.

4. Alpha testers install version 1 and complete testing.

5. Promote version 1 to Beta.

6. Beta testers install version 1 and find some issues.

7. Address issues in version 2.

8. Release version 2 either to internal track or directly to Alpha.

9. Beta only testers continue with version 1. Alpha testers update to version 2.

10. Version 2 testing is complete.

11. Promote version 2 to Beta. Beta testers update to version 2.

12. Release version 2 to Production, which means users can download it from the Play Store.

13. Release version 3 to internal track.

14. Internal testers update to version 3. Alpha, Beta only testers and the general public remain on version 2.

Open test track

As you’ve seen, closed testing is great for when you want to test your app with a set of trusted testers. But typically, the problem with those users is they’re not representative of the population of production users. Production users have a wider set of devices, but they might not be as motivated as trusted testers and may engage with a different set of features on your app. When you want to have broad coverage of your code, find technical issues or get more relevant business metrics, you can use Open testing.

Releasing to open testing allows any user to discover and join your testing community directly from the Google Play Store app on their device. These users can provide private feedback you can review in the Play Console. This type of feedback won’t affect your public app ratings.

Opening testing is a great way to scale up and make sure the new version of your app provides a great experience to users before you launch it to the world.

You can cap the number of testers or users that can join the open testing program to keep things manageable.

Launch your beta release

In the last chapter, you promoted your internal release to a closed track Alpha release. Optionally, you might have also posted new builds or created multiple closed tracks. Now you can promote one of your alpha releases to the open test track as a Beta release, or post a new app bundle into a new open test track. Try the former.

In the Play Console menu, click Closed testing. For one of your Alpha releases, click Manage Release. Then click the Promote release link and examine the available options:

In the example above, you can promote the closed test build PodPlay 3 Alpha Release 1.0.0 either to another available closed track or directly to production. However, there isn’t an option to promote it to an open test track yet. That’s because you need to create the test track before you can promote an existing build to it.

In the Play Console menu, click Open testing. Then click the Start track link to the right of the Beta track summary.

Go back to the Alpha track from the previous step. Now you can promote the release to Open testing in addition to other Closed Testing tracks and Production. Click Open testing from the options.

You’re taken to the Create open testing release page. The process is similar to creating the Closed release. Like before, you need to select countries and regions where your release can be tested. However, now you don’t need to select any test groups since the Beta will be available to the general public via the Google Play Store.

In the Testers tab, you can select Unlimited testers or limit the number of testers, where the minimum number of testers is 1,000. Fill in those details and provid a feedback email address for the testers. Now click the Start rollout to Open testing button. Play Console presents you with a confirmation dialogue, warning you anyone can now test your Beta release.

Click Rollout to release your Beta. Congratulations! Once it passes review, your app will be publicly available to test in Beta.

Pre-launch report

Before promoting one of your test builds to Production, you should take some time to review the pre-launch report.

The pre-launch report takes the app builds you publish to the Play Console and installs them on up to ten different devices. It runs your app for five minutes at a time with robo for nearly an hour of testing in total. It shows crash reports, performance issues and security vulnerabilities.

In the Play Console menu, click Pre-launch report -> Overview.

In the Overview section, you’ll see a summary of all the issues in your app, divided into categories for stability, performance, accessibility and security and trust. From there, or in the Details section, you can dive into the details of each report.

Under Pre-launch report -> Settings you can set credentials for testing your app, deep links from which to test your app and which languages to test your app in. The Settings section Pre-launch report also has options to control the way your app is crawled, such as robocall scripts and demo loops for games. For more information about this, see the Google I/O 2018 video on Pre-launch: https://youtu.be/zTy-ur1Wnq4

The pre-launch reports can provide valuable information about how your app is performing on real devices. You can see screenshots of your app running on a large variety of devices, security scan results as well as performance and crash reports.

The Pre-launch section can provide valuable insights into how your app runs on actual hardware devices even before testers download it. To automate testing your app on more than ten devices, and for more options than are available in the Pre-launch section, you can leverage Firebase Test Lab. You can also integrate Firebase test lab with your CI/CD toolchain. For more information on Test Lab see Beyond Pre-Launch Reports in the Firebase documentation: https://firebase.google.com/docs/test-lab/android/test-lab-play

Rollout & quality

So you’ve tested internally, then in closed groups and finally, using open testing. You’ve polished the user experience, optimized business metrics and ironed out bugs and performance issues. You’re confident this new release has it all. The only thing left to do is roll it out to the public.

At Google I/O 2017, Google announced the Android App Bundle. They also introduced the Bundle Explorer to the Play Console to help you understand your APK or bundle contents. It provides useful insight into the sizes of your APKs. Keeping your APKs as small as possible means users can download and install faster and have more free space left for other things on their devices.

On average, apps see a 20% size reduction by using Android App Bundle. The Bundle Explorer can show you the size savings you can achieve.

Google recommends using staged rollouts when releasing an app to production. As you’ve now seen, staged rollouts let you control the percentage of users eligible to update and gradually increases this as your confidence in the release grows. If something goes wrong, you can also halt the release so only a small percentage of users are affected.

You can further extend staged rollouts with the country targeted rollout option. This lets you rollout per country in addition to rollout by percentage. This option is useful for starting your release in a market that you have a deep understanding of. It also makes it easier to understand your business metrics as the rollout progresses.

Once your release is rolling out, you can use the Quality section in the Play Console to monitor key metrics, such as app ratings, as well as crashes and ANRs. These metrics help you evaluate your release and ensure it remains healthy as you proceed with the rollout. For more about ANRs, checkout the Android documentation: https://developer.android.com/topic/performance/vitals/anr

In the Vitals page you can check metrics like battery usage, jank, stuck wake locks and others. You may not have much data there now, but once you start testing your app, be sure to check out these features in the Play Console menu under Android Vitals -> Performance. For more on jank and stuck wake locks, checkout the Android documentation:

• https://developer.android.com/topic/performance/vitals/render
• https://developer.android.com/topic/performance/vitals/wakelock

Release to production

Once the Alpha and Beta testing are complete, you’re ready for the final release to Production! This is as simple as promoting the final Beta version to Production.

To create your production release, click Open Testing in the Play Console menu. Then promote your release as before, only this time select Production from the Promote Release menu.

If you hit the Create new release button in the Production menu instead, you won’t be able to promote your Open track release since you can only have one production release at a time. If you did that by mistake and wanted to promote your Open track release instead, simply discard the draft production release first.

Publishing API

For automating APK deployment with continuous integration systems or using Gradle plug-ins, Google has provided the Publishing API. Rolling out a release via the API uses the same release model you’re now familiar with from the Play Console. This lets you name your release and more easily modify release notes. The APT also supports the testing tracks mentioned earlier. This is great for configuring your continuous integration system to push through your internal test track whenever you have a new build ready for QA.

It’s possible to halt a release using the publishing API. This lets you fully automate your release process, including automatically responding to problems.

You can also manage draft releases via the API. So you can stage a draft release from your CI system and then have your product manager login, check that everything looks good and hit confirm and Rollout.

You can find the full API details and the associated client libraries here: https://developers.google.com/android-publisher.

Making use of the Google toolsets

There’s great diversity in development team sizes, and user base sizes and app needs differ accordingly. Some apps have small developer teams, with maybe ten or fewer people, while others have hundreds or even thousands of developers. Smaller apps need ways to scale rapidly to a growing user base. Larger apps need ways to innovate safely and quickly. But all apps have a few needs in common:

1. Each app is constantly evolving.
2. Each app needs to add new and exciting features and adapt quickly to user feedback.
3. All app development teams would like to avoid bad updates and their implications.

There are some common tools and best practices that scale well from the smallest to the largest apps.

You need to ensure you can listen to your users and their feedback. You need to make sure you can maintain, validate and improve the key user and business metrics. And you need to optimize the technology to avoid bugs and performance issues while supporting incredibly diverse users and devices.

How do you scale? As a team grows in size and ambition, how do you continue to achieve good release attributes while still moving quickly?

There are a few strategies for creating a consistent process that scales well, even for deploying the largest apps. In this section, you’ll learn some strategies to test new features and release your app’s next versions.

Testing

You could test by always putting the raw, most bleeding-edge features into your Alpha track. This would ensure the team members could stay in tune with the latest and greatest features as the app progresses. However, as the team grows, this type of strategy can cause problems.

Teams need to be able to move quickly, experiment and occasionally break things. But product managers need fresh and stable builds to show off the latest features to upper management or other stakeholders. You may have a demo that has a lot of the new features. No one enjoys live demos that fail!

With multiple testing tracks, you can give individual teams their own builds where they can experiment independently of each other and the release process. They can deploy daily or even hourly if they wish, to share the latest features among themselves. You can also set the testing track’s country availability to global to allow testers in any country to test your apps, even if the released product isn’t globally available yet.

Multiple tracks also let you have a more thorough testing process at release time. By using individual team tracks, teams can test new features independently before you cut the final release. Once you’re ready to release, you promote your build through multiple stages of testing, starting with a team-wide test of tens of people, to a company-wide test with thousands of users, and then a public, open beta with potentially millions of test users.

The open beta allows external users to try your latest and greatest features if they’re willing to give you private feedback. Users can join directly from the store listing in the Play Store app. The open public Beta gives high volume, external feedback on a slew of device and platform combinations and real-world use cases.

Testing isn’t just about mitigating the risk of bugs and crashes. It’s also a chance to get feedback on features and ensure new features have the right impact on key performance indicators.

You might be wondering, why go through all these various stages of testing?

Why not go straight to open beta?

Well, you might want to test out some confidential new features before they’re visible to external users.

Why have both a team-wide test and a company-wide test?

It’s good to establish a tradition in your organization of dogfooding your apps. Dogfooding is the practice of a company or team uses its own products. You might not want to break the app for everyone in the company when you’re testing out new features.

Why might you still need an open beta if you have a large company and do a company-wide test?

Even if a company-wide test can reach thousands of users, these users may tend to have a somewhat narrow set of Android devices, and they may have a narrow set of use cases or behaviors as compared to the general public. An open beta gives you much more scale and a device set that’s more representative of your production users.

So, that’s testing. You’ve validated your feature and your app update. Now, how do you roll out these updates and features to users? Read on to find out in the next section!

Feature rollout

A staged rollout is critically important to app development teams at large companies with mission-critical apps. Rather than updating billions of devices at once, you always want to start small and ramp up incrementally, keeping a close eye on business, user and crash metrics. At the first sign of any issues, you can always halt a release.

But how do you actually manage these releases?

One method for managing an app release is to wait until all the features scheduled for that release are ready, then cut and roll out the release. Does this sound familiar? This is how things work at quite a few large companies. It might seem to work most of the time, but unfortunately, features sometimes hit a snag, causing delays to all the other features scheduled for the release.

Soon, a January release can become a February release. And then you’re pooling more and more features into that single release. More features lead to more testing, more bugs, more release candidates and more changes that make it hard to track down exactly what caused any particular bug or performance regression.

Additionally, since the next release might be a while away, developers scramble to get their features onto the release. Then in the meantime, you may discover you need to ship an urgent bug fix that can’t wait. As the team scales, this cycle tends to spiral out of control.

However, you can avoid all the resulting stress from such situations.

Waiting for all the features to be ready slows down innovation and adds a lot of risk to the app release. So while it might seem counter-intuitive at first, releasing faster is safer. Keeping a continuous and predictable release cycle makes each release smaller, safer and easier to manage. And you can get those urgent bug fixes released quickly and painlessly.

Interestingly, when developers know the next release is only a few weeks away, they tend to avoid cramming their almost, but not quite, finished features into a given release.

So, this all sounds great, but how does it work in practice? How do you keep the release cycle running on time? And how do you ensure new features don’t go live before they’re ready?

Firebase Remote Config

You can use flag-guarded feature development to safely put out features in an app release. Google uses this technique internally for its app rollout cycles. Whenever possible, they try to avoid shipping new features directly with an app update. Google puts each feature behind a flag that can be toggled on and off from the server.

First, use the staged rollout to release the app update with all the flags turned off. By first deploying such a change neutral binary, it’s easier and safer to get this update to all of your users. This also lets you evaluate the app binary itself, for things like stability and system health, as it installs on the user’s device separately from the feature and how it’s doing.

Once you deploy this change-neutral app update, you can then slowly enable each feature by turning on the flags. Carefully keep an eye on all important users, business and crash metrics to detect any issues. If you do detect any issues, you then can disable the feature by turning off the flag. This technique ensures an issue with one feature won’t adversely affect all of the app update’s other features.

One way to implement this type of technique is by using Firebase Remote Config.

Firebase Remote Config isn’t limited to Android. So, your company could use it for both your iOS and your Android deployments. Firebase Remote Config moves much of the release cycle process you might typically go through with multiple app builds into the cloud. You can deploy changes to small, and then progressively larger, segments. Or you can perform A/B testing to evaluate if a change you’re making is a good choice.

By circumventing the need to release multiple builds, it can enable you to roll out changes in minutes rather than days or weeks. You use Firebase Remote Config in conjunction with Firebase Analytics, formerly known as Google Analytics, to get real-time feedback on your rollouts.

For more information about Firebase Remote Config, see: https://firebase.google.com/products/remote-config.

Following the techniques outlined in this chapter and the previous one, Google maintains a bi-weekly release cycle for apps with user bases numbering in the billions of users.

Production release

Once the Alpha and Beta testing are complete, you’re ready for the final release to Production! This is as simple as promoting the final Beta version to Production.

Go to the App releases ▸ MANAGE BETA section and click RELEASE TO PRODUCTION.

This creates a release in Production and displays the release screen to verify the details. As with the Alpha and Beta release, you need to review the release information before publishing it to the Play Store.

When you’re ready, click REVIEW. If everything checks out, you’ll see the START ROLLOUT TO PRODUCTION button.

For first-time app publishers, this can be both an exciting and stress-inducing moment. The app you’ve worked so hard on will finally be available for the public to enjoy.

Don’t be nervous. Click START ROLLOUT TO PRODUCTION.

Pay attention to any warnings that may crop up. If everything looks good, click CONFIRM.

Within a short amount of time, your app will be live in the Play Store. Celebrate! Throw a launch party and spread the news about your first published app.

But don’t party too long, because you haven’t finished yet. Like a newborn child, you can’t leave your production app on its own. It needs some tender loving care and attention to thrive!

Post-production

Here are some final tips to help keep your app in top shape.

• Review your app stats on a regular basis. The Play Console provides a wealth of information about the number and types of installs, number and frequency of crashes and overall ratings. Look for spikes or drops in any of these categories to stay on top of changes. Don’t assume items will fix themselves: Be proactive and address issues as soon as they appear. See Chapter 14 for a deep dive on this topic.

• Check reviews and look for problem trends. Even the best-made apps will inevitably get some negative reviews. Look for common threads in the reviews. If several users all complain about the same thing, that’s an excellent hint to focus on that issue.

Positive reviews can also provide valuable feedback about what you’re doing right and help drive future product development. You can also respond to user reviews using the Google Play Developer Reply to Reviews API, found here https://developers.google.com/android-publisher/reply-to-reviews, or in the Google Play Console.

See Chapter 13 for a simple yet extremely effective strategy to generate positive reviews and get direct user feedback instead of negative reviews and the dreaded one-star ratings.

• Be aware of new Android releases. In some cases, a new Android OS release can impact how your existing app performs. Make sure to keep up with beta releases of the Android OS, and make sure your app performs as expected before the OS is released to the public.

• List well-known issues. If you have issues that are known and you can’t fix them quickly, consider mentioning them in the Play store description along with a workaround if possible. It’s better if users know about these issues rather than being surprised after they download the app.

• Consider using staged rollouts. You’ve covered staged rollouts and their benefits in-depth in this chapter. When using staged rollouts, you specify the percentage of users to update to the new release. You can also limit the update to specific countries. For the first release, you might consider rolling out to a single, smaller country before targeting your primary countries.

Other publishing methods

In some cases, you may need to distribute an app without going through the Play Store. It might be an enterprise app that will never go public, or it might be a side project you’re distributing to friends and family.

There are a few ways to distribute an app directly.

Email distribution

Email requires the least amount of work on your part. All you do is attach the APK file to an email and have your users open the email on a compatible Android device.

Users will need to configure their devices to allow unknown sources before installing the APK. It’s a good idea to include instructions in the email when sending out the APK.

If a user is running Android 8.0 or newer, they should look for the Install unknown apps section in the device settings.

If a user is running a version before Android 8.0, they should enable Unknown sources in the Security section of the device settings.

When the user opens an email with an APK attached, they can download the APK.

The user can then find the APK in their downloads app or by pulling down the notifications view. When they tap the APK file, they’ll be prompted to install the app.

Website distribution

Another option is to host the APK file on your website or a cloud share service such as Dropbox, Google Drive or Slack. You can either send a link to the download location or point the users to the download page on your site. Whether the user taps the link from an email or the browser on the device, they’ll be prompted to install the APK.

As with email distribution, the user must configure the device to allow unknown sources.

Other app stores

There are some other app stores available for publishing your app. You may want to take time to explore which options are available.

One of the most well-known stores is the Amazon Appstore. Amazon devices such as the Fire TV and Fire Tablet come with the Amazon Appstore by default. It contains apps made especially for Amazon products as well as many apps also found in the Google Play store. There’s no registration fee for developers on the Amazon Appstore, and it also offers some unique monetization models.

There are some fundamental differences between Google and Amazon in the way apps are purchased and how in-app billing is handled. However, in both cases, you’ll get 70% of the app earnings.

One big difference is that you can’t switch a free app on Google Play to a paid one. You must make that decision during the initial rollout. Amazon lets you start your app as free and change to paid at any time. The Amazon App store process is a bit more involved and requires you to wrap your APK in their code.

You can always start by releasing to the Google Play store and then decide later if you also want to distribute the app to other app stores.

Key points

• You’ve seen why releasing is an exciting time and how to think about what constitutes a great release. A great release delights users, improves business metrics and is stable and performant.

• You took a look at the suite of tools the Google Play Console makes available to help you achieve efficient, well understood and low-risk app releases.

• You learned about the internal test track for fast, iterative testing with your team and testers.

• You looked at closed testing, where you get to control who can test your app. You saw how you can go beyond Alpha and Beta testing with multiple closed testing tracks.

• You learned how to best leverage open testing where any user can opt into testing your app directly from the Google Play Store. You’ve seen how this can bring massive scale to your app testing. You also looked at how to roll out your releases, the different areas of the Play Console, staged rollouts and a glimpse of the publishing API for automating your releases using Gradle and continuous integration tools.

• Finally, you saw an overview of Google’s strategy for creating a consistent release process that scales from the smallest to the largest teams, and how to implement it yourself using Firebase Remote Config.

Where to go from here?

As mentioned earlier, developing and publishing your app is just the beginning. In the rest of this book, you’ll dive deep into what lies beyond the app release.

In this and the previous chapter, you received a broad overview of the Play Console, a more in-depth look into Test Tracks and many of the things you need to pay attention to before releasing your app to production. Another aspect of Play Console is monitoring and promoting your app after releasing to production. This includes the Grow and Quality sections of Play Console and Play Store discovery. You’ll learn more about that in section four of this book. You can also check out the Google Play playlist on YouTube: https://www.youtube.com/playlist?list=PLWz5rJ2EKKc9Kh-e9fhvc8EI16Avbifie