Retrojet lets you fix a Flutter app that is already in your users’ hands, without shipping a new build through the App Store or Google Play and waiting for review.

You publish a release through the store as usual, and Retrojet keeps a copy of it. When you change Dart code later, the Retrojet CLI builds a patch for that release and uploads it. Devices that run the release download the patch and use it the next time the app starts.

How an update travels

  1. Release. You build your app with the Retrojet CLI and upload it. This is the build you also submit to the store.
  2. Patch. You change Dart code and publish a patch for that release to one channel, for example staging.
  3. Promote. Once the patch looks good on that channel, you promote the same patch to stable. Its content does not change, only who receives it.
  4. Rollback. If a patch causes trouble, roll it back on the channel where it hurts. Other channels are not touched.

The CLI is where releases and patches are created. The console is where your team checks them, promotes them, and rolls them back.

The pieces

PieceWhat it does
CLI (retrojet)Runs on your machine or in CI. Signs you in, connects a Flutter project, builds and uploads releases and patches.
Console (retrojetdev.cloud)Web app for your team: organizations, members, apps, channels, usage, promote, and rollback.
Your app on devicesChecks for a new patch for its release and reports whether it downloaded and installed.

What works today

Retrojet is in early access. Be aware of what is ready before you plan around it:

PartState
ConsoleReady
retrojet login, whoami, logoutReady
retrojet initReady
retrojet release, retrojet patchIn progress
Install script, access tokens for CIPlanned

Next steps