Congratulations! You've just released a new version of your cool iOS or Android app into production. Great! It's just... Have you thought about what you would do if this release contains a fatal bug? Alright, maybe you've got a full suite of automated tests and an army of QA professionals, so it won't happen to you. But what if users don't like the new UI design and your conversion rate drops by 50%? In short, what's your strategy for that day when you release a very unfortunate update of your mobile application into production? I would argue that after mobile applications reach a considerable audience, you must be prepared to handle this kind of emergency. In this post, I'll explain how feature flags can help you control your mobile applications, give you peace of mind about potential emergencies, and even grant you some business benefits.

The idea behind feature flags is simple: mobile app developers add special code that allows for control of several internal app parameters remotely. These parameters become feature flags. After developers integrate feature flags into apps, controlling their behavior can be as simple as clicking a button in your feature flags management dashboard. Controlling the feature flags is easy, and you can get disproportionately big benefits from it. In a moment, I'll talk about the more important feature flags use cases in mobile apps. But first, I'd like to address another equally important topic. You see, the feature flags technique is not limited to mobile apps. It can be readily used for web frontend and backend as well—or any other platform, for that matter. So is there anything about mobile apps that makes feature flags stand out in this context? Yes!

Think about the various components of a generic internet application. Web backend servers are the heart of a system. Backend servers store application data, execute business flows, and integrate with third-party applications. Users don't usually access web backend servers directly, though. They use web clients instead. The two most common types of web clients are web frontend and mobile native. Web frontend clients allow users to interact with the application through web browsers. Mobile clients provide access to application functionality from mobile devices. Now let's look at these components through the prism of digital distribution techniques. Both the backend server and the clients are "distributed" through the internet. However, components' distribution models still differ in some aspects and impose different levels of risk to the business. As the saying goes, "The devil is in the details." In the ideal world, I wouldn't discuss web backend and web frontend at all. I would just tell you how feature flags can help you in mobile applications, and that would be enough to convince you that you need them. But we don't live in the ideal world. So, before launching into a discussion on feature flags, I'm going to contrast web backend, web frontend, and native mobile distribution models and convince you that it's native mobile that you should pay a special attention to.

You control web backend servers and the code that runs there. Clients access the servers by sending requests over the internet that trigger execution of predefined server flows. After servers execute the relevant flows, they send responses to the original clients. If you change anything about backend functionality, the clients will observe the effect of this change the very next time they communicate with the server. This fact, combined with many mature and safe deployment strategies (e.g., blue-green deployment), allow for quick and relatively low-risk backend updates that can be easily rolled back.

Users who interact with your application through web browsers effectively load chunks of your code on demand and then run it on their hardware. This code can cover anything from individual widgets to the entire website in scope. Since users run this code in web browsers on their devices, you effectively lose control over it. But it's not as bad as it sounds. Users load your web frontend code into their browsers on demand. They'll reload this code the next time they visit your site. Therefore, you'll have a chance to patch or roll back web frontend code on each user session.

In contrast to web backend and frontend, the distribution of mobile apps is a clumsy and heavyweight process. Users need to visit application stores and manually download your app to just get started with it. Apps of 50+ megabytes in size are not rare nowadays. Later, as you release updates, user devices will need to download big chunks of data again. In some cases, these updates can be comparable in size to the original apps. As you probably know, mobile devices have limited battery life and can be constrained by network bandwidth and its cost. Many users will receive apps updates only when they charge their devices and are connected to Wi-Fi at the same time. If anything goes wrong with one of your mobile app releases, your users might be stuck with it for hours or even days. But that's still not the worst scenario. See, users can completely disable automatic updates on most mobile devices. Therefore, you might be unable to replace the unfortunate release on users' phones until they manually update your app. Worse, they might choose to uninstall it because they don't want to waste network bandwidth on apps that disappoint them. All in all, updates to your mobile applications bear higher intrinsic risk to the business. Fortunately, you can mitigate this risk using the feature flags technique.

Alright, it's time to see some of the more important use cases of feature flags in mobile applications.

I would argue that having an ability to roll updates back is one of the most important features of any deployment pipeline. Both Google Play and the App Store fall short in this respect because they don't provide a rollback option at all. There are countless scenarios in which a rollback feature would be a lifesaver. Let me just list some off the top of my head for you:

• An unfortunate design change that hurts user engagement and conversion.

• A new feature that sends too many server requests, effectively DDOS'ing your own servers.

• A fatal bug that affects owners of specific devices.

Using feature flags, you can have full control over the distribution of new features in almost real time and roll everything back if a need arises.

The days of the "one size fits all" approach are gone. Today, product owners and marketers in serious businesses should be able to tailor user experience in mobile apps to individual users. Such personalization can use very broad criteria (e.g., geographic location) or a specific user characteristic (e.g., purchase history). Advanced personalization strategies might take into account many different parameters simultaneously and be dynamic in nature. Many personalized features can involve changes to mobile apps behavior. This kind of personalization requires feature flags.

Businesses use A/B testing to obtain unbiased and quantitative feedback about product changes from actual users. This is achieved by releasing several alternative variants to different groups of users and then measuring the variants' performance. This technique allows businesses to make an informed decision about product development and marketing strategies. As you might have already guessed, A/B testing is also based on feature flags under the hood.

Time to wrap it up. I wanted to raise your awareness of the limitations involved in the distribution of mobile apps to the users. Routinely, these limitations are annoying but not critical. However, during emergencies, they can become devastating bottlenecks and turn what could be just a minor issue into a total disaster. You can use feature flags to get much better control over mobile apps. They allow you to toggle specific features on and off remotely, thus greatly reducing the risks. In addition, feature flags can be used for app personalization, A/B testing, and more. Now, you most probably don't want to build the entire feature flags management platform yourself. Fortunately, you've got a wide range of readily available feature-flags-as-a-service solutions. Just pick one of them and enjoy the peace of mind it brings you.