Most mobile app development projects eventually reach a stage where the development of a given version is complete, and the application is ready for publication on app stores. In the case of Android, this primarily involves the Google Play service. The act of releasing can be understood simply as “uploading and publishing”, but it can also be more sophisticated. You might have heard of the unwritten rule "Don't release before the weekend," but is that sufficient?
Development and publication of Android applications come with several specifics that need to be considered:
Considering all of these factors, it becomes evident that removing an unwanted version of an already released application presents significant challenges. It's also impossible to ensure in advance that the application will work flawlessly, both in terms of stability and functionality. This remains true even when the application undergoes rigorous testing across various fronts, including Unit tests, Instrumented tests, Screenshot tests, Detekt, and Android Lint, in addition to multiple rounds of manual testing. These methodologies only reduce risks, they don't eliminate them. It's almost impossible - and very costly in terms of time and finances - to cover all devices and user behaviours.
The Google Play service seems to acknowledge this and provides several tools that enable smarter and smoother releases:
In this article, we will focus on how to utilize open testing for releasing early access & beta versions of applications in order to identify potential issues with a version in a timely manner and react to them promptly.
Prior to the official release for users, an application can be introduced through a beta program to gather valuable information about its stability and functionality. In this program, users willingly participate and should be aware that the version they receive might not represent the final production. Consequently, the application might include errors or features that could undergo modifications or even be eliminated at a later stage.
Early access applications are applications in the beta program that haven't been published yet - there is no official production version available, only a version in the beta program. These applications are available on Google Play in a separate section called Apps in development.
Beta applications are applications in the beta program that already have a published production version and represent its future version, which will be installed as an update. These applications are available on Google Play on the app's description screen (if the app supports the beta program). A significant advantage of beta applications is that if the app exhibits problematic behaviour, the user can leave the beta program at any time and install the stable production version of the app.
Both of these versions allow you to control the number of users and determine which countries are supported in the Google Play administration. Additionally, users participating in the beta program can provide feedback on the specific version of the application.
Both feedback and reviews are user interactions with the application. Despite serving the purpose of commenting and rating the app, there are significant differences between them.
In Etnetera Flow, we have found that users who provide feedback are generally more constructive, polite, and open to helping refine the app compared to users who leave reviews.
In Etnetera Flow, we view the beta program as a space where we can verify whether a new app version is stable and all features are functioning as designed. Despite the possibility of bugs in beta apps, it's advisable to publish apps in the beta program that have successfully passed all testing phases and have been approved for quality, stability, and functionality.
During the time when the application is released in the beta channel, we actively monitor its stability, quality, behaviour, and user feedback. In addition to the data in the Google Play console, we also utilize other tools, such as Firebase.
In cases where the application doesn't perform as expected, it makes sense for us to repeat the entire process and publish multiple newer versions with fixes to the beta program before promoting a refined build to the production version.