DEV Community

Cover image for Flutter code push with Shorebird: when can a hotfix be a patch?
Stacklyn Labs
Stacklyn Labs

Posted on

Flutter code push with Shorebird: when can a hotfix be a patch?

#flutter #dart #mobile #devops

A critical bug is in production. The fix is one line. Do you wait days for store review, or push it over the air?

With Flutter, the answer depends on what the fix touches.

Why React Native-style code push doesn't apply

React Native apps run JavaScript, so tools can swap the JavaScript bundle at runtime.

Flutter compiles your Dart code ahead of time (AOT) into native machine code. There is no bundle to swap. That's why the classic CodePush approach doesn't work for Flutter.

How Shorebird does it

Shorebird takes a different route:

  • Your app ships with a Shorebird-enabled fork of the Flutter engine.
  • When you publish a patch, Shorebird compares the new Dart AOT snapshot with the released one and produces a binary diff, often only a few kilobytes.
  • The app checks for patches in the background, downloads the patch, and applies it on the next restart, not while the user is mid-tap.

In practice, the workflow splits into two commands:

# A full release: builds the base binary you submit to the store
shorebird release android
shorebird release ios

# A patch: a Dart-only fix delivered over the air to that release
shorebird patch android
shorebird patch ios
Enter fullscreen mode Exit fullscreen mode

Patch or release?

Because Shorebird patches the Dart AOT snapshot, the boundary is clear.

A patch can carry:

  • Dart-only changes: logic fixes, UI fixes, anything written in Dart

A full release (new .aab / .ipa through store review) is needed for:

  • changes to Swift, Objective-C, Kotlin or Java code
  • updating plugins that wrap native SDKs, such as a camera or payments plugin, because their native code can't be patched
  • Flutter version upgrades, which change the engine itself
  • sweeping asset changes, often

The quick test: did the fix touch anything outside Dart? If yes, it goes through the store.

A useful habit

Keep native changes and Dart changes in separate releases when you can. If a release mixes a native SDK upgrade with Dart logic changes, a bug in the Dart part may still be patchable, but anything in the native part means another store submission.

What about Apple's rules?

The relevant rule is in the Apple Developer Program License Agreement, section 3.3.1(B): interpreted code may be downloaded to an app only under set conditions, and the first is that it doesn't change the app's primary purpose. App Review Guideline 2.5.2 draws the same line: an app may not download code that introduces or changes its features or functionality.

So code push is for fixes, not for shipping new features around review. Shorebird's FAQ explains how its iOS patches run through an interpreter to stay within that rule. Read it before you rely on code push for an iOS app.

Further reading: Flutter over-the-air updates: a technical deep dive on our blog covers the AOT snapshot and patch pipeline in more detail.

Have you shipped a code push patch to production yet? How did review-free hotfixes change your release process?

Top comments (0)