Bitrise Release Management alternative: keep Bitrise CI, pay flat

Bitrise is best known as a mobile CI: hosted macOS and Linux machines that build your iOS and Android apps from a bitrise.yml. It also sells Release Management, which since 2024 works with any CI: the part that hands builds to testers and walks a version through TestFlight, Google Play and App Store review. Many teams are happy with the CI and only want to know whether the release part has to come from Bitrise too. It does not. This article explains what Bitrise Release Management includes, what a small team needs from that layer, and how to keep Bitrise CI while sharing builds and shipping releases from a flat priced tool. AppForShare is the tool we make, so weigh our parts with that in mind.

Bitrise facts below are as listed on November 4, 2026, from its pricing page, the Release Management page and the docs pages linked in each section. Prices change, so check the pricing page before you decide.

What Bitrise Release Management includes

Bitrise describes Release Management as a way to "upload IPA, APK, or AAB builds from CI or API, assign tester groups, and distribute OTA through private or public install pages", with TestFlight and Google Play, approval gates, staged rollouts, release notes, "what to test" instructions and CodePush for React Native and Expo. A 2024 launch post on its community forum says it works "with any CI tool". It comes in two tiers, as listed on November 4, 2026:

Tier	Price	What it lists
Basic	Free "with existing Bitrise plan"	Manual distribution, 1,000 artifacts per app, 2 GB per artifact, 150 day retention, CodePush access
Standard	$250 per app per month billed yearly, $280 monthly, volume discounts	Automated workflows, 365 day retention, TestFlight and Google Play integration, staged rollout support

Two details matter for the bill. First, "per app" means a connected app, which Bitrise's concepts page defines as one App Store or Google Play app linked to a Bitrise project. Whether the iOS and Android versions of one product count as two apps is not stated on the pages we read. Second, Slack and Microsoft Teams release notices are "only available on the Standard plan" per the notifications docs, and outgoing webhooks in Release Management need a Standard license too (webhooks docs).

So the free tier covers sharing builds by hand, and the store side, notices and automation sit in Standard, priced per app. For one product on two platforms that can be $500 a month on the yearly price if both apps count. The full worked examples are in Bitrise pricing for a small mobile team.

What a small team needs from the release layer

For most small teams and agencies, the list is short and practical:

• Tester links without accounts. A client or a tester taps a link, sees an install page and installs. No sign up.
• iPhones that actually install. Ad hoc builds only install on devices in the provisioning profile, so the team needs a way to collect UDIDs and know whether a tester's phone is in the build.
• Feedback back from testers, with screenshots, without adding an SDK to the app.
• A check before the store does it. SDK versions, target API level, privacy manifests and similar rules, caught on the test build rather than at review.
• The store steps: App Store review with phased release, Google Play tracks and rollout, release notes.
• A price that does not grow with every app. Agencies often have many small apps.

How AppForShare covers that next to Bitrise CI

AppForShare is not a CI and never builds on its own machines. Bitrise keeps building; AppForShare takes the finished .ipa, .apk or .aab and does the tester and store work. What that looks like:

• Install pages with no tester account in 13 languages, with install help that warns before the tap when the iOS version is too old, the profile has ended or the build is App Store signed.
• iPhone devices without any account. Testers read their UDID with the free UDID finder, and with Remember my iPhone each iOS install page says whether their model is in the build. On Pro and Team an onboarding link per iOS project collects devices, and an Admin registers them on your Apple account in one click (device registration). Bitrise test devices are registered from a Bitrise user's profile page or by UDID by hand, per its device docs; a way for a tester without a Bitrise account to send a UDID was not found in its docs.
• Tester feedback from the install page with up to 5 screenshots, on every plan with an account, and from inside the test build through a link. No SDK.
• A store readiness check on every account build, Free and up, with a fix for each issue. It is guidance, not a promise of approval. We did not find an artifact check like it in the Bitrise Release Management docs we read.
• Store steps on Pro and Team: App Store review sending with a checklist and phased release controls, sent by an Admin; Google Play releases between testing tracks on Pro, and production rollouts on Team, where an Admin sets, raises, halts, resumes or completes the rollout percentage with a confirm tick; a listing editor and reviews inbox.
• Webhooks on Pro to Slack, Microsoft Teams, Google Chat and Discord, including release status changes from the stores.
• A release checklist on Team that Developers tick per build, with an Admin override, before a build goes into the Live channel.

