Still, the release of a mobile application is way more complicated and risky than one of a website. As a result, releases can often take a very long time – to make sure everything is ok.
The publication of a mobile app: a very long process
In short we could resume the publication of an app to a very simple 4-step process:
- Step 1: Compile the code
- Step 2: Sign the resulting binary
- Step 3: Upload it to Apple / Google
- Step 4: Push the release button
In reality those steps are the only ones which are mandatory and they are quite complicated to perform (mostly because Google and Apple ecosystems are).
To ensure a proper release there are a bunch of extra steps you should always perform, ending up with a way more complicated process:
Add the fact that Apple can refuse your app for some obscure reasons or that it is easy to make a mistakes, and one can easily understand why the release is often a pain point.
Don’t trust humans to perform a robot job! Once again, our answer is automation and a framework called Fastlane.
Fastlane is an open-source project, owned by Google, that aims at helping developers through the lifecycle of their application, and therefore the mobile application release.
Fastlane provides with a lot of tools to interface with our own daily tools: from the IDE (development environment) to build the app to the API of Google and Apple to publish it.
Playing with those tools (or custom ones you can build for yourself) and arranging them together you can build flows (called lanes) that matches your processes and execute them in a blink.
At FABERNOVEL TECHNOLOGIES we build lanes for each process we have to manually repeat many times.
Despite all the efforts one puts in automated tests and QA there might still remain some hidden bugs or flows in the UX.
Thankfully Apple and Google provides tools to secure launches.
Using Testflight (Apple) or Closed Beta Program (Google) one can send an app to an identified set of users. This allows you to confront your app in live condition to users that will be more accommodating if some problems still occur.
If your planning allows it, we strongly suggest to use this feature, at least towards internal testers and if possible to an identified community of beta testers. It will help you to tackle last bugs on most used features and gather a lot of feedback.
Phased release / Progressive Rollout
Finally use Phased Release (Apple) Progressive rollout (Google) to distribute your app to the final users. It means you won’t make the update available to your entire userbase at the same time and can stop the release anytime if your analytics shows there is a problem with the version.
Analytics? This will be the topic for our next article in this story since you cannot hope to continuously improve your app without monitoring its performance and how your users are using it.
Would you like to stay updated on this story? Subscribe to our newsletter.Subscribe