Release Strategy

What is a Staged Rollout

A staged rollout gradually exposes a new version to an increasing percentage of users. Instead of releasing to 100% of users at once, you start with 1-5%, monitor crash rates and user feedback, and increase the percentage as confidence grows.

Rollout Stages

A typical staged rollout follows this pattern:

Implementing in Play Console

When publishing a new version:

1. Go to Release > Production
2. Create a new release and upload your AAB
3. Set the rollout percentage to your starting value (e.g., 5%)
4. Monitor the Android Vitals dashboard for crash rates
5. Increase the percentage when metrics are stable
6. If issues arise, use Halt rollout to stop distribution immediately

Automated Rollout with Fastlane

You can automate percentage increases with fastlane:

# Fastfile
lane :promote_to_production do
  # Promote from internal to production at 5%
  supply(
    track: 'internal',
    rollout: '0.05',
    package_name: 'com.example.myapp'
  )
end

lane :increase_rollout do |options|
  supply(
    track: 'production',
    rollout: options[:percentage],
    package_name: 'com.example.myapp'
  )
end

Rollout Monitoring

During rollout, watch these metrics:

• Crash-free users — Must remain above 99.5%
• ANR rate — Should be below 0.47%
• User reviews — Spike in negative reviews signals problems
• Uninstalls — Sudden increase indicates a broken release

What Feature Flags Do

Feature flags (also called feature toggles) decouple code deployment from feature release. You can merge code to production without exposing it to users, then enable it remotely when ready.

Simple Feature Flag Implementation

A basic feature flag system using SharedPreferences or a remote config:

class FeatureFlags(private val context: Context) {
    private val prefs = context.getSharedPreferences("feature_flags", Context.MODE_PRIVATE)

    fun isEnabled(flag: String): Boolean {
        return prefs.getBoolean(flag, false)
    }

    fun setEnabled(flag: String, enabled: Boolean) {
        prefs.edit().putBoolean(flag, enabled).apply()
    }
}

// Usage in a composable
@Composable
fun HomeScreen(featureFlags: FeatureFlags) {
    if (featureFlags.isEnabled("new_checkout_flow")) {
        NewCheckoutScreen()
    } else {
        LegacyCheckoutScreen()
    }
}

Remote Feature Flags with Firebase Remote Config

For server-controlled flags without app updates:

val remoteConfig = Firebase.remoteConfig
val configSettings = remoteConfigSettings {
    minimumFetchIntervalInSeconds = 3600 // 1 hour in production
}
remoteConfig.setConfigSettingsAsync(configSettings)

// Set defaults
remoteConfig.setDefaultsAsync(mapOf(
    "new_checkout_flow" to false,
    "dark_mode_enabled" to true
))

// Fetch and activate
remoteConfig.fetchAndActivate().addOnCompleteListener {
    if (it.isSuccessful) {
        val newCheckout = remoteConfig.getBoolean("new_checkout_flow")
        // Apply the flag
    }
}

Kill Switch Pattern

Use feature flags as kill switches for problematic features:

// In your network layer
val experimentalApiEnabled = Firebase.remoteConfig.getBoolean("experimental_api")

if (experimentalApiEnabled) {
    return experimentalApiClient.getData()
} else {
    return legacyApiClient.getData()
}

If the new API causes issues, disable it remotely without an app update.

Flag Lifecycle

Feature flags should be temporary. Follow a cleanup process:

1. Create — Add the flag with a default value
2. Roll out — Enable for percentage of users
3. Confirm — Verify metrics and user feedback
4. Cleanup — Remove the flag and dead code branches

Long-lived flags accumulate technical debt. Assign owners and set expiration dates.

What A/B Testing Means

A/B testing compares two or more variants to determine which performs better. Users are randomly assigned to variants, and a primary metric determines the winner. This replaces opinion-based decisions with data.

Setting Up A/B Tests with Firebase

Firebase Remote Config supports A/B testing through Firebase Experiments:

1. Open Firebase Console > Remote Config
2. Create a new parameter with conditional values
3. Create an A/B test linking the parameter to an audience
4. Define the success metric (conversion rate, engagement, retention)

Anatomy of a Good A/B Test

Every test needs:

• Hypothesis — "Changing the checkout button color from gray to green will increase conversion by 5%"
• Control — The current version (button = gray)
• Variant — The new version (button = green)
• Primary metric — Checkout completion rate
• Secondary metrics — Revenue, session length, crash rate
• Minimum sample size — Calculate using statistical significance tools

Example A/B Test Implementation

// In your composable
@Composable
fun CheckoutButton(firebaseRemoteConfig: FirebaseRemoteConfig) {
    val buttonColor = if (firebaseRemoteConfig.getBoolean("checkout_green_button")) {
        Color(0xFF4CAF50) // Green variant
    } else {
        Color(0xFF9E9E9E) // Gray control
    }

    Button(
        onClick = { /* checkout logic */ },
        colors = ButtonDefaults.buttonColors(containerColor = buttonColor)
    ) {
        Text("Complete Purchase")
    }
}

Interpreting Results

Wait for statistical significance before declaring a winner:

• p-value < 0.05 — Results are statistically significant
• Confidence interval — Shows the range of likely effect sizes
• Segment analysis — Check if results hold across user segments

Common pitfalls:

• Stopping tests too early when one variant is ahead
• Testing too many variants with insufficient traffic
• Ignoring secondary metrics (a button change might increase conversions but hurt retention)

Release Strategy Integration

Combine all three techniques:

1. Feature flag — Merge code with the flag off
2. A/B test — Enable the flag for a test audience, measure impact
3. Staged rollout — If the variant wins, roll out to all users gradually

This pipeline minimizes risk at every stage.