AppForShareGet started

Docs

Move testers and releases from Bitrise Release Management

You can keep Bitrise CI. Moving from Bitrise Release Management means adding one upload step after your build, mapping install pages, access links and tester groups, bringing your testers, and connecting the stores. This guide covers each step and what it needs.

  1. Step 1, Every plan

    What changes

    Bitrise keeps building. Only the part after the build moves: testers install from AppForShare links with no account, and the store steps run from AppForShare with your own App Store Connect and Google Play keys.

    Links follow your plan: 7 days on Free, and as long as you subscribe on Pro and Team. For a link that keeps working across builds, use a channel link: one address that always opens the newest build you put into it.

  2. Step 2, Pro and Team

    Add the upload step

    Create an API token in AppForShare under Dashboard, Settings and add it in the Workflow Editor as a Secret named APPFORSHARE_TOKEN. Then add a Script step after the Xcode Archive, Android Build or Gradle Runner step. Use $BITRISE_APK_PATH or $BITRISE_AAB_PATH for Android; an .aab becomes one APK testers install.

    The step prints the install link and the store readiness result. With --fail-on blocked it fails with exit code 2 when the check finds a blocker; the build stays uploaded. An AppForShare step for the Bitrise step library is in review. Until it is listed, the Script step does the same.

    #!/usr/bin/env bash
set -e
npx --yes appforshare upload "$BITRISE_IPA_PATH" \
  --notes "$GIT_CLONE_COMMIT_MESSAGE_SUBJECT" \
  --channel beta --fail-on blocked
    Upload from Bitrise

  3. Step 3, Free, Pro and Team as noted

    Map install pages, access links and tester groups

    A public install page is a build link here, on every plan, or a channel link when testers should always get the newest build (Pro and Team). An access link with its own expiry is an extra link with a stop date (Pro up to 3 per build, Team up to 20). An access code is a password per build (Free and up), or per tester access codes that each allow a set number of devices (Team).

    An external tester group is a tester group (Team): testers are emailed when a new build is shared with them, and you see per tester whether they installed the newest build. A private install page is a private project that only invited testers can open, with no account (Team). "What to test" text becomes release notes (Pro and Team), and every build can get an AI test plan (every plan with an account).

    npx appforshare link add 12345 --label "QA team" --stop 2026-12-31
npx appforshare upload app.ipa --channel beta --groups "QA,Clients"
    Several links per build

  4. Step 4, Team, device onboarding on Pro and Team

    Bring your testers

    Import your tester list as a CSV file on the Testers page or with the CLI. Invites are off by default, so nobody is emailed until you share a build. Groups named in the file are made for you.

    iPhone testers do not need a profile anywhere. Turn on the onboarding link of the iOS project and send it: testers install a profile, their device lands in your device list, and with an App Store Connect connection an Admin registers it on Apple in one click. You then build again on Bitrise as usual.

    npx appforshare testers import testers.csv
    iOS device registration

  5. Step 5, Pro and Team, Play production on Team

    Store steps

    Connect your App Store Connect team key and a Google Play service account on the Stores page. Keys are encrypted with Google Cloud KMS and never shown again.

    For the App Store, the review card checks what Apple needs before an Admin sends a version for review, and controls the 7 day phased release. For Google Play, the releases page shows every track; Pro promotes between testing tracks, Team also promotes to production and sets, raises, halts, resumes and completes the rollout. Every change is made by an Admin with a confirm tick, never automatically. On Team, the release checklist holds the Live channel until every step is ticked.

    Google Play releases

  6. Step 6, Pro and Team

    Notifications

    Post new builds, installs, tester feedback and store status changes to Slack, Microsoft Teams, Google Chat, Discord or a signed webhook. Store status covers App Store review states and Google Play release states.

    Webhooks

  7. Step 7, Pro and Team

    AI coding tools

    Connect Claude, Cursor, VS Code or another MCP client to the hosted AppForShare MCP server with OAuth sign in, for uploads, links, readiness and testers. The Bitrise MCP server can stay connected for your builds; the two do different jobs.

    MCP server

  8. Step 8, Your choice

    Clean up on Bitrise

    Once testers use the new links, turn off the public install pages and remove the access links you no longer need in Bitrise Release Management, so old links stop handing out old builds. Your Workflows, Secrets and build history stay as they are.

    Bitrise: distributing builds to testers

Questions

Do I have to leave Bitrise CI?
No. Bitrise keeps building; one Script step after the build step uploads to AppForShare.
Do my Bitrise install links move over?
No. They stay on Bitrise. Upload the builds your testers still need here and send the new links, or one channel link that keeps working for later builds.
Is there an AppForShare step in the Bitrise step library?
One is in review. Until it is listed, the Script step with the CLI does the same upload, channel and readiness check.
Do testers need an account?
No. Testers open the link on the phone and install. Invited testers of a private project get an emailed link, still with no account.
Can AppForShare raise a Google Play rollout on its own?
No. An Admin sets, raises, halts, resumes or completes the rollout with a confirm tick (Team). AppForShare never changes a rollout by itself.

Weighing the two first? Read AppForShare vs Bitrise. For the upload commands, see Upload from CI.