The Dos and Don’ts of Releasing Mobile Apps
As you gain experience in the world of professional mobile application development, chances are, at some point, the release process will become one of your responsibilities. Often considered an afterthought in the SDLC, there are lots of mistakes to be made here, and just as many ways to avoid them. Today we’ll talk about how to properly release a mobile app, including all the steps leading from when development is completed to clicking the “Publish” button.
Distribution
Before you can test an app, you have to get the app to the testers. There are lots of options for distributing development builds to a QA team, and you’re going to need one. I recommend using a platform that can handle both Android and iOS app distribution, at least for development builds. Since mobile QA engineers often operate across both platforms, it’s convenient for them to have one process for getting the app. We use HockeyApp for distribution, which Microsoft is currently transitioning to a new tool called App Center. It’s not a great tool, but it will certainly get you off the ground. Meanwhile, the now Google-owned and operated Firebase is about to release their own distribution tool, Crashlytics Beta, so I’ll definitely be checking that out in 2019, and I suggest you do too, especially if you’re already using any of Firebase’s other features in your app.
Those tools are great for distributing development builds, but you also definitely want to run some tests on that actual program you’re releasing to users. Once development testing is done, some testing should be exercised on your final build, including testing the upgrade process itself. For this, there’s no silver bullet option, so we use each platforms’ tools for distributing pre-release production builds. On Android, that means the Google Play Integration Test Channel, and on iOS, TestFlight. I won’t go into specifics here, as this article is already way too long, but I’ll try to do a deep dive on these tools in the future. Next up:
QA
Quality Assurance is the gasoline of the release process. Without QA you really can’t move forward at all. Or, rather, you could, but you’d have no confidence that everything actually works the way you expect under different sets of circumstances. It’s impossible to weed out bugs introduced in the development cycle without QA, especially when you have a large team of developers all working concurrently. In a robust agile development cycle, there are two main types of QA — In-Sprint, and End-to-End
In-Sprint QA, in an agile software dev system, means that every story, task, and bug a developer completes is specifically tested to ensure that that ticket was implemented correctly. QA Engineers exercise all of the criteria under which the code can function, and verify that all cases work correctly. When the ticket concerns new functionality, this is called “Progression” testing. It means that you’re introducing something new, so there’s no standard to test against, and you have to create new tests for new features.
Once In-Sprint QA is successfully completed, a release-candidate is made (more on that in a minute) and sent to End-to-End QA. E2E’s job is to verify that the app does all the things that In-Sprint said were working, and that it does all the things it used to do before new development was started. This is referred to as “Regression” testing. In between the In-Sprint and End-to-End processes, there’s a conversion where all the new tests that In-Sprint created to test new functionality are added to the overall application Regression Test Suite. This test conversion is incredibly important. If In-Sprint tests don’t make it into End-to-End, then any new development you worked on will never get tested again, and the chances of releasing an app with broken features goes up exponentially. When Progression (In-Sprint) and Regression (End-to-End) QA are both completed successfully (that is, QA doesn’t find any critical defects in the app) then the build is said to be “certified.” But what happens when QA turns up a bug in your build?
Release Branches and Version Control
Development of the product generally doesn’t stop when development for a release is done, so the first question you need to answer is, how can you turn over a build to be tested and at the same time work on new features for the next release. What happens if there’s a bug in the release build? How can you fix a bug if you’ve already added a bunch of new stuff before that bug was found?
This is where a smart branching strategy comes to the rescue. Pretty much any version control system worth its salt has some concept of branching. As the name suggests, branching code means that, just like a tree branch, the code is the same up to a point, and then splits into (essentially) two copies. Each branch can then evolve independently of the other. In this case, one copy — the release branch — stays frozen at the point where you finished development. The other branch (let’s call that one the master branch) can be modified with new code and bug fixes without effecting the release branch at all. If a bug is found in the release candidate (that’s the build you made and handed over to QA earlier) a fix for it can be developed and added to the release branch. That way, the next build you make, again off the release branch, can be identical to the first except for that one bug fix. That way, you minimize the risk of introducing new bugs into the release, by isolating it from new work. The fix can then also be applied to the master branch, to ensure that the same bug doesn’t get into the next release (in Git we would use the cherry-pick command for this). The other benefit of release-branching is that once you actually publish, you have a frozen branch that represents the exact codebase that got published. You can go back to that code at anytime for reference.
Ok, now that your release candidate is QA’d, you’re ready to release, right? Not so fast.
Recoverability
Before releasing your app even the first time, you want to make sure you’ve built in a range of recoverability options in case something goes wrong after you publish. As I frequently remind everyone in the office, an app is not a website. Once it’s out there, you can’t just redeploy and fix everything. If you don’t know what I mean by recoverability, go back and read this, and then develop some recoverability features. Then start this whole release process over again.
Ok, so NOW you’ve built and QA’d all your new features and all your recoverability features, and fixed all your bugs on the release branch AND master, so you’re (finally) ready to publish. Now what? Well…
Beta Test
A beta test is an experiment where you distribute the new app to a control group of users before you go live to the whole user-base. The idea here is that, no matter how rigorously your QA department tests your app, they just aren’t going to use it the way that users will, and therefore, users will almost always find bugs that QA and Dev both missed. If you can afford the time, consider a beta test, even for just a week. You’ll be amazed at the revelations the test will uncover, especially if you’ve got analytics and crash reporting built in. More on those in another article.
Ok, so now you’ve Developed, QA’d and (probably haven’t) Beta tested your Release Candidate, so it’s (finally, finally, for real now) time to let it out into the wild.
Publishing
The actual publication of a mobile app on each platform is a subject unto itself, so I won’t go into it here, but again the tools you use are platform specific: The Google Play Store Console for Android apps, and iTunes Connect for iOS. There are plenty of resources on how to use these tools, so check those out for more in depth instructions.
Post-Publication
The job of managing a release doesn’t end when you publish, it extends right up until you’re ready to release again. If you want your app to succeed, be well reviewed, or in some cases, make money, you also have to monitor the release in production so you can fix bugs, implement features people want and address your users’ concerns. To do this, you’ll need to install crash reporting, and some sort of analytics in your app. Again, these are both broad topics for future articles, but for now I’ll say that Firebase provides dead-simple tools for both.
Also, keep in mind that app reviews provide insights into your product that are much harder to obtain from, say, a website. Both Google Play and the App Store provide the ability for app developer to respond to reviews, which can be an incredibly useful tool for getting more information from users about problems with the app. Reviews can reveal the troubles that users are experiencing with your app, and inform decisions about future changes and improvements. There are tools like AppFollow for monitoring your reviews, and others like Apptentive for soliciting user feedback and even communication with users directly. That said, you should also be prepared for people to just hate your app for no clear reason. Sigh.
Releasing a digital product for people to use is a complex and involved process, and often requires an entire team just to manage the logistics of it all. But paying attention to your releases is definitely in your best interests as a developer. A breakdown anywhere in the release process can leak bugs into production, and once users start experiencing problems with a mobile app, it’s a very short leap to an uninstall. Building trust in an application is something you as a developer have to work at, by building a redundant test-and-release process that ensures, as much as it can, that as few bugs make it out into the wild as possible.