{"id":73900,"date":"2025-08-13T12:04:28","date_gmt":"2025-08-13T06:34:28","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=73900"},"modified":"2025-10-13T15:06:52","modified_gmt":"2025-10-13T09:36:52","slug":"feature-toggles-remote-config-and-a-b-testing-in-android-ship-faster-without-fear-2","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/feature-toggles-remote-config-and-a-b-testing-in-android-ship-faster-without-fear-2\/","title":{"rendered":"Feature Toggles, Remote Config, and A\/B Testing in Android: Ship Faster Without Fear"},"content":{"rendered":"
\n
\n
<\/div>\n

Imagine you’re an app developer. You’ve worked hard on a new feature, but just before it’s ready, a bug appears. You have a hard choice: either you delay the launch to fix the bug, or you release the feature with the bug and hope it doesn’t cause problems.<\/span><\/strong><\/p>\n<\/header>\n

\n

This happens because usually, when you release new code, the new features are turned on right away. A better way to work is a method called progressive delivery<\/strong>. This lets you release your code and your features at different times. This means you can ship code all the time while having full control over when and how new features are turned on.<\/p>\n

To do this, you can use three important tools: Feature Toggles, Remote Config, and A\/B Testing. By understanding and using them, you can build a more reliable release process that uses real user data.<\/p>\n<\/section>\n

<\/p>\n

\n

1. The Foundation: Feature Toggles<\/h3>\n

A Feature Toggle<\/strong> is like a switch in your app’s code. You can use it to turn a new feature on or off. You can build all the code for a new feature, but the switch lets you decide when people can actually see and use it. This way, you can put the new code into your app, but keep the feature hidden until you are ready.<\/p>\n

Without a toggle:<\/p>\n

\n
startNewCheckoutFlow()<\/code><\/pre>\n<\/div>\n
With a toggle:<\/p>\n
\n
if (isFeatureEnabled(FeatureToggle.NewCheckout)) {\r\n    startNewCheckoutFlow()\r\n} else {\r\n    startLegacyCheckoutFlow()\r\n}<\/code><\/pre>\n<\/div>\n
Key Benefits:<\/h4>\n
    \n
  • Safe Testing:<\/strong> You can hide new, experimental features behind a toggle and only show them to a small group of internal testers.<\/li>\n
  • Less Risk:<\/strong> If a new feature causes a big crash or problem, you can turn it off instantly with a toggle. This saves you from having to release a whole new app update just to fix the issue.<\/li>\n
  • Continuous Delivery:<\/strong> Developers can add new code to the main app often, knowing that the new feature will stay hidden until it’s ready for everyone.<\/li>\n<\/ul>\n<\/section>\n
    <\/p>\n
    \n
    2. The Brains: Remote Config<\/h3>\n
    While a simple on\/off switch in your code is good, it’s not very flexible. You can’t change it without releasing a new app update. **Remote Config** is a tool that lets you control these switches from a central place on the internet. This means you can turn features on or off, or change things like a welcome message, without making users update their app.<\/p>\n
    Remote Config allows you to change more than just on\/off switches:<\/h4>\n
      \n
    • Boolean flags:<\/strong> Turn features on or off (`enable_new_ui`).<\/li>\n
    • Strings:<\/strong> Update UI text or messages (`home_title`).<\/li>\n
    • Numbers:<\/strong> Change a setting for your app (`max_cart_items`).<\/li>\n
    • JSON objects:<\/strong> Store more complex information for special settings.<\/li>\n<\/ul>\n
      The most popular tool for this on Android is Firebase Remote Config<\/strong>, which is a powerful and simple platform with features like rolling out to a percentage of users, targeting specific groups, and A\/B testing.<\/p>\n<\/section>\n
      <\/p>\n
      \n
      How it Works: The Progressive Delivery Flow<\/h3>\n
      This diagram shows how your Android app, the remote configuration, and the user all connect:<\/p>\n
      \n
      \"Flow
      Firebase Remote config<\/p><\/div>\n<\/div>\n
      The app gets its settings from the server, which you manage using the Firebase Console. The app then uses these settings to decide what features to show the user.<\/p>\n<\/section>\n
      <\/p>\n
      \n
      3. The Experimentation Engine: A\/B Testing<\/h3>\n
      A\/B Testing is a way to find out which version of a feature works best. You can show one version to some users (Group A) and a different version to other users (Group B). Then you compare the results to see which one is more successful, like which one gets more clicks or sales.<\/p>\n
      Remote Config gives you the ability to show different versions of a feature to different users. A\/B testing is the process of setting up and looking at the results of this test. This process removes guesswork and helps you check your ideas with real user data.<\/p>\n
      The A\/B Testing Process:<\/h4>\n
        \n
      1. Have an Idea:<\/strong> What do you want to test? For example, “A green checkout button will get 10% more purchases than a blue one.”<\/li>\n
      2. Create Versions:<\/strong> Use Remote Config to make a “Control” group (Version A) with the blue button and an “Experiment” group (Version B) with the green button.<\/li>\n
      3. Show to Users:<\/strong> The A\/B testing tool randomly puts users into one of the groups.<\/li>\n
      4. Track Results:<\/strong> Use a tool like Firebase Analytics to track your goal (e.g., button clicks) for each group.<\/li>\n
      5. Analyze:<\/strong> The tool will tell you which version was the winner based on the data.<\/li>\n
      6. Rollout:<\/strong> You can then turn on the winning version for all users with a single click.<\/li>\n<\/ol>\n<\/section>\n
        <\/p>\n
        \n
        Getting Started with Firebase in Android (Step-by-Step)<\/h3>\n
        Here’s a simple guide on how to get started using Kotlin and Firebase.<\/p>\n
        Step 1: Add the Firebase SDK<\/h4>\n
        First, you need to add the Firebase SDK to your app’s `build.gradle.kts` file.<\/p>\n
        \n
        \/\/ build.gradle.kts (Module: app)\r\ndependencies {\r\n    \/\/ ... other dependencies\r\n    implementation(\"com.google.firebase:firebase-config-ktx\")\r\n    implementation(platform(\"com.google.firebase:firebase-bom:32.7.0\")) \/\/ Recommended for versioning\r\n}<\/code><\/pre>\n<\/div>\n
        Step 2: Set Default Values<\/h4>\n
        You should always set a default value for your features. These are used when the app first launches and hasn’t yet connected to the internet to get new settings, or if there’s no internet connection at all.<\/p>\n
        Create a new XML file at `res\/xml\/remote_config_defaults.xml`.<\/p>\n
        \n
        <!-- res\/xml\/remote_config_defaults.xml -->\r\n<defaultsMap>\r\n    <entry>\r\n        <key>enable_new_ui<\/key>\r\n        <value>false<\/value>\r\n    <\/entry>\r\n    <entry>\r\n        <key>welcome_message<\/key>\r\n        <value>\"Hello from defaults!\"<\/value>\r\n    <\/entry>\r\n<\/defaultsMap><\/code><\/pre>\n<\/div>\n
        Step 3: Get & Activate the Config<\/h4>\n
        In your app’s main code, get the latest settings from the server.<\/p>\n
        \n
        \/\/ A good place to do this is when your app first starts.\r\nval remoteConfig = Firebase.remoteConfig\r\n\r\n\/\/ Set how often the app should check for new settings (e.g., 1 hour)\r\nval configSettings = remoteConfigSettings {\r\n    minimumFetchIntervalInSeconds = if (BuildConfig.DEBUG) 0 else 3600\r\n}\r\nremoteConfig.setConfigSettingsAsync(configSettings)\r\n\r\n\/\/ Set the default values from the XML file\r\nremoteConfig.setDefaultsAsync(R.xml.remote_config_defaults)\r\n\r\n\/\/ Get the latest settings from the server and use them\r\nremoteConfig.fetchAndActivate()\r\n    .addOnCompleteListener { task ->\r\n        if (task.isSuccessful) {\r\n            val updated = task.result\r\n            Log.d(\"RemoteConfig\", \"Config params updated: $updated\")\r\n        } else {\r\n            Log.e(\"RemoteConfig\", \"Fetch failed.\")\r\n        }\r\n        \/\/ Now you can use the settings, whether they are new or the defaults.\r\n        updateUI()\r\n    }<\/code><\/pre>\n<\/div>\n
        Step 4: Read Flags in Code<\/h4>\n
        You can read the flags anywhere in your code after they have been loaded.<\/p>\n
        \n
        fun updateUI() {\r\n    val remoteConfig = Firebase.remoteConfig\r\n    val isEnabled = remoteConfig.getBoolean(\"enable_new_ui\")\r\n    val welcomeMessage = remoteConfig.getString(\"welcome_message\")\r\n\r\n    \/\/ Use the values to control what the user sees\r\n    if (isEnabled) {\r\n        \/\/ Show the new user interface\r\n    } else {\r\n        \/\/ Show the old user interface\r\n    }\r\n\r\n    val textView = findViewById<TextView>(R.id.welcome_text_view)\r\n    textView.text = welcomeMessage\r\n}<\/code><\/pre>\n<\/div>\n<\/section>\n
        <\/p>\n
        \n
        Advanced Strategies & Best Practices<\/h3>\n
        Structuring Feature Flags (Clean & Scalable)<\/h4>\n
        For bigger apps, using a helper function with a list of all your flags is a good way to keep your code clean and organized.<\/p>\n
        \n
        enum class FeatureToggle(val key: String) {\r\n    NewDashboard(\"feature_new_dashboard\"),\r\n    CheckoutV2(\"feature_checkout_v2\"),\r\n    DynamicBanner(\"feature_dynamic_banner\")\r\n}\r\n\r\nfun isFeatureEnabled(toggle: FeatureToggle): Boolean {\r\n    return Firebase.remoteConfig.getBoolean(toggle.key)\r\n}<\/code><\/pre>\n<\/div>\n
        This prevents you from having to type the same flag names over and over and helps avoid mistakes.<\/p>\n
        Scalable Rollout Strategy<\/h4>\n
        A smart rollout plan lowers risk and lets you test new features with real users before you launch them to everyone.<\/p>\n
        \n\n\n\n\n\n\n\n\n\n\n
        Stage<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
        Dev Only<\/td>\nThe feature is only available to your internal development and test accounts.<\/td>\n<\/tr>\n
        Internal QA<\/td>\nThe feature is turned on for a small group of internal testers.<\/td>\n<\/tr>\n
        5% Rollout<\/td>\nYou release the feature to a small percentage of real users to get early feedback and check for problems.<\/td>\n<\/tr>\n
        50% Rollout<\/td>\nYou slowly give the feature to more users to make sure it’s stable and works well.<\/td>\n<\/tr>\n
        100% Rollout<\/td>\nThe feature is stable and is turned on for all users.<\/td>\n<\/tr>\n
        Cleanup<\/td>\nAfter the feature is fully released and stable, you remove the switch and the old code.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
        Analytics & Monitoring<\/h4>\n
        To make decisions based on facts, you must link your feature flags to your crash reports and analytics. Firebase Crashlytics and Analytics make this easy.<\/p>\n
        \n
        \/\/ Tell Crashlytics which features are on for the user\r\nCrashlytics.setCustomKey(\"feature_new_dashboard\", isFeatureEnabled(FeatureToggle.NewDashboard))\r\n\r\n\/\/ Track which version of a test a user is in\r\nFirebase.analytics.setUserProperty(\"checkout_variant\", variant)<\/code><\/pre>\n<\/div>\n<\/section>\n
        <\/p>\n
        \n
        Conclusion<\/h3>\n
        Using Feature Toggles, Remote Config, and A\/B Testing changes the way you build apps for the better. Instead of big, risky releases, you can constantly improve your app based on what you learn. You can try new ideas with a small group of users, turn off bad features right away, and make the app better for everyone.<\/p>\n
        By shipping faster without fear, you can stay ahead of the competition and build a product that your users truly love.<\/p>\n<\/section>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
        Imagine you’re an app developer. You’ve worked hard on a new feature, but just before it’s ready, a bug appears. You have a hard choice: either you delay the launch to fix the bug, or you release the feature with the bug and hope it doesn’t cause problems. This happens because usually, when you release […]<\/p>\n","protected":false},"author":2121,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":53},"categories":[518],"tags":[4845],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73900"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/2121"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=73900"}],"version-history":[{"count":8,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73900\/revisions"}],"predecessor-version":[{"id":76707,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73900\/revisions\/76707"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=73900"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=73900"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=73900"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}