Things to do before releasing an app

18 Jan 2023

Photo by Balázs Kétyi on Unsplash

So you’ve been hard at work building an amazing app and are getting ready to share it with the world. As the release date approaches, you start wondering you if you’ve done everything you are supposed to. You want to get this right. It’s hard keeping track of everything even if you’ve done this before, so here’s a simple list to follow:

Set the correct Application / Bundle ID

Mobile apps need to have a unique Application ID (Android) / Bundle ID (iOS). You can’t change this once the app is published and will be stuck with it forever. Make sure you set the right value. The best-practice for this is to use the reverse DNS notation. If your website is myawesomeproduct.com, your application / bundle ID should be com.myawesomeproduct. Some people use com.myawesomeproduct.mobile or com.myawesomeproduct.[android/ios] and that’s OK too.

Remove all hardcoded secrets from the code

Make sure you don’t have any hardcoded secrets like encryption and API keys in your code. Reverse engineering mobile apps is getting easier and if an attacker is sufficiently motivated, they will find and exploit these secrets. Obfuscating your code using tools like Proguard only slows them down, but doesn’t stop them. For keys you have to include in the app, make sure they only work if the application / bundle id matches the one for your application.

Test on low, mid and top-tier devices

Testing on emulator/simulator is fine during development, but make sure to test on a wide range of devices before release. You’ll be tempted to test only on the latest flagships, but don’t. Identify a good selection of low, mid and top-tier devices and test on them.

Test on devices with different screen sizes

Test on both small and large screens. It’s easy to miss UI bugs if you don’t do this. Make sure images scale correctly, text doesn’t get truncated, and all animations work as expected.

Test different screen orientations

Test the app in both portrait and landscape mode. Also test switching between those modes while using the app. It’s easy to miss exceptions and memory leaks that occur due to orientation changes.

Test on different OS versions

First make sure you’ve set the right minimum supported versions for your app. Then make sure you test on at lease the oldest and newest version. There can be subtle difference in API behavior across versions that are easy to overlook. Some versions may have additional rules for using permissions so make sure you account for that.

Test on devices from different manufacturers

This is relevant to Android. Manufacturers sometimes change the behavior of an API under the hood causing the app to behave differently. Pick devices from all the popular device manufactorers (Samsung, Motorola, Google, Xiaomi, etc) and test the app on them. If you don’t want to invest upfront to buy so many test devices, use a service like BrowserStack.

Test on slow networks

Not everyone has access to high-speed WiFi. Test the app on slow, flaky networks to make sure your app works properly.

Test with all supported languages

If you support multiple languages, test that the translations are rendered correctly. Some languages like German have very long words compared to English which breaks UIs in interesting ways. RTL languages like Arabic read right to left and can also lead to interesting bugs if you are not careful.

Test with screen readers

At least 2.2 billion people worldwide are visually impared in some capacity (source). Make sure your app works properly with Voice Over on iOS and Talkbalk on Android. Depending on which countries you launch in, this may also be a legal requirement.

Have a way to monitor stability

Make sure you have crash reporting implemented in the app and familiarize yourself with it. Verify that the crashes are being reported and learn how to monitor the stability of a build. You can use services like Bugsnag and Firebase Crashlytics for this.

Create a playbook to release a hot-fix

Releases often do not go as planned so be prepared to release a hot-fix quickly. Write down the steps needed to create a new build and how to publish it to the app stores. Share this broadly so that everyone on your team knows what to do. Make sure all the right people have sufficient permissions to do this. You don’t want to get stuck in position where you have to do an emergency release and the person with app store access is on vacation.

Set up a way to monitor and reply to app store reviews

Lots of bugs are reported in the form of reviews on the app stores. People are very likely to write a review when something doesn’t work as expected and give your app a bad rating. Your app’s app store rating directly impacts search ranking and user conversion so do everything you can to keep it high. Reply to both positive and negative reviews. People often update their review and rating if you reply to them after fixing the issue. Google and Apple don’t make it easy to do this, so use a service like Appfigures instead.

Get a security audit done

Building a secure app is hard and it’s easy to make mistakes even though you may have years of experience. Get professional security researchers to perform a security audit on your app and fix any issues they find. If you work for a large company, you will most likely have an in-house team for this. If that’s not the case, there are lots of companies who you can pay to do this for you. This may seem overkill, but it’s better to be safe when the stakes are high.

Implement a kill-switch

First off, congrats on reading this far.

If you do everything I wrote above, there’s a very good chance that your release will go as planned. However, Murphy’s Law is real and it’s extremely valuable to have a way to disable the app remotely at any time. Security vulnerabilities and bugs that cause loss of money or user info are prime examples of when to use this ability.

The most common way of implementing this is to have a mechanism on the server to block versions older than a specific version of the app from being usable and having client-side code to show provide instructions to the user to update the app. Test this thoroughly and document how to use it so that everyone on the team knows how to do it. Every minute matters when there is a critical issue in production.

Good luck!