Move tester builds and releases off Bitrise, keep Bitrise CI
· 8 min read
Moving tester builds and releases off Bitrise Release Management does not mean leaving Bitrise. The CI keeps building exactly as it does today; only the step after the build changes, and with it where testers install and where store releases are sent from. This checklist takes the move in order: what changes, the workflow step, how install pages and tester groups map, devices, store steps, notifications, AI tools and cleanup. It uses AppForShare as the destination because that is the tool we make. The short product guide is Move from Bitrise.
Bitrise details are as read on November 4, 2026 in its distribution docs, pricing page and the pages linked below.
What changes and what stays
- Bitrise CI stays. Workflows, stacks, code signing steps and triggers do not change.
- Testers install from AppForShare links, with no account, instead of Bitrise install pages.
- Builds follow your AppForShare plan. Links stay live while you subscribe on Pro and Team, and 7 days on Free. On Bitrise Basic, builds were kept 150 days, so if you rely on long lived links on a free tier, plan for that.
- Store releases are sent from AppForShare with your own App Store Connect and Google Play keys.
The map
| On Bitrise Release Management | On AppForShare |
|---|---|
| Public install page | The build's install link (every plan) or a channel link that always opens the newest build (Pro and Team) |
| Access link with an expiry | An extra link with its own stop date, label and password (Pro 3 per build, Team 20), or a stop date on the build |
| Access code | A password on the build (Free and up) or on each extra link |
| External tester group | A tester group (Team), with emails on new builds, status per tester and reminders |
| Private install page | A private project only invited testers open, from an emailed link, no account (Team) |
| "What to test" text | Release notes on the install page (Pro) plus an AI test plan per build (Free and up) |
| Test devices on Bitrise user profiles | UDID finder (free, no account), onboarding link per iOS project (Pro and Team) |
| Approvals | Release checklist ticked per build by Developers, with an Admin override (Team) |
| TestFlight and App Store review | App Store review sending with phased release controls, by an Admin (Pro and Team) |
| Google Play rollout | Testing tracks (Pro); production rollout %, halt, resume, complete by an Admin (Team) |
| Slack and Teams notices (Standard) | Webhooks to Slack, Microsoft Teams, Google Chat, Discord (Pro) |
Step 1: add the upload step
Create an API token in AppForShare under Dashboard, Settings (Pro and Team). In the Bitrise Workflow Editor add it as a Secret named APPFORSHARE_TOKEN. Then add a Script step after the build step:
#!/usr/bin/env bash
set -e
npx --yes appforshare upload "$BITRISE_IPA_PATH" \
--notes "$GIT_CLONE_COMMIT_MESSAGE_SUBJECT" --channel betaFor Android, upload $BITRISE_APK_PATH or $BITRISE_AAB_PATH; an .aab becomes one universal APK testers install. Add --fail-on blocked to fail the step when the store readiness check finds a blocker; the build stays uploaded. An AppForShare step for the Bitrise StepLib is in review; until it is listed, the Script step does the same. The full guide is upload from Bitrise and the longer tutorial is share a Bitrise build with testers.
Run the workflow once and open the link it prints. If you used --channel beta, the channel link is the one to hand out: it never changes and always opens the newest build in Beta.
Step 2: map install pages and access links
For each Bitrise install page or access link still in use, pick the match from the table. Two notes:
- Bitrise lets you make several access links per artifact, each with its own expiry or none. Our extra links work the same way per build, with a label only you see, and link controls add pause and an install cap (Pro and Team).
- If a client should always get the newest build, give them a channel link rather than a link per build.
Step 3: move testers
On Team, import testers from a CSV file on the Testers page or with appforshare testers import testers.csv. The file needs an email column, and can have a name column and a groups column; groups that do not exist are made. Invites are off by default, so nobody is emailed until you choose. How you get the list out of Bitrise depends on your setup; its Release Management API and its MCP server both list tester groups and testers. Importing testers from Bitrise directly is not something AppForShare does today.
Then put each group on its projects (tester groups), and invite when the first build is ready. Testers see status per project: invited, opened the link, on an older build, has the newest build.
Step 4: iPhone devices
Devices Bitrise already registered on your Apple account stay registered there, and the profiles your Bitrise signing steps make keep them. Nothing has to move for existing testers.
New testers no longer need a Bitrise profile. Send them the free UDID finder, or on Pro and Team turn on the onboarding link for the iOS project: the tester enters an email on the iPhone, installs the UDID profile, and the device lands in your devices list. An Admin registers it on your Apple account in one click (device registration); then build again on Bitrise with a profile that includes it. When a build that includes the device is uploaded, the tester gets one email with the install link. On Team, hands free device setup can register devices on its own, but it starts builds only on GitHub Actions, so with Bitrise CI you start the next build yourself. More in register a tester's iPhone without making them sign up.
Step 5: store steps
Connect your stores under Dashboard, Stores: an App Store Connect team API key (App Manager role is enough) and Google Play through a service account. Pro has one connection per store, Team up to 10. Keys are encrypted and never shown again.
- App Store: the App Store review card checks build, export compliance, review contact and listing text, then an Admin sends with a confirm tick. Release after approval, by hand or on a date, with the 7 day phased release that an Admin can pause, resume or release to everyone. See App Store phased release.
- Google Play: Play releases on Pro promotes between testing tracks and edits release notes. On Team an Admin also promotes to production and sets, raises, halts, resumes or completes the rollout percentage, each with a confirm tick. A person makes each change; nothing steps up on a schedule. See Google Play staged rollouts.
- Approvals: the release checklist (Team) is ticked per build by Developers, and the Live channel takes a build only when every step is ticked, unless an Admin overrides. It is not a named approval per person, and it does not gate store sending.
Step 6: notifications
On Pro add webhooks under Dashboard, Integrations for Slack, Microsoft Teams, Google Chat, Discord or a signed generic URL, and subscribe to store.status for App Store and Google Play status changes, plus build and feedback events. On Bitrise, Slack and Teams release notices are a Standard feature.
Step 7: AI coding tools
If your team uses Claude Code, Cursor or VS Code, connect the hosted AppForShare MCP server with OAuth for uploads, links, testers and readiness (Pro and Team). Bitrise has its own hosted MCP server with OAuth, bitrise-mcp, and it can stay for builds and pipelines. The two do different jobs.
Step 8: clean up on Bitrise
Bitrise's docs say access links can have "different expiration times, or no expiration time at all". Links with no expiry keep working until you remove them. Once testers have the new link, turn off public install pages you no longer need and delete old access links, starting with builds that point at a test server or hold unreleased features. If you were on Release Management Standard only for the store side, check your Bitrise plan once the store steps above work for you.
What you give up, and what you gain
Said plainly: you give up the release object per version with stages and named approval tasks, automatic Google Play rollout steps over 7 days, release presets, CodePush and, on a free tier, 2 GB builds kept 150 days. You gain install pages in 13 languages with install help, UDID collection without any tester account, feedback with screenshots and no SDK, a store readiness check on every build, a listing editor and reviews inbox, and flat prices: Pro $12 and Team $39 a month with 5 seats, not per app. The reasons in more depth are in Bitrise Release Management alternative, the numbers in Bitrise pricing for a small mobile team, and the full table in AppForShare vs Bitrise.
Common questions
Do I have to leave Bitrise CI?
No. Only the step after the build changes.
Do old Bitrise install links stop working?
Not until you turn them off or they expire on Bitrise. That is why step 8 matters.
Can I move builds over from Bitrise?
Upload the builds still in testing again, or run the workflow once. Usually only the newest build per app and platform needs to move.
