Skip to content

CONCEPT Cited by 1 source

Platform-asymmetric rollout control

Definition

Platform-asymmetric rollout control is the observation that iOS and Android offer materially different control surfaces for staged production rollouts, and that this asymmetry shapes the rollout schedule a mobile team can execute.

The two platforms

Capability Google Play App Store
Arbitrary rollout % ✅ ❌ (pre-determined schedule)
Full halt of new installs ✅ ⚠️ pause only — users can still manually update
Hotfix approval time fast up to ~24 hours

(See systems/google-play-console, systems/app-store-connect.)

Operational consequence

Shopify (see sources/2025-09-12-shopify-migrating-to-react-natives-new-architecture) routed Android ahead of iOS because Android was the platform on which a full stop was possible. Shopify's concrete schedule:

  • Day 1 — Android 8%, iOS 0%. Early signal from Android because it can be halted.
  • Day 2 — Android 30%, iOS 1%. Substantial Android ramp; low iOS exposure keeps recovery window open.
  • Day 3 — Android 100%, iOS 100%. Full rollout.

Note the iOS jump from 1% → 100% on day 3 — because there's no meaningful intermediate percentage to hold at. Once Shopify had confidence, fine-grained iOS control wasn't an option they could use anyway.

Why iOS is the higher-blast-radius platform during migration

Three reasons from the same source:

  1. Can't fully halt. Users can manually update; paused ≠ unavailable.
  2. Slow hotfix. Up to 24 hours for re-review of a fix submission; rollback requires another submission too.
  3. No fine-grained %. Can't hold at, say, 5% for a week to soak.

The combination means that if a bad build escapes to iOS at a sensitive rollout stage, the recovery costs are materially higher than Android's. This justifies the Android-first rollout ordering.

Why this matters for native-binary migrations

This concept is especially load-bearing for migrations (like Shopify's new-architecture migration) where the change can't be gated by a remote feature flag. For remote-config-gated rollouts, the store-level rollout percentage is a secondary control — the binary is out there either way, and server-side config controls adoption. For native-binary changes, the store rollout is the only rollout, and the store's limitations are your limitations.

Last updated · 470 distilled / 1,213 read