Control who installs your beta build: pause, expire, limit

You send a test build to a client on Monday. By Wednesday the install link is in their company chat, two people you have never met have installed it, and one of them is reporting a bug you fixed three builds ago. Nothing went wrong on purpose. Install links are made to be easy to share, and that is exactly how they leak.

This guide covers how to control who installs your beta build: why links spread, what the real risks are, which tools fit which situation, and a short playbook for common cases. At the end it shows how install link controls work in AppForShare, including the CLI and the MCP server.

Why an install link leaks

An install link is a URL. Anyone who has it can open it, and most people who receive one have no reason to think it is private. The usual ways it spreads:

• Forwarded in chats. A tester shares the link with a colleague who "also wants to try it". The colleague shares it again.
• Posted in public. A link pasted into a public channel, a forum thread or a support ticket can be found and opened long after the post was written.
• Shared inside a client company. You send the build to one stakeholder. They forward it to the whole team so everyone can review, which is reasonable from their side.
• Old builds keep circulating. Links from earlier builds stay in inboxes and bookmarks. People install whatever link they find first, not the newest one.

What is actually at risk

Most leaks are harmless, but a few outcomes are worth preventing.

• Unreleased features. A beta can show a feature, a price or a partner integration that is not public yet. A screenshot from an outside installer can end up in front of the wrong people.
• Wasted bandwidth. Every install downloads the full build. A link that spreads widely uses up transfer that your plan or your own hosting pays for.
• Feedback on stale builds. Reports from an old build cost time to triage and often describe problems that are already fixed.
• Builds you no longer want installed. A build with a serious crash, wrong server settings or test data should stop spreading as soon as you know.

One thing that is separate: on iOS, an ad hoc build only installs on devices whose UDID is in the provisioning profile, and Apple limits how many devices you can register each membership year. That limit is set by Apple and the signing, not by the link. A leaked iOS ad hoc link will not install on an unregistered phone, but an Android APK link will install on any Android phone that allows it. The guide on iOS ad hoc device registration covers the Apple side.

The tools you have, and when each fits

Most build sharing tools offer some mix of the controls below. They solve different problems, so it helps to know which one you are reaching for.

Passwords

A password on the install page stops anyone who only has the URL. It is simple and works for every platform. The weakness is that a forwarded link usually travels with the password in the same message. A password is good for a small group you trust to keep both private, such as a client review.

Private tester lists

Only people you invited can open the build. This is the strongest control, because forwarding the link does nothing for someone who is not on the list. The cost is setup: each tester needs to be invited. It fits ongoing beta programs with a known group and client work where you need to know exactly who installed.

Expiry dates

A link that stops working after a set date limits how long a leak can matter. It fits anything with a natural end: a review week, a demo day, a test window before a release.

Install caps

A link that stops after a set number of installs puts an upper bound on spread. It fits events and demos, where you know roughly how many people should install, and public betas where you want a fixed number of early testers.

Pausing

Pausing stops new installs right away without losing the link. When you turn it back on, the same URL and QR code work again. It fits a build you need to hold while you check a problem, or a link you want closed between sessions.

Deleting

Deleting removes the build, so the link stops working. It is the right step when a build should never be installed again. Unlike pausing, it is not meant to be undone.

A store reviewer

Store reviewers usually get access through the store itself, such as TestFlight or a Google Play testing track, not through your own install link. If you do send a reviewer or an outside auditor a direct link, a password plus a short stop date is a sensible pairing.

A short playbook

Client review for one week

Set a password and a stop date at the end of the review week. Send the link and password to your main contact and say who the build is for. If the client asks to bring in more people, extend the date instead of sending a new build. For larger clients, a private project with named testers removes the guesswork about who installed.

Conference demo with 50 installs

Print a QR code for the build, set an install limit a little above 50 to leave room for retries on your own devices, and add a stop date for the last day of the event. When the event ends, the link closes by itself, even if the QR code stays on a printed card somewhere.

Pulling a build with a crash

Pause the link first. That stops new installs within a moment and keeps the build around while you look into it. Once you have a fixed build, share the new link and decide whether the old build should be deleted. Tell existing testers to update, because phones that already installed the broken build keep it.

Public beta

For a beta announced in public, use a stable link that always points to the newest build, so old links do not leave people on stale versions. Set an install limit if you want a fixed number of testers, and raise it in steps as you are ready for more feedback. Avoid a password here, since it will be posted next to the link anyway.

How install link controls work in AppForShare

AppForShare shares iOS and Android test builds through an install link and QR code. On Pro and Team, every build has link controls in Settings, under Link controls, on the build page.

Pause, stop date and install limit

• Pause. Testers who open the link see a short message instead of the install button until you turn it back on.
• Stop date. The link stops taking installs after the end of that day, in UTC.
• Install limit. The link stops after that many installs. On iPhone, an install is counted when the phone fetches the install manifest. On Android, it is counted at a fresh download, and a resumed download is not counted twice.

Apps already installed keep working. The controls only affect new installs from the link.

Setting controls needs Pro or Team. Removing them works on any plan, and controls you set keep applying after a downgrade, so a link you closed does not open again because a plan changed.

From the CLI and MCP

The CLI has a link command that takes a build ID or slug:

npx appforshare link 12345 --pause
npx appforshare link 12345 --resume
npx appforshare link 12345 --stop 2026-12-31
npx appforshare link 12345 --max-installs 50
npx appforshare link 12345 --stop off --max-installs off

Passing off removes a stop date or an install limit. This fits a CI job that uploads a build and sets a stop date in the same run; the CI docs cover upload tokens. The MCP server has a set_link_controls tool, so an AI assistant connected to your workspace can pause or limit a link, and it asks for confirmation before it changes anything. Setup is on the MCP page.

Other controls that already exist

• Passwords on install links, on every account from Free up.
• Private projects on Team, where only invited testers can open builds, with tester groups to give a named set of testers access in one step.
• Signed download links that expire, so the file URL behind an install cannot be reused later.
• Link life on Free: links of Free builds stay live for 7 days.
• Delete a build to take it down. Deleted builds can be restored for 7 days, then the file is removed for good.
• Beta and Live channels on Pro and Team, which give one stable link per channel that opens the newest build put into it.

Pro is $12 a month and Team $39 a month; see pricing for what else each plan includes.

Honest limits

• No control can take back an app that is already on a phone. Pausing, stop dates, limits and deleting only stop new installs.
• An install limit counts install attempts as described above, not people. One tester installing on two phones counts twice, and a person who starts an install and gives up may still be counted.
• Link controls do not check who the person is. If you need to know exactly who can install, use a private project with invited testers on Team.
• Stop dates work by day in UTC, not by hour in your own time zone.

Common questions

Can I make an app install link expire?

Yes, with a stop date on the link. In AppForShare, on Pro and Team, the link stops taking installs after the end of the chosen day in UTC. Free build links also end on their own after 7 days.

How do I limit how many people install a beta build?

Set an install limit on the link. Once that many installs are counted, the link stops offering the build. For a fixed list of named people, a private tester list is a better fit than a number.

What happens to testers who already installed the build when I pause the link?

Nothing. Their app keeps working. Pausing only shows new visitors a message instead of the install button.

Is a password enough to share a build securely?

For a small trusted group, usually yes. Passwords tend to be forwarded along with the link, so for wider sharing combine a password with a stop date or an install limit, or use a private project with invited testers.

Do link controls stop a leaked iOS ad hoc build from installing?

They stop new installs from the link. Separately, an ad hoc build only installs on devices registered in its provisioning profile, so an unregistered iPhone cannot install it whatever the link settings are.