App releases
How your app changes reach the App Store and Play Store.
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
- 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
- Land your changes on the repo's default branch and verify them locally (Testing your work).
- Ask your Appbrew contact for a release, stating the platform(s) and anything the release notes should call out.
- Appbrew builds, bumps the app version, submits, and confirms back, including store-review timelines when Apple or Google review applies.
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.
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), say so when you request it.