Keeping Your Android App Popular After Launch

About The Author

Ryan Bateman is a Technical Product Owner at Novoda, a mobile consultancy company. His job is to care about apps a little too much. He’s been working as a … More about Ryan ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

How do you maintain that momentum and ensure that your app keeps gaining in popularity? In this article, Ryan Bateman covers some practical approaches to keeping users interested in and using your app, including talking to your users, keep on launching features, making the first impression count and using all functionalities of the operating system. The following tips are all long-term approaches to maximizing user retention, driving daily usage and getting users hooked on your app, but they don’t have to be deployed simultaneously. Your general aim, and best approach, should simply be to demonstrate that you know and care about your users’ needs and requests.

You’ve launched your app and it’s doing well. You worked hard, kept your initial features lean, and all of your effort has resulted in an app that users like and recommend to friends. So, how do you maintain that momentum and ensure that your app keeps gaining in popularity?

This article covers some practical approaches to keeping users interested in and using your app, including talking to your users, keep on launching features, making the first impression count and using all functionalities of the operating system.

Get Talking To Your Users

According to a survey conducted by Google and Ipsos MediaCT, the top three reasons why users abandon an app are lack of interest, change in user needs and simply lack of usefulness. But usefulness, necessity and interestingness are subjective and change over time — what you think your users need or like isn’t always accurate. So it’s important to start a dialog with your users.

App usefulness is motivation for ~72% of apps being abandoned
(Image: Think With Google) (View large version)

We’ve found that the best long-term approach is to foster a “VIP” beta-testing community. These beta-testing communities help us understand user needs, even as they change and adapt. These beta testers, in return, get early access to new features and have an opportunity to help shape the application, making them feel like VIPs and often turning them into advocates for the application as a result. We typically use the Play store’s beta distribution channel and a Google+ community for this purpose. This distribution channel enables users to receive app updates via the Play store as normal, but from the beta release group. The Google+ community acts as a place to leave comments and bug reports, and access to the channel can be restricted.

Creating your own beta-testing community is simple. First, find the first few people who have rated your app lower than you’d like or who are particularly vocal about its design, and engage them in a dialog. Treat their complaints and concerns sincerely, and recognize that they’ve spent time trying out your application. If they’re open to the idea, ask them to join your beta-testing community, and, where possible, ensure that your subsequent releases address their concerns specifically. When you do so, let them know and thank them for their help. You’ll find that these users go from being critics to advocates.

CCleaner for Android, an application published by Piriform, is one such application for which we took this approach. Within 18 months, it grew to over 15 million downloads, and the beta-testing group grew to 10,000 people. The people in this testing group have become advocates whose opinions help shape the app’s next features, keeping it useful and up to date with users’ needs. This beta group is very large. When setting up your own, try to keep it to a number that will allow you to respond to queries and bug reports, while still leaving you time to work on new features.

Keep Launching

If you’ve kept your first launch lean, you should have a backlog of features that you’d have loved to put in the product but sensibly didn’t. Keep that version 1.1 lean, too, and assume that half of the effort that goes into it will be bug fixes, but get it out sooner than later.

Aim to update your application regularly, and get users used to (and excited about) these updates. This regular update rhythm will both act as a good personal motivator as well as teach users to expect timely, interesting updates. Companies such as Spotify make these regular releases a part of their engineering culture, creating a “release train” that leaves the station every two weeks. Features that are not completed in time for the next train are shipped as part of the release but are deactivated and unseen by user.

Spotify releases regularly, sometimes with features partially completed but unseen by the user
(Image: “Spotify Engineering Culture, Part 1”) (View large version)

There are a number of tools you should consider adopting when attempting to decrease the time between your app’s updates.

Automated testing is the most important. A continuous integration server, such as Jenkins, can be used to automatically run tests on features and changes that you’ve made to the code as you work, ensuring that you never code yourself into a corner. Knowing that your updates and changes haven’t caused a new bug or broken an older feature means you shouldn’t ever have to waste time “doubling back” over old code.

An issue tracker is a good tool for prioritizing your workflow and maximizing the value you send out with each update. JIRA is a one such tool used by many large teams, while Trello is a good alternative for lone developers. Both tools allow you to create issues (or cards) that you can use to monitor your backlog. This helps you to plan and organize releases with minimal hassle and keep your administrative overhead to a minimum.

If you’re using Git, then another practical method of managing this selective integration of new features in time for a release is the Gitflow workflow. This workflow keeps code branches for new features separate from the main code base. When it’s time to create a release, these code branches can then be selectively merged back into the main code base.

Make That First Impression Count

According to a survey conducted by Quettra, on average 77% of users no longer actively engage with an app after just one week. If you want your app to keep engaging users and stay popular, then making a good impression in those first few days after installation is vital.

App usefulness is motivation for ~72% of apps being abandoned
(Image: Quettra/Andrew Chen) (View large version)

As an app developer, your aim, therefore, should be to highlight the app’s usefulness to new users in the first week after installation. A good onboarding process that highlights the app’s functionality is vital. Where possible, this onboarding should walk users through a real use case or show real data to best impress upon them the purpose of the application.

This can be a challenge in some cases, such as when the app’s content is behind a paywall or when its content is populated entirely through user action. In the case of “The Sun”, one of the world’s largest English-language newspapers, we worked with the company’s designers and API developers to ensure that the onboarding process contained real, timely data (in this case, football scores and recent headlines).

This real, time-sensitive data presented well, highlighted to new users exactly what kind of content they could expect and showed that care had been taken in its presentation. This approach caused adoption rates to spike and resulted in increased revenue.

## Use Every Part Of The Buffalo Android is far more than simply a phone operating system. With a little work, it’s easy to move your app’s core functionality into any of Android’s other form factors and then tailor the UI and UX as necessary. Nothing delights a user more than an app that works well and seamlessly across all of their devices — from their phone to their new tablet and even to their Android TV. This cross-platform compatibility is a great way to outdo your competitors. You’ll no longer simply be competing on a single form factor. Android applications are typically distributed as [Android application package]( (APK) files. These files can be produced for individual platforms, in which case multiple APK files would be produced, or a single APK can be produced that works on multiple Android form factors. One way to ensure that you’re able to deliver a consistent experience across all of these platforms is to **produce a single APK file** that can easily be installed on any Android device. Producing a single APK has both [advantages and disadvantages.]( One advantage is **automatic installation on new devices**. If a user of your app buys a new device, once they log into the new device with their Google account, all of their compatible apps will automatically be synced. If you’ve produced a single APK, this means the user will find your app installed automatically on their new device. In the case of Android TV, where app discovery is generally more difficult, this is almost essential to gaining installation traction. The biggest disadvantage in producing a single APK for all platforms is the **resulting file size**. This one APK will need to contain all resources for all platforms and configurations, meaning a potentially bloated APK for those with phones with small storage. In terms of code structure, the best way to organize your code for easy portability across form factors is to ensure good separation of the app’s business logic (which typically won’t vary from device to device) from the presentation layer (which will). This will allow you to alter each platform’s UI and UX without having to alter any underlying logic.

Landing page UI may differs between two form-factors such as tablet and phone but it can share the same underlying business logic.
(Image: Novoda) (View large version)

Here, for example, we see how an app with a single APK has a log-in page laid out in two different ways for the tablet and phone form factors. The underlying business logic for validating a password or making a call to the necessary API will be the same for both form factors, but how we present any errors and lay out the page will be different.

With this in mind, we always start our projects with two modules: “core,” which contains our core business logic, and “mobile,” which contains our Android- and platform-specific code. Within the mobile module, we then split our presentation layer code across various platforms as necessary, all while keeping the underlying business logic the same across our platforms. This separation of concerns ensures that we can not only parallelize development, but also reduce potential regression bugs. This approach has numerous other benefits, such as making standalone testing of core business logic easier.

Final Notes

The tips mentioned above are all long-term approaches to maximizing user retention, driving daily usage and getting users hooked on your app, but they don’t have to be deployed simultaneously. Your general aim, and best approach, should simply be to demonstrate that you know and care about your users’ needs and requests.

Further Reading

Smashing Editorial (al, ml, jb, da, mrn)