Bitrise public install page: how it works, limits, what to add
· 7 min read
If your app builds on Bitrise, the quickest way to get a build onto a tester's phone is often the public install page in Bitrise Release Management. Turn it on for a build, copy the link or show the QR code, and the tester installs. This article explains how that page works, how it differs from the private install page and from access links, what the limits are on iOS, and what testers may still need around it. AppForShare is the tool we make, and it comes up at the end as one way to fill the gaps, so read those parts with that in mind.
Bitrise facts are as read on November 4, 2026 in its managing builds and distributing builds to testers docs, the pricing page and the posts linked below. We did not sign up, so anything that only shows inside an account is left out.
Where install pages live in Bitrise
Builds reach Release Management as installable artifacts: from a Bitrise CI workflow, or from any other CI through Bitrise's API. The build distribution page lists them. Each build page shows where the build came from, when it was made, its size, the device types it supports, a QR code, an Install button and, for APK and AAB files, a Download artifact button. Release Management Basic, which Bitrise lists as free "with existing Bitrise plan", covers this manual distribution with 1,000 artifacts per app, 2 GB per artifact and 150 day retention, as listed on November 4, 2026. Standard, at $250 per app per month billed yearly, keeps builds for 365 days.
Private install page, public install page and access links
Bitrise has three ways to let someone in:
| Way in | Who can open it | Notes |
|---|---|---|
| Private install page | People with a Bitrise login on the project | Launched in June 2024 (Bitrise blog) |
| Public install page | Anyone with the URL or QR code, no account | A toggle per build |
| Custom access links | Anyone with that link, optionally with an access code | Several per artifact, each with its own expiry or none |
The docs say: "You can create multiple access links for the same artifact, with different expiration times, or no expiration time at all." That is useful when one client should lose access next week and another should keep it. A "What to test" text of up to 4,000 characters per build shows on the build page and on the public install page, so testers see what to look at.
External tester groups
Since July 2026 Bitrise has external tester groups: "Add testers by email, no Bitrise account needed", per its announcement of July 6, 2026. Members get an email with an access link to an install page that "can be further protected with an expiry date and an access code". Which plan this needs is not stated in the post. For testers outside your company this closes the main gap of the private page, which needs a login.
The iOS catch: the device must be in the build
On iOS, an over the air install only works when the build is signed Ad Hoc, Development or Enterprise, and for Ad Hoc and Development the iPhone's UDID must be in the provisioning profile. Bitrise's docs put it as the device being "registered for your user and for this build". This is an Apple rule, and every install page has to live with it.
How a device gets there on Bitrise, per its test device docs: a Bitrise user registers the device from the Profile page in Safari, or someone adds the UDID by hand, and Bitrise's Xcode signing steps with App Store Connect API auto provisioning add registered devices to Apple during a build. A way for a tester who has no Bitrise account to send their UDID was not found in its docs. A 2021 forum answer says devices must be on a Bitrise account first. So an external tester with a new iPhone usually has to find the UDID some other way and send it to you.
A free way that needs no account anywhere: send the tester to our UDID finder. It installs a signed profile that reads the UDID and shows it, and the tester can email it to you. You then add it on Bitrise or in the Apple Developer portal and build again. More on that in register a tester's iPhone without making them sign up.
What we did not find on Bitrise install pages
These were not found in the Bitrise docs we read on November 4, 2026. That is not proof they do not exist, and Bitrise ships often:
- Install page languages other than English.
- Install help when an iOS install fails, such as a warning before the tap that the device or iOS version will not work.
- Tester feedback or screenshots sent from the install page.
- White label or a custom domain for install pages.
- Install analytics per device or country (the product page mentions "tester activity"; details not checked).
If none of these matter to your testers, the public install page may be all you need.
What to add for testers, and how
If they do matter, you can keep Bitrise CI and Bitrise build pages for your own team, and give external testers an AppForShare link from the same workflow. Add an API token (Pro and Team) as a Bitrise Secret named APPFORSHARE_TOKEN, then 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 betaUse $BITRISE_APK_PATH or $BITRISE_AAB_PATH for Android. An AppForShare step for the Bitrise StepLib is in review; until it is listed, the Script step does the same. The guide is upload from Bitrise. What testers then get:
- No account. The install page opens from the link or QR code.
- 13 languages, picked from the phone (install page languages).
- Install help: a note above Install when the iOS version is too old, the profile has ended, the build is iPad only or App Store signed, plus fixes for "Unable to install" and Android's "App not installed".
- A device check. A tester who taps Remember this device on the UDID finder sees on each iOS install page whether their iPhone is in the build (iPhone device check). On Pro and Team, if the device is not in the build and the project's onboarding link is on, they can send it to you from the page.
- Feedback with up to 5 screenshots from the install page, on every plan with an account, with no SDK.
- One link that stays. A channel link always opens the newest build put into it (Pro and Team).
Access links map too. Extra links per build with their own label, password, stop date and install cap are on Pro (3 per build) and Team (20), see several links per build. A password per build works on Free. Invited tester groups with per tester status, private projects and reminder emails are on Team (tester groups). On Team, white label and a custom domain for install pages are included.
Retention and file size, side by side
Bitrise figures as listed on November 4, 2026; ours from pricing.
| Bitrise Release Management | AppForShare | |
|---|---|---|
| Free tier | Basic, with an existing Bitrise plan: 2 GB per artifact, 150 days | Free: 150 MB per file, links live 7 days |
| Paid | Standard: 365 days, $250 per app per month (yearly) | Pro $12 a month: 2 GB, links live while subscribed; Team $39: 4 GB |
| Tester account | Not needed for public pages and external groups | Not needed |
| Languages | English found | 13 |
| Feedback from the page | Not found | Free and up |
Said plainly: on free file size and retention Bitrise is ahead. Basic keeps 2 GB builds for 150 days, while our Free plan is for short tests. Our case is the tester side, not the free tier.
Common questions
Does the Bitrise public install page need a tester account?
No. As read on November 4, 2026, the public page opens from its URL or QR code without an account. The private install page needs a Bitrise login.
Why does an iPhone say it cannot install the app?
Most often the device is not in the build's provisioning profile, or the profile has ended. Add the UDID, build again and share the new build.
Can I turn a public install page off later?
Yes, it is a toggle per build, and access links can be removed. Links made with no expiry keep working until you remove them, so clean them up when a test ends.
Can I use both?
Yes. You can keep Bitrise for builds and internal sharing and send outside testers an AppForShare link from the same workflow. See Bitrise Release Management alternative and AppForShare vs Bitrise.
