Build1 publisher3 min readPublished
Shorebird's Dart-only patches swap store review for the user's next app restart
A one-line logic error took about 8 hours to fix on Android and 12 on iOS through the stores, so one Flutter team moved Dart fixes to code push, where the wait is a background download and a restart.
The Engineer · Build desk
What happened
- A Flutter team shipped a build with a small logic error that needed a one-line fix, and found out when the app started crashing on users' devices and Sentry fired nonstop.
- The corrected build took about 8 hours to go live on Android and 12 hours on iOS, and the crashes continued for the whole of that wait.
- The team adopted Shorebird, a code push tool that sends Dart updates, called patches, to phones already running a released build without a new store submission or store review.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Triage now turns on the shape of the fix: Dart-level fixes go out as patches, and anything touching a plugin or a permission goes back into the store queue.
- cost Adopting code push puts a vendor between the fix and the users, so Shorebird's CDN availability becomes part of your incident response, alongside the Google OAuth and storage hosts the install depends on.
- constraint Uptake is bounded by when users relaunch, so a bug on a long-lived screen keeps a long tail of affected sessions.
- cost Because a patch is scoped to one release version, every version still in use needs its own patch push, and supporting old releases becomes a recurring task.
You cannot patch until you have a release, and the release is the build you upload to Google Play or the App Store [9]. A patch is built on top of that release and reaches every user running that version [9][10]. Users still on an earlier release do not get it.
Delivery still takes time. The patch downloads in the background with no user action [5], and it takes effect the next time the app restarts [6]. Store review comes out of the repair time and the restart interval goes in. For a crash loop that is fast, because the app is already dying and relaunching. For a wrong total on a screen people leave open, the window is whatever your session behaviour is. The Console's Insights tab counts unique device launches, and the same device launching twice counts once [17].
The 8 and 12 hour figures are one team's wall clock on one incident, with crashes continuing the whole time [3]. iOS was 4 hours slower, 1.5 times the Android wait [18]. For those to be planning numbers anywhere else, the submissions would have to sit in the same queue at the same priority, with no manual review triggered. The post reports the one incident and does not say how long its other submissions took [20]. Check your own submission history for the same app. On the writing side, the post's author wrote: "We fixed the code fast. But shipping the fix was slow." [2]
The config that separates patch streams is the flavors block in shorebird.yaml. `shorebird init` or `shorebird create` writes that file into the project root, and it is meant to be committed [11]. The team runs two flavors, dev and prod [8]. Each gets its own app ID in that file, `dev: 864ab1b0-ba78-4b15-990a-a63cec35a41b` and `prod: 6b6e6631-4fbe-4645-8d9d-d5247656d975`. Those IDs keep dev patches away from prod devices, and the app_id is not a secret [12].
`shorebird doctor` checks five endpoints before it calls the install healthy: api.shorebird.dev, console.shorebird.dev, oauth2.googleapis.com, storage.googleapis.com and cdn.shorebird.cloud. The last answered in 96 ms in the published run [13]. You are taking on all five as dependencies, since the path from fix to user now runs through Shorebird's CDN. In the same run, doctor's one complaint was that shorebird itself was out of date [14]. Anyone automating patch pushes should note that Shorebird CI was deprecated on August 8, 2026, with a notice to switch to the open source shorebird package [15].
The scope limit is stated plainly in the docs: Dart code only, and a new plugin or a new permission still needs a store release [7]. So the store path stays in the runbook for those changes, along with `shorebird preview`, which runs a release on a device or emulator before you ship it [16].
What to watch
- Patch adoption curves from push to percentage of devices restarted would replace the restart interval as a guess with a measured number.
- The CI path for the open source shorebird package after the August 8, 2026 deprecation, since that is where patch pushes get automated.
- Any team publishing its own median store review times per platform, which would test whether 8 and 12 hours is typical or one bad day.