Flutter OTA updates without an app-store review — how it works
A one-line fix to a Flutter app normally means a full store submission and a wait of hours to days. Over-the-air (OTA) code-push collapses that to minutes: you ship the changed Dart to installed apps directly, and the next launch runs the patch. Here's how it works — and where the boundaries are.
Is this allowed by the stores?
Yes, within limits. Both Apple and Google permit apps to download and run interpreted code that doesn't change the app's advertised purpose. OTA code-push stays inside that boundary: it patches logic and UI within the app you already shipped — it does not download a different app. It's the same mechanism React Native's CodePush relied on for years, brought to Flutter's Dart.
What ships over the air — and what doesn't
The patchable surface is the interpreted layer of your app. Arbitrary changes that require a new native binary (new plugins, changed native entitlements) still need a store release. But the vast majority of production hotfixes — a broken checkout flow, a wrong price, a crashing screen — are pure Dart, and those ship instantly.
- Business logic and UI fixes in Dart — shipped OTA
- Copy, thresholds, and config — shipped live via Remote Config
- New native plugins or entitlements — still a store release
Why rollback matters more than push
Shipping fast is easy; shipping fast safely is the hard part. A patch that fixes one screen and breaks another is worse than the original bug because it's now on every device in seconds. That's why Sankofa Deploy gates every Flutter rollout behind feature flags and ties it to crash detection: if the crash rate climbs after a patch, the release rolls back on its own.
OTA without automatic rollback is a loaded gun. OTA bonded to your crash signal is a safety net.
Flutter OTA is the fast lane for mobile teams — and it's a first-class citizen in Sankofa OS, not a bolt-on. See Deploy for the full pipeline.