Build ≠ Distribute: the model
AppRelay separates how a project builds from where each build ships, so one build can fan out to many destinations with no code changes.
Last updated 2026-07-02
The single most important idea in AppRelay is that how a project builds and where it ships are two different things. Most tooling conflates them — the same script that compiles your app also uploads it, so shipping the same build to a second place means copying and editing that script. AppRelay decouples the two.
The model
- Toolchain (build side)
- A lane has exactly one toolchain — it produces an artifact. “Build this React Native app.”
- Distribution (ship side)
- A lane has one or more distributions — each takes the artifact somewhere. “Send it to the App Store,” “…and to Firebase.”
This is a many-to-many mapping. One build can fan out to several destinations; conversely, a single build can be sent to whichever one destination you choose at release time.
Worked example
A React Native app that ships to three stores:
- One toolchain:
reactNative(orexpo), one version source, one build command. - Three distributions: App Store Connect, Play Console (production track), and Firebase App Distribution.
The build runs once; each distribution takes the result to its destination. A Next.js site is the mirror image: one node build, and a distribution that's either Vercel or an S3 + CloudFront sync — swap the destination without touching the build.
What a distribution carries
| Field | Purpose |
|---|---|
| Label | A human name for this destination. |
| Channel | Which distribution channel this is (App Store, Play, Vercel, S3, …). See the channels reference. |
| Recipe | The steps that actually deliver the build — see Recipes. |
| Signing | The signing method for this destination (App Store Connect, Android upload key, Developer ID + notarize, …). |
| Parameters | Channel-specific knobs — e.g. Play track, S3 bucket + distribution id, Docker image + tag. |
| Secret references | Named references to secrets needed at delivery time (never the secret values themselves). |
Signing methods
Signing belongs to the distribution, because the same build may be signed differently for different destinations. Available methods include App Store Connect, Gradle-configured signing, a configured jarsigner, Developer ID with notarization, an Android upload key, Windows code signing, or none.
Adding a destination
- Open the lane in the project editor's Lanes section.
- Add a distribution. Pick its channel, choose or duplicate a recipe, and set the signing method.
- Fill the parameters the channel needs (and reference any secrets).
- Save. The new destination now appears alongside the others and runs from the same build.