Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Shorebird lets you send eligible Dart code patches to users who already have a Shorebird-built release, without submitting each patch as a new store update. It does not remove the initial store submission or guarantee that a patch is permitted by Apple or Google: you build and distribute a base app normally, then use Shorebird for supported changes to that release.
What Shorebird changes—and what it does not
Shorebird separates a Flutter app’s store-distributed release from later over-the-air patches. A release is the baseline associated with a particular app build. A patch adds eligible Dart changes to that baseline; it does not create a new store version or reach people who have not installed a compatible release.
For the baseline, shorebird release builds the app and uploads compiled Dart artifacts to Shorebird. You then submit the resulting Android App Bundle (.aab) or iOS archive (.ipa) through your usual store workflow. Shorebird does not submit the app to Google Play or App Store Connect for you. Later, shorebird patch can distribute supported changes without a new store submission for that release. See Shorebird’s Code Push overview.
Which changes can you patch?
Use a patch for eligible Dart changes, such as updates to widgets, business logic, or state management, provided the build remains compatible with the release. A new store release is needed when a change requires modifying the native app or its packaged contents.
#1 Best Overall
| Change | Use a Shorebird patch? | What to do |
|---|---|---|
| Eligible Dart UI, business-logic, or state-management change | Yes, if the patch builds successfully for the target release | Build and publish a patch for that release |
| Kotlin, Swift, Java, Objective-C, platform configuration, or native plugin change | No | Create and distribute a new store release |
| Adding, removing, or changing packaged assets such as images or fonts | No; the patch guide says asset patching is unsupported | Include the change in a new store release |
| New runtime permission, native dependency, or Flutter engine upgrade | Treat as not patchable | Create and distribute a new store release |
Shorebird compares the local build artifacts with those saved for the release and warns or blocks by default when it detects native or asset differences. Do not treat a warning as permission to ship an incompatible change. Check the patch guide for the current behavior and options.
Prepare the project and create its base release
- Install and integrate the Shorebird CLI. Follow Shorebird’s current Code Push documentation for setup. Its documentation landing page specifies Flutter 3.27.0 or later; verify the current prerequisite there against your project before proceeding.
- Check the local environment. Run
shorebird doctorand confirm that the Flutter SDK version matches the version vended by Shorebird for the project. Resolve reported setup or compatibility issues before creating a release. - Build the release for the platform you distribute. Run
shorebird release androidorshorebird release ios. Shorebird describes this command as a replacement for the corresponding Flutter build flow and uses it to upload compiled Dart artifacts as the baseline for later patches. See Create a Release. - Submit the generated app through the normal channel. Upload the resulting
.aabor.ipato the appropriate store workflow, such as Google Play or App Store Connect. Complete the required submission and review process before relying on the release as the installed baseline.
Build and publish an eligible patch
- Make a Dart-only change. Review the change for native code, platform configuration, plugins, permissions, and packaged asset changes. If it depends on any of those, prepare a new store release instead.
- Target the correct release and platform. Run
shorebird patch androidorshorebird patch ios. When needed, specify the release that should receive the patch. A patch is associated with a particular release version; users on a different version need a patch targeting that release or an updated store build. - Review Shorebird’s artifact checks. The CLI compares the new artifacts with the saved baseline and can warn or block when it detects native or asset differences. Investigate these differences rather than attempting to force a patch for changes that require a store build. The command details are in Create a Patch.
- Choose a rollout track. Shorebird supports deployment tracks for staged rollout;
stableis the default track. You can test on a staging track where appropriate before publishing to the intended audience. Track options and current procedures are described in Shorebird’s complete Code Push guide.
When users receive the patch
By default, the app checks for updates in the background on startup. The patch downloads while a user is using the app and normally becomes active on a subsequent app launch—not immediately on every device as soon as you publish it. Shorebird describes the restart behavior in its Code Push overview.
If your app needs an immediate or mandatory update flow, Shorebird provides programmatic update checks through package:shorebird_code_push. That lets the app implement a different user-facing strategy; it does not make unsupported changes patchable. See Update Strategies.
Store review and policy still apply
A Shorebird patch is not a general exemption from store rules. Apple’s App Review Guidelines, section 2.5.2, say: “Apps should be self-contained in their bundles, and may not read or write data outside of the designated container area, nor may they download, install, or execute code that introduces or changes features or functionality of the app, including other apps.” The guideline also describes a limited exception for certain educational apps with specific conditions. Read the current Apple App Review Guidelines and Apple App Review information for the applicable requirements.
Shorebird says its iOS implementation is designed to use an interpreter, but that design does not guarantee that every app or patch complies with Apple’s rules. Shorebird’s FAQ also summarizes Play Store constraints, including restrictions around downloaded executable code and changes that could mislead users or violate their expectations. In either store, the developer remains responsible for the app’s behavior and policy compliance.
Quick Recap
Best Value
Rank #4
Decide between a patch and a store release
- Choose a patch when the change is eligible Dart code, the app already has a Shorebird-built release, and the patch targets the version users have installed.
- Choose a store release when the change touches native code, platform configuration, packaged assets, permissions, native dependencies, or the Flutter engine—or when users need a new base version.
- Use the normal store workflow for first installation. A patch cannot update an app before a user installs a distributed release.
- Plan for rollout and activation. Select the appropriate track, allow for background download, and account for activation on a later app launch under the default strategy.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
