Skip to content

Delete Apps, Releases, and Patches

People usually reach for delete when a patch has a problem, but deleting is rarely the right fix. Think about why you want to delete, and whether one of these options fits better:

  • A patch has a bug. Roll it back instead of deleting its release. A rollback removes the patch from end users’ devices, and you can roll it forward again later if the patch turns out to be fine.
  • You want to test a patch before users get it. Publish it to a staging track.
  • You want to move an app to another organization. Transfer ownership of the app instead of deleting it.

Delete only when you no longer need an app or release at all. If you’re not sure which option is right, reach out and the Shorebird team can help you decide.

Individual patches can’t be deleted. A patch is removed along with the release it belongs to, or the app that owns that release.

If you want to stop serving a patch, you can roll it back. A rollback remotely uninstalls the patch from end users’ devices and falls back to the previous patch or the base release. You can undo a rollback later if you need to.

Roll back a PatchRemotely uninstall a patch. You can undo a rollback later.

Releases are deleted per platform. When you delete a release, the dialog asks which platforms to delete, and your choice determines what is removed:

  • All deletes the release itself, along with its artifacts and every patch published to it. Devices will no longer receive patches for that release version.
  • A single platform deletes that platform’s release and patch binaries. The release itself remains, and the other platforms are untouched.

In both cases, the deleted binaries can’t be restored.

See Delete releases for the steps, the platform selection dialog, and shorebird releases delete.

Deleting an app also deletes every release, patch, and artifact associated with it. Copies of the app that are already installed on end users’ devices keep working normally, but they won’t receive new patches.

If you want to move an app to another organization, use Transfer ownership in the same Danger zone instead of deleting it.

  1. Navigate to the app in the Shorebird console.
  2. Go to the Settings tab.
  3. In the Danger zone, under Delete app, select Delete.
  4. Confirm in the dialog that appears.

From the command line, shorebird apps delete opens this page. The Settings tab is shown only to Admins and the Owner; an App Manager can delete the app too, from the page that command opens.

If you deleted an app or release by mistake

Section titled “If you deleted an app or release by mistake”

Shorebird can’t restore it, but copies of your app already installed on users’ devices keep working, and keep running the patch they already have. They won’t receive another patch until they update from the store to a new release.

On an Enterprise plan, the audit log records who deleted an app (app.delete) or a release (release.delete), and when.

Running shorebird release again for the same version doesn’t reconnect those devices. It creates a new release with a new build, and patches made for that build can’t install on the build already in the store. See Patches can’t install because the app isn’t the build Shorebird released.

To patch your users again:

  1. Release a new version with shorebird release.
  2. Publish that build to the stores.

Patches made for the new version install on devices once they update to it.

Builds already in the stores carry the deleted app’s ID, and a new app always gets a new, random ID, so those builds can’t receive patches again. To start patching again:

  1. Create a new Shorebird app with shorebird init --force, which writes a new app_id to shorebird.yaml. It rewrites the file with only app_id (and flavors), so check the diff and put back any other settings, such as auto_update: false, before you commit.
  2. Release with shorebird release, and publish that build to the stores.

In a project with flavors, shorebird init --force gives every flavor a new app ID, which disconnects the flavors you didn’t delete too. Instead:

  1. In shorebird.yaml, remove the deleted flavor’s line under flavors:. If the top-level app_id is the same ID as that flavor’s (shorebird init sets it to the first flavor’s app when every platform has flavors), set it to a remaining flavor’s ID.
  2. Run shorebird init without --force. It creates a new app for that flavor and keeps the others.
  3. As with --force, check the shorebird.yaml diff and put back any settings it dropped before you commit.

Deleting your account removes every organization where you’re the only member, and everything in them. If you own an organization that has other members, transfer or delete it first. See Delete Account for everything deletion removes and what blocks it.

You delete your account on the Account page in the console. From the command line, shorebird account delete opens that page.

Delete AccountPermanently delete your Shorebird account and all associated data.