How to deliver more value in your app with fewer releases?
4 ways how Firebase Remote Config can help
For mobile apps, releases are painful. Especially when multiple development teams are involved. Despite careful planning, alignment, and commitment, releases are still time-consuming and unpredictable.
Although mobile releases are an essential part of native app development, it is unfortunate that they cannot be entirely eliminated. However, the good news is that we can make the release process less painful and more adaptable by utilizing various tools. One of the most useful tools for this purpose is Firebase Remote Config or any other Remote Config implementation.
Firebase Remote Config is a cloud service that lets you change the behavior and appearance of your app without requiring users to download an app update.
In this article, we will explore 4 things you can do with FRC to improve your app and streamline the release management process. To make the conversation easier, I’ll use the abbreviation FRC throughout the article.
Canary release for sensitive features
Canary release is a common practice used by many mobile app developers when introducing new features. Rather than releasing a new feature to all users at once, the feature is rolled out to a smaller subset of users first. This allows developers to test the feature in a controlled environment and gather feedback before releasing it to a larger audience.
Firebase Remote Config offers two ways to perform canary releases:
- Releasing for a specific audience based on user properties: target specific users based on their user properties, such as selected language, country, or any other. This allows us to release the feature to a particular group of users and gather feedback before rolling it out to everyone.
- Releasing with a percentage rollout: roll out a new feature to a percentage of users, gather feedback, and measure the impact of the feature before releasing it to everyone.
Both canary release methods are credible and can be beneficial for new features. With FRC, the canary release is made easy and manageable, giving the development team more control over the release process and improving the overall user experience.
Running a public beta program
FRC offers a convenient and efficient way to build an open beta program for your app without the need for a backend. If you have an active core audience that is eager to test new features and provide feedback, you can use FRC to build a beta program and give these users access to the latest features.
To set up a beta program using FRC, you can create a special user property and a new condition in the FRC settings. This condition can be used to enable new features only for beta testers. Once this is set up, product managers can configure the beta features by themselves. This makes it easy and fast to set up a beta program and make changes as needed.
One of the benefits of using FRC for beta testing is that beta tests can be disabled at any time for any feature individually. This means that if a beta feature is not performing well, it can be turned off without affecting the rest of the app.
Once the beta test for a feature is over, you can change the condition and release it to all your users. This doesn’t require users to download an update, which makes the release process faster and more efficient.
In summary, using Firebase Remote Config to build a beta program for your app offers many benefits, including the ability to configure beta features without a backend, easy management of beta tests, and fast release of features to all users once the beta test is complete.
App version update communication
Engaging users to update their apps is a solid aspect of mobile app development. Minimizing the number of users on old versions and maximizing it on the latest ones is essential for improving app performance and user experience. Remote Config can help achieve this goal by enabling developers to handle communication with users effectively.
There are two approaches to encourage users to update their app versions: soft and hard.
- Soft approach: informs users about the new update and its benefits. This approach can trigger user interest and can be achieved through various means such as announcements or new content promises.
- Hard approach: informs users that their current app version is no longer supported. Usually, this message is followed with limitations on the client side because we want users to stop calling deprecated APIs and stop using something that is broken. However, developers should be careful when using the force approach as it should only be used when the number of users on the older version is relatively low or when the older version has critical issues.
Both soft and hard approaches would be a great topic for a separate article, but for now, it would be enough to note that both approaches might be implemented using only the FRC service.
Get non-critical data that changes on a rare basis
Imagine you have some non-critical data that changes infrequently, like data for some static screen with texts, image URLs, and links. This type of data is typically too static to build a backend solution around, but business requires it to be updated occasionally. You may wonder whether to store it on a backend or in FRC. Here are some considerations to keep in mind.
What if I store it on the backend?
- You will need to communicate with backend engineers to update the data periodically
- Any changes to the data structure will also require alignment between the backend and clients
- Additionally, versioning of this data may depend on the backend versioning approach (if there is any)
- The backend’s reliability will impact data delivery to clients
But what if I store this data on FRC?
- Direct access to the data, which can be updated manually by anyone or through API at any time
- Flexible Conditions and values can be changed anytime with no codebase impact
- Versioning is handled automatically on the Firebase side
- Easier to connect data to related analytics
By using FRC, you can update the data at any time without relying on a backend engineer, and avoid potential failures that could affect data delivery to clients. By offloading this responsibility to the Firebase infrastructure, FRC can improve the reliability and performance of your app compared to traditional backend implementation.
Overall, storing non-critical data that changes infrequently in FRC is a convenient and efficient solution that can save you time and effort in the long run.
Conclusion
Firebase Remote Config is a powerful tool that allows us to change the behavior and appearance of our apps without requiring users to download a new version and allows our backend engineers to focus on more impactful initiatives. From getting user-facing data to changing app behavior, FRC offers a wide range of benefits for developers who want to improve the performance, scalability, and user experience of their app.
Utilizing FRC allows us to make the release process smoother and simpler. By using such tools we can make every release have less impact on the system and make the development team more involved in the feature lifecycle instead of the release cycle. I believe this will bring a great benefit to a business in the long run.
If you’re not already using any Remote Config in your app, consider exploring its many possibilities to take your mobile development environment to the next level.
Thank you for reading, and don’t forget to follow me on Medium, LinkedIn, and Twitter for more useful insights and updates on mobile app development and related topics.
