# App releases (/docs/ship/app-releases)



You build in your app repo; **Appbrew runs the releases**. You do not need fastlane, signing certificates, or store-submission tooling on your machine. The release pipeline builds from your repo's default branch, signs, and submits to both stores.

## One-time setup [#one-time-setup]

* **App Store**: Appbrew needs access to your App Store Connect app. Usually an admin invites Appbrew's release account, or provides an API key for your Apple account. Your Appbrew contact will tell you which applies.
* **Play Store**: access to the app in your Play Console.
* **Signing custody**: Appbrew holds the Android keystore and manages iOS certificates and provisioning profiles for the app. You do not commit or handle signing material.

## Requesting a release [#requesting-a-release]

1. Land your changes on the repo's default branch and verify them locally ([Testing your work](/docs/build/testing)).
2. Ask your Appbrew contact for a release, stating the platform(s) and anything the release notes should call out.
3. Appbrew builds, bumps the app version, submits, and confirms back, including store-review timelines when Apple or Google review applies.

<Callout type="info" title="What needs a release, and what doesn't">
  Native changes — a new dependency with native code, an integration marked
  `requiresNativeBuild`, changes under `ios/` or `android/` — always need a
  store release. App **config** changes (screens, blocks, theme) ship when the
  theme is published from the dashboard and need no release at all.
</Callout>

## Versioning [#versioning]

The release pipeline manages app versions. Don't bump version numbers in the repo yourself. If a release must align with a marketing date or a platform upgrade ([Upgrading](/docs/ship/upgrading)), say so when you request it.