Imagine your Flutter app ships a checkout bug on a Friday afternoon. The fix is a two-line Dart change. You know exactly what it is. You have it committed, reviewed, and ready to go in under an hour.
Then you wait.
A day for the build. A day for QA sign-off. Two to three days for App Store review. Another day for staged rollout. By the time users are running the patched version, you’ve spent nearly a week, and your support queue has been full since Saturday morning.
This is not a hypothetical. It’s the default enterprise Flutter release cycle. And it’s the problem Shorebird was built to solve.
The bug in production: three items totaling $112.97 display as $79.99. Users are undercharged — and the team doesn’t find out until the support queue fills up.
The Traditional Enterprise Flutter Release Cycle
Before we look at what changes, it helps to be precise about what the baseline actually looks like. Enterprise teams don’t just run flutter build and submit. There are governance layers, QA gates, and rollout controls that exist for good reason.
Here’s a representative pipeline:
| Stage | What happens | Typical duration |
|---|---|---|
| Code freeze | Feature branch merges, dependency locks | 1–2 days |
| Build & sign | Release build, signing, artifact packaging | 1–2 hours |
| QA cycle | Regression testing, device matrix, UAT | 2–3 days |
| Store submission | Upload to App Store Connect / Play Console | 1–2 hours |
| Review | App Store review (Apple); Google review | 1–3 days (Apple) / hours–1 day (Google) |
| Staged rollout | 5% → 25% → 100% user rollout with monitoring | 2–5 days |
| Observation | Crash rates, session metrics, support volume | Ongoing |
For a planned feature release, this pipeline makes sense. For a one-line critical fix, like a broken payment flow or an incorrect compliance disclosure, each one of those stages is an obstacle standing between your team and your users.
Traditional hotfix timeline: 5–10 business days from “fix is ready” to “all users are running the fix.” In an incident, every hour the bug stays live is another hour of lost revenue, damaged user trust, and mounting support volume. Days are not an acceptable unit of measurement for a broken checkout flow.
Where Shorebird Fits In the Stack
Shorebird builds release infrastructure for Flutter teams. Code push is its flagship capability: after your app is installed on a user’s device, Shorebird can deliver Dart-level patches that install in the background and apply on the next app restart, without going through the app store. This is compliant with both the App Store Review Guidelines and Google Play policies — patches update only the Dart layer, not native binaries, which falls within the permitted over-the-air update category.
A few things are important to understand before we get to the workflow:
What can be patched:
- Any Dart code change. Logic fixes, UI corrections, text changes, API integration updates.
What cannot be patched:
- Native plugin changes (anything that modifies Android or iOS native code, including method channels)
- App icons or native assets
- Changes to app permissions or capabilities
If your fix touches Dart only, which most hotfixes do, it’s patchable.
The New Workflow: CI/CD + Code Push in Practice
Here’s the same pipeline with Shorebird integrated:
| Stage | What happens | Typical duration |
|---|---|---|
| Code freeze | Feature branch merges, dependency locks | 1–2 days |
| Release build | shorebird release instead of flutter build | 1–2 hours |
| QA cycle | Regression testing, device matrix, UAT | 2–3 days |
| Store submission | Upload to stores as before | 1–2 hours |
| Review + rollout | Store review + staged rollout | 2–5 days |
For the full release cycle, the pipeline looks roughly the same. The difference surfaces when something goes wrong after the release ships.
For a hotfix with Shorebird:
| Stage | What happens | With Shorebird | Without Shorebird |
|---|---|---|---|
| Fix branch | Dart-only fix, code review | 1–4 hours | 1-4 hours |
| Build | shorebird patch vs. full release build | ~15 minutes | 1-2 hours |
| QA | Targeted vs. full regression suite | 2–4 hours | 2-3 days |
| Delivery | Patch rollout vs. store review + staged rollout | Hours to 1 day | 3-8 days |
| Total | Same business day | 5-10 business day |
Shorebird hotfix timeline: same business day to next morning. That’s not a small improvement. For teams where incident SLAs are measured in hours, it’s a structural change in what “incident resolved” means.
The patch reaches the device without any store involvement. The app detects it in the background and surfaces a prompt on the next launch:
Shorebird downloaded the two-line Dart fix silently in the background. One tap and a restart — no update prompt from the store, no waiting for review.
The before and after, delivered same day:
|  |
|---|---|
| Before — $79.99 (wrong) | After — $112.97 (patched) |
Shorebird’s console gives you rollout controls comparable to what you’d configure in App Store Connect or Play Console, plus built-in patch analytics:
- Set a rollout percentage (e.g., start at 10%)
- Monitor crash rates and session metrics by cohort (patched vs. unpatched)
- Track patch adoption across your user base
- Increase rollout or roll back with a single action
For enterprise teams that have rollback SLAs or staged rollout requirements, this is where you enforce them, independent of the store.
What Changes for the Team (and What Doesn’t)
What changes
Branching strategy. Add a patch branch convention. When a hotfix lands in main and the release is already live, cut a patch/<version\> branch from the release tag. Only Dart-only changes go here. This keeps the release history clean and makes it clear what each patch contains.
CI/CD pipelines. Add a patch pipeline alongside your existing release pipeline. The patch pipeline is lighter: no full build matrix, targeted regression only, shorebird patch instead of shorebird release.
On-call runbook. Update your incident response runbook. For Dart-only fixes, the hotfix path now goes through shorebird patch rather than an expedited store submission. Define the criteria clearly — “if the fix touches only Dart files in lib/, use the patch path”, so engineers aren’t making judgment calls during an incident.
What doesn’t change
QA gates. Code push doesn’t skip QA. It shortens the timeline because the patch scope is narrow (targeted regression rather than full regression), not because review disappears. Enterprise governance still applies; it just runs faster on a smaller surface.
Native changes. If a fix requires a native code change, it goes through the store. No shortcut exists for that path, and none should. Shorebird doesn’t change that constraint.
The Honest Ceiling
Shorebird is a significant operational improvement for the scenarios where it applies. It’s worth being equally clear about where it doesn’t apply.
If your incident involves a native crash, a broken native plugin integration, a method channel change, or a permissions update, you’re still going through the store. Plan for both paths. Teams that treat code push as a complete replacement for store release hygiene create a different class of problem, they let their release pipeline atrophy and then hit a native-layer incident with a rusty process.
The strongest setup maintains both: a healthy store release pipeline for full releases and native changes, and a fast patch path for the majority of production fixes that touch only Dart.
Getting Started
Shorebird’s documentation covers account setup, the CLI reference, and platform-specific release guides.
If you’re evaluating Shorebird for an enterprise Flutter app and want help structuring the integration — branching strategy, CI/CD pipelines, rollout governance — reach out to the VGV team. This is the kind of delivery infrastructure work we do for enterprise clients, and it’s significantly faster to get right the first time with a team that’s done it before.