Prices are per workspace, not per app: Pro is $12 a month and Team $39 a month with 5 seats. Details are on pricing.

Set it up in a Script step

An AppForShare step for the Bitrise StepLib is in review; until it is listed, the Script step does the same. Create an API token in AppForShare (Dashboard, Settings, Pro and Team), add it in the Workflow Editor as a Bitrise Secret named APPFORSHARE_TOKEN, and add a Script step after your build step:

#!/usr/bin/env bash
set -e
npx --yes appforshare upload "$BITRISE_IPA_PATH" \
  --notes "$GIT_CLONE_COMMIT_MESSAGE_SUBJECT" --channel beta

BITRISE_IPA_PATH is set by the Xcode Archive step, and GIT_CLONE_COMMIT_MESSAGE_SUBJECT by Git Clone. For Android use $BITRISE_APK_PATH or $BITRISE_AAB_PATH; an .aab becomes one universal APK testers can install. --channel beta puts the build into a channel whose link always opens the newest build, so testers keep one address. Add --fail-on blocked if you want the step to fail when the readiness check finds a blocker; the build stays uploaded either way. The full guide is upload from Bitrise, and the longer tutorial is share a Bitrise build with testers.

Where Bitrise is ahead

Said plainly, because it should shape the choice:

• It is a full CI with its own Macs. AppForShare does not build. Our GitHub builds run on your own GitHub Actions minutes, on GitHub hosted runners.
• A free tier with room. Release Management Basic gives 2 GB per artifact and 150 day retention at no cost if you already have a Bitrise plan. AppForShare Free takes 150 MB files with 7 day links; 2 GB needs Pro.
• A release object per version with stages from release candidate to store release, and approval tasks for named stakeholders. Our pieces (build page, release checklist, App Store review card, Play releases page) sit on separate pages, and our checklist is ticked by any Developer rather than by named approvers.
• Automatic Google Play rollouts. Its Google Play docs describe changing the rollout percentage automatically over 7 days, with pause and resume. On AppForShare a person changes the percentage each time.
• Release presets per app with default release notes per language, phased release settings, approvals and notices (release presets docs).
• CodePush for React Native and Expo, free up to 100,000 monthly active users. AppForShare ships whole builds and has no SDK.
• Enterprise options: SLA, self hosted or dedicated machines, build cache and Insights.

Both sides have a hosted MCP server with OAuth for AI coding tools: Bitrise's bitrise-mcp covers builds, artifacts and tester groups, and ours covers uploads, links, testers and readiness (MCP server).

How to choose

Stay with Bitrise Release Management if you want one vendor for builds and releases, if automatic rollout steps and named approvals inside a release matter more than price, or if you use CodePush. If the free Basic tier covers your testing, you may not need anything else.

Add AppForShare next to Bitrise CI if testers and clients struggle with installs, if you collect iPhone UDIDs by hand, if you want feedback and readiness checks on each build, or if per app pricing grows faster than your team. You change one step in the workflow, and Bitrise keeps building. The step by step move is in moving tester builds and releases off Bitrise Release Management and the short guide is Move from Bitrise. The full side by side is AppForShare vs Bitrise.

Common questions

Can I keep Bitrise CI and use AppForShare?

Yes. Add the Script step after your build step. Bitrise keeps building and testers install from AppForShare links.

Is AppForShare a CI like Bitrise?

No. It does not run builds on its own machines. It takes uploads from any CI, and on Pro and Team it can set up builds on your own GitHub Actions.

Does AppForShare do staged rollouts?

Google Play production rollouts on Team and App Store phased release controls on Pro and Team, each done by an Admin. Neither runs on a schedule by itself.

Is there a Bitrise step?

An AppForShare step for the Bitrise StepLib is in review. Until it is listed, the Script step above does the same job.