TestFlight public link and APK in one link and QR code

Your iPhone testers install the beta through TestFlight. Your Android testers install an APK. So every release message carries two links, every printed card carries two QR codes, and at least one tester opens the wrong one and asks what to do next.

This guide covers what a TestFlight public link is and how to create one in App Store Connect, what Apple requires before external testers can install, the options for giving iOS and Android testers a single link, and how an AppForShare channel sends each phone to the right place from one link and one QR code. It ends with when an ad hoc build is still the better choice.

What a TestFlight public link is

TestFlight is Apple's beta testing service. Testers install the TestFlight app on their iPhone or iPad, accept an invitation and install your build from there. There are two kinds of testers.

• Internal testers are members of your App Store Connect team. Apple allows up to 100 of them, and builds are available to them without beta review.
• External testers are anyone else: clients, users, friends. Apple allows up to 10,000 external testers per app. They are organised in external testing groups.

External testers can be invited by email, or through a public link. A public link belongs to one external testing group and looks like https://testflight.apple.com/join/AbCd1234. Anyone who opens it on an iPhone or iPad with TestFlight installed can join the group and install the current build, without you typing their email address anywhere. That makes it the easiest way to share an iOS beta with people outside your team.

How to create a TestFlight public link

1. In App Store Connect, open your app and go to the TestFlight tab.
2. Create an external testing group, or open an existing one.
3. Add a build to the group. If it is the first build of this version for external testers, App Store Connect asks for test information and submits it to TestFlight beta review.
4. In the group, enable the public link. Apple shows the link and lets you copy it.
5. Optionally set a tester limit, so the link stops accepting new testers once that many have joined. Apple also lets you set criteria for who can join through the link, such as device type and OS version.

You can disable the public link at any time, which stops new testers from joining. Testers who already joined stay in the group until you remove them.

What Apple requires

• Beta review for external testers. The first build of a version that you give to external testers goes through TestFlight beta review. Apple does not always need a full review for later builds of the same version, but plan for some waiting time on new versions.
• Builds expire. A TestFlight build can be tested for 90 days after it was uploaded. After that testers can no longer open it, so upload a new build before a long test runs out.
• The TestFlight app. Testers need TestFlight installed. If they open the public link without it, Apple's page asks them to install it first.
• iPhone and iPad only for this flow. A public link does nothing for Android testers, and opening it on a computer only shows Apple's instructions.

The two platform problem

Most apps ship on both iOS and Android, and most teams test both at the same time. On iOS the build is in TestFlight. On Android there is no TestFlight, so the build goes out as an APK through a link, or through a Play testing track.

That gives you two of everything:

• Two links in every release message, one per platform, with a line explaining which is which.
• Two QR codes on posters, slides and printed cards at events, in shops or at a client meeting.
• Testers who open the Android link on an iPhone, or the TestFlight link on an Android phone, and get a page that tells them nothing useful.
• Old links in old messages, because a new APK often means a new link, while the TestFlight link stays the same.

A client or a hundred people scanning a code on a slide need one link that does the right thing on whatever phone opens it.

Ways to share one beta link for iOS and Android

1. Keep two links

Send both links and label them clearly: "iPhone: TestFlight link. Android: APK link." It costs nothing and works fine for a small group of technical testers. It does not help with printed QR codes, and the Android link changes every time you share a new APK unless your tool gives you a stable one.

2. Build your own landing page

A small page on your own site can detect the visitor's platform and redirect: iPhone and iPad to the TestFlight public link, Android to the APK. You get one URL and one QR code under your own domain. The work is in keeping it current: someone has to update the APK address on every build, host the file or point to wherever it lives, and handle the computer case with both options and a QR code. For a team with a web developer and a fixed release process, it is a reasonable choice.

3. Firebase App Distribution

Firebase App Distribution distributes Android builds and iOS ad hoc builds to invited testers. On iOS it does not use TestFlight: the build is ad hoc, so each tester's device UDID has to be in the provisioning profile, and new devices mean a new build. If you want to stay with ad hoc on both platforms, it covers that. If your iPhone testers are already on TestFlight, it does not combine the two.

4. An AppForShare channel with the TestFlight link

AppForShare channels give each project a stable link and QR code that always opens the newest build put into the channel. You can add your TestFlight public link to a channel, so iPhones go to TestFlight and Android phones get the newest APK from the same link.

The right choice depends on where your testers already are. If they are happy with two links, keep two links. If you want one link and one QR code that never change, the last two options are the ones to look at.

How TestFlight and the APK share one link in AppForShare

Channels such as Beta and Live are part of the Pro and Team plans. Each channel has a stable link of the form /c/<code> and a QR code that always opens the newest build put into it. iOS and Android builds are separate projects, and they share channels when they are paired. Pairing is automatic when the bundle id and the package name are the same; otherwise you pair them by hand on the project's Testing page.

Since November 2026 a channel can also hold a TestFlight public link.

1. Turn on the public link in App Store Connect. Use an external testing group as described above and copy the link. It has to be a testflight.apple.com/join/ link; other addresses are refused.
2. Open the project's Testing page in AppForShare. Press the TestFlight button next to the channel, for example Beta, and paste the link.
3. Upload or promote your Android build into the same channel as you do today, from the dashboard or from CI.
4. Share the channel link or its QR code. Nothing else changes when you ship new builds.

What each visitor sees

• iPhone and iPad: redirected to your TestFlight public link, which opens TestFlight.
• Android: the install page of the newest APK in the channel.
• A computer: both rows, TestFlight and the Android build, with the QR code to scan from a phone.

If the channel also contains an ad hoc iOS build, the TestFlight link wins, so iPhones go to TestFlight. Remove the link from the channel and iPhones get the newest ad hoc build in it again, if there is one.

From CI, the CLI or an AI assistant

The CLI sets the link in one line, which fits at the end of a release job:

npx appforshare testflight https://testflight.apple.com/join/AbCd1234 --channel beta --app com.example.app

Use off instead of the URL to remove the link. The CI docs cover the API token and the rest of the CLI. The MCP server has a set_testflight_link tool for the same change from an AI assistant. If your app uses the in-app update check, the channel's update check answer for iOS includes testflightUrl, so a test build can send people to TestFlight instead of to an ad hoc install page.

What it does not do

• AppForShare does not create the public link and does not submit builds for beta review. You turn the link on and handle review in App Store Connect.
• There are no install counts or tester status for the TestFlight side on the channel. Those are in App Store Connect.
• If the plan lapses, the link is ignored and iPhones get the ad hoc build in the channel again. Removing the link works on any plan.

A separate Team feature, TestFlight tester sync, links an AppForShare tester group to an external TestFlight group through an App Store Connect connection. The public link on a channel needs no App Store Connect key; you only paste the link. For a wider comparison, see AppForShare vs TestFlight, and pricing for what Pro and Team include.

When to use ad hoc instead of TestFlight

TestFlight is the easier path for outside testers, but an ad hoc build is still useful in a few cases.

• No beta review wait. An ad hoc build installs as soon as it is uploaded. For a fix that a client needs to see this afternoon, that matters.
• Internal QA on registered devices. If your QA team uses a fixed set of phones whose UDIDs are already in the provisioning profile, ad hoc builds reach them without TestFlight. The free UDID finder helps collect a device's UDID.
• Builds you do not want in TestFlight. Debug builds, builds pointed at a staging server or builds with extra logging are often easier to keep out of App Store Connect entirely.

The trade off is that Apple limits how many devices you can register per year, and every new device needs a new build. That is why ad hoc works best for a small, stable group.

A channel serves one or the other to iPhones, not both. A simple setup is two channels: Beta with the TestFlight link for outside testers, and QA without a TestFlight link for registered devices. Android testers get the newest APK from whichever channel they open, and your internal team still gets ad hoc builds on iPhone from the QA link.

Common questions

How do I share a TestFlight link?

Enable the public link on an external testing group in App Store Connect and send that link. Testers open it on an iPhone or iPad with the TestFlight app installed. The group needs a build that has passed beta review before testers can install.

Can one link work for both TestFlight and an Android APK?

Yes, if something in between checks the visitor's platform. You can build a redirect page yourself, or add the TestFlight public link to an AppForShare channel, which sends iPhones and iPads to TestFlight and Android phones to the newest APK from one link and one QR code.

Does the TestFlight public link expire?

The link itself stays the same until you disable it or the tester limit is reached. The builds behind it expire 90 days after upload, so keep uploading new builds while testing runs.

Do testers need a UDID for TestFlight?

No. TestFlight installs the build without the device being registered in your profile. UDIDs are only needed for ad hoc builds.

Which AppForShare plan includes the TestFlight link on a channel?

Pro and Team, the plans that include channels.