One test build, several clients: own links, passwords, end dates
· 9 min read
An agency builds one app and shows it to more than one party. Sometimes it is a white label app with a demo build for three prospects. Sometimes it is one client with several stakeholders: the product owner, an outside QA firm, an investor who wants to see progress. The build is the same for all of them. What differs is who should have access, until when, and what happens when one of them leaves.
Until recently, the usual answers were one link with one password shared by everybody, or the same build uploaded several times. Both work, and both get awkward. This guide shows a cleaner setup: one build, a separate link per client, each with its own password, end date and install cap. It is written for agencies and freelancers, and the examples use AppForShare.
Why one shared link gets awkward
- You cannot revoke one client. When a prospect says no, or a stakeholder leaves the project, changing the password locks out everyone else too.
- Passwords travel. A password sent to one company ends up forwarded inside it, and sometimes outside. With one shared password you cannot tell where an install came from.
- One end date for all. Client A's review ends on Friday, Client B's at the end of the month. One link has one stop date.
- No per client numbers. "Did they even install it?" is a fair question before a follow up call, and a shared link cannot answer it.
Why uploading the same build twice is not better
Uploading the same .ipa or .apk once per client gives separate links, but the builds are now separate too. Feedback arrives on different builds, the "what changed" history of the next build compares with whichever copy came last, storage counts twice, and on CI the job uploads the same file several times. When you fix a bug, every copy needs its own replacement. It works for two clients and turns into bookkeeping at five.
One build, a link per client
The cleaner model: the build is uploaded once, and you add an extra share link for each client. Every link is its own short address, and it opens the same build's install page. On AppForShare, several links per build is on Pro (up to 3 extra links per build) and Team (up to 20). Each link has:
- A label, such as "Client A" or "Investor demo", seen only by you as the owner. The client never sees what you called them.
- Its own password, optional. On that link, only the link's password applies, so Client A's password does not open Client B's link, and the build's own password is not needed there.
- A stop date, after which that link takes no installs.
- An install cap, the most installs that link allows.
- Its own install count, so you know whether each client installed.
Installs on every link also count in the build's total, and the build's own controls still apply to every link: if you pause the build, set a stop date on it or give it an install limit, all its links follow. That gives you one switch for everybody and one per client.
| Setting | On the build | On an extra link |
|---|---|---|
| Password | Applies to the build's own link | Only the link's own password applies on that link |
| Stop date | Stops every link of the build | Stops that link only |
| Install cap | Counts every install of the build, on every link | Counts that link's installs only |
| Pause | Pauses every link of the build | Remove the link instead |
| Install count | Total of all links | That link's own count |
| Label | n/a | Seen by the owner only |
Setting it up
On the build page, the Links card adds a link with a label and the optional password, stop date and cap, and lists each link with its address, state and install count. From a terminal or CI, the CLI does the same:
# One link per client on build 5120
appforshare link add 5120 --label "Client A" --password "harbor-41" --stop 2026-12-31 --max-installs 25
appforshare link add 5120 --label "Client B" --password "maple-07" --stop 2026-11-30
appforshare link add 5120 --label "Investor demo" --max-installs 3The stop date is the end of that day in UTC. Send each client their link and password in separate messages, or at least not in the same chat thread as other clients.
When one client is done
Remove that client's link. Its page then says the link was turned off, the other links keep working, and the address is never given to another build.
Apps already installed keep working; a removed link stops new installs, not existing apps. If a client must stop using a build, for example after a contract ends or because the build is broken, the stronger step is to retire the build or have your test build check for it, as described in moving testers off an old build.
What to write to each client
The message matters as much as the link. Clients are not testers, and a short note saves a call:
- What the build is: "Version 2.4, build 118, for your review of the new booking flow."
- How to install: open the link on the phone, enter the password, tap Install. On Android, allow installs from the browser once. On iPhone, open the link in Safari.
- Until when: "This link works until November 30."
- How to report: the install page has a Send feedback card with screenshots, so the client does not need your ticket tracker.
Keep the password out of the same message as the link when you can, for example link by email and password by phone or chat. If a client forwards the email, the link alone does not open the build.
The iPhone part does not change
An ad hoc iOS build installs only on devices whose UDID is in its provisioning profile. Several links do not change that: every client's iPhone must be in the profile of the build they open. Collect UDIDs early with the free UDID finder or a device onboarding link (Pro and Team), register them, and build again before you send links. Apple allows 100 devices per device type per membership year, which goes quickly when several clients share one account. Our guide on Ad Hoc device registration covers the details.
Links belong to one build
Extra links are per build. When you upload the next build, it gets its own link, and you add client links to it again. For a client review that sees many builds in a row, that is one line per client in your CI job, using the command above with the new build.
If what a client needs is "always the newest build", a channel is the better tool: one stable link and QR code per channel that opens whichever build you put into it. Many agencies use both: a channel per long running client, and extra links on a specific build for demos, prospects and one time reviews.
Other tools for client work
| You need | Use |
|---|---|
| The same build, separate access per client, revoke one | Several links per build (Pro 3, Team 20 per build) |
| A link per audience that always opens the newest build | A channel per audience (Pro and Team) |
| Deliveries, comments and signed approval per client | Client projects (Pro 2 active, Team unlimited) |
| Install pages under your agency's brand | White label and custom domain (Team) |
| Only named people can install | Private projects with invited testers (Team) |
For a whole client relationship, client projects add a portal where the client signs in by email link, sees each delivery and version, comments, and signs off on a version, with a signed PDF recorded for both sides. That fits contracts where "approved" needs to be written down. More on running deliveries in sending app builds to clients, and on branding in white label build sharing.
How other tools handle it
Several links per build is not unique to us. AppsOnAir (by Logicwind) lets you create more than one share link per build, each with its own expiry and optional password, and edit or delete them one by one; as published in November 2026, its free plan caps a link at 30 days and paid plans at 90, and password protected links start on its Pro plan. On AppForShare, links on Pro and Team do not expire while you subscribe, so the stop date is something you choose per client rather than a plan limit.
Which plan you need
Extra links are part of Pro at $12 a month (up to 3 extra links per build) and Team at $39 a month (up to 20 per build, plus 5 seats, tester lists, private projects and white label pages). Free has one link per build with an optional password and a 7 day life, which is enough for one client at a time. If your plan later stops including extra links, the existing ones keep working; adding or changing one needs the plan again. Details are on pricing.
A checklist for a multi client build
- Collect every client's iPhone UDIDs and build the iOS app with all of them in the profile.
- Upload the build once, with release notes written for people outside your team.
- Add one link per client: a label you will recognise, a password, a stop date that matches the review, and a cap if the audience is small.
- Send each client their link and password separately.
- Check each link's install count before your follow up call.
- Remove a client's link the day their review ends.
- For the next build, add the links again, or move long running clients to a channel.
Common questions
Can I send one test build to several clients with different passwords?
Yes, on Pro (3 extra links per build) and Team (20). Each link has its own password, and only that password opens it.
Do clients see each other's links or labels?
No. Labels are visible to the owner only, and each client has a separate address.
Do installs on extra links count toward the build's install limit?
Yes. Every install counts on its link and in the build's total, and a limit on the build applies to all its links.
What does a client see after I remove their link?
A page saying the link was turned off. Other clients' links keep working.
