Test build distribution best practices for 2026
· 8 min read
Most test build problems are not technical. The tester installed last week's version, the link expired before the client opened it, or nobody knows which build has the payment fix. A little discipline removes most of that noise.
This is a practical list of app distribution best practices for testing in 2026, for iOS and Android, whether you have two testers or forty. For each one we also say plainly what AppForShare does for it and on which plan, so you can see where a tool helps and where it is just a habit.
1. One build, one link, one set of notes
Never reuse a link for a new build, and never send a file around by chat. Each build a tester sees should have its own install link and a short note that says what it is for. When someone reports a bug, the link they used tells you exactly which binary they had.
Good release notes for testers are short and specific:
- What changed since the last build, in two to five lines.
- What to test, and what is known to be broken so testers do not report it again.
- Any setup: a test account, a feature flag, a server environment.
On AppForShare: every upload is a new build with its own link and QR code, on every plan. Slugs are never reused, so an old link or QR code never points to someone else's build. Release notes on the install page are part of Pro and Team. Free accounts get 5 AI actions a month, and one action can draft tester notes from the build, which you then review; putting that draft on the install page is Pro and up.
2. Make the version and build number tell the truth
Testers will read whatever is on the screen, so make it meaningful. Keep the user facing version (CFBundleShortVersionString on iOS, versionName on Android) for the release you are working toward, and increase the build number (CFBundleVersion, versionCode) on every build you hand out. A CI run number or a timestamp works well as a build number because it only goes up.
Two rules save a lot of time:
- Never hand out two different binaries with the same version and build number.
- Show the version and build somewhere in the app, for example a settings or about screen, so a tester can quote it in a bug report.
On Android this is more than tidiness: a device will not install an APK with a lower versionCode over a newer one without uninstalling first, which also wipes the app's data.
3. Say what changed between builds
Beyond your own notes, it helps to see what changed in the binary itself. A new permission, a higher minimum OS or a jump in size are things a tester or reviewer should hear about before they meet them on a device.
On AppForShare: the "what changed" view is free on accounts. It compares the build with the previous build of the same app and platform: version, permissions, minimum OS, minimum and target API, SDK, frameworks, size, provisioned devices, and store readiness issues fixed or new. It compares build metadata, not your source code.
4. Decide who can open the link
Test builds often contain unfinished features, test servers and debug menus. Treat the link as something that should only reach the people who need it.
| Situation | Reasonable control |
|---|---|
| Internal build shared in a team channel | Password on the link, shared separately |
| Build for a client or an outside tester | Password, or a private project with named testers |
| Build with unreleased features or partner data | Private project, invited testers only, plus a check of who installed |
On AppForShare: password protected links are on the Free plan and up (guest uploads without an account get the QR code only). Team adds private projects that only invited testers can open, and a "who installed" list. Download links are signed and short lived, and files sit in a private bucket. For a fuller checklist see security checks before sharing a build.
5. Know when your links stop working
A link that dies quietly is worse than no link. Testers come back to an old message, tap, and get an error, and the bug they wanted to retest stays open. Pick a lifetime on purpose and tell testers what it is.
On AppForShare: link life depends on the plan. Guest links last 3 days, Free links 7 days, and Pro and Team links stay live while the plan is active. Free owners get an email when a link has under 2 days left. If a Free link has expired, its files are kept for 7 more days, and upgrading in that window brings the same link and QR code back.
6. Plan Ad Hoc devices before you need them
On iOS, a link install only works for builds signed Ad Hoc, Development or Enterprise. Ad Hoc is what most teams use for outside testers, and it installs only on devices whose UDID is in the provisioning profile. App Store builds and TestFlight builds cannot be installed from a link at all.
Apple lets an account register up to 100 devices per product family (iPhone, iPad, Mac and so on) per membership year. Removing a device during the year does not give the slot back; you can only clear the list at the start of the new membership year. So:
- Collect UDIDs before the build is made, not after a tester reports "Unable to install".
- Register only devices that will really test, and keep a short list of who owns each one.
- After adding devices, regenerate the profile and build again. An existing build does not learn about new devices.
On AppForShare: the free UDID finder needs no account and lets a tester email their UDID to you. The IPA inspector runs in your browser and shows the profile type, expiry and the full list of provisioned UDIDs, so you can check a build before sending it. AppForShare does not re-sign builds. More on the process in iOS Ad Hoc device registration.
7. Check the build before testers do
Some problems only show up when you try to ship: an old SDK, a missing privacy manifest, a debuggable Android build, an expiring profile. Finding them in a test build is cheaper than finding them in review.
On AppForShare: every build uploaded to an account gets a store readiness check (iOS SDK version, privacy manifests and required reason APIs, Play target API level, 16 KB page size for 64-bit native libraries, debug signing, profile expiry). Each issue comes with how to fix it. It is guidance, not a promise of store approval.
8. Tell testers a new build is ready
If testers have to ask whether there is a new build, they will test the old one. Post every build where the team already talks, with the link and the notes.
On AppForShare: Pro adds webhooks for Slack, Discord or your own signed endpoint (see the webhooks docs and Slack and Discord build notifications). Team emails invited testers when a new build lands. Anyone with an account can also turn on push notifications in the AppForShare web app for new builds and other events.
9. Upload from CI, not from a laptop
Manual uploads are where wrong files get shared: a debug build, last week's archive, the wrong branch. Let the pipeline upload and post the link.
- name: Share build
run: npx --yes appforshare@1 upload build/MyApp.ipa --notes "${{ github.event.head_commit.message }}"
env:
APPFORSHARE_TOKEN: ${{ secrets.APPFORSHARE_TOKEN }}On AppForShare: CI upload tokens are part of Pro and Team. The same npx line works in GitLab CI, Bitrise, Codemagic or a Fastlane sh step. Details are in the CI docs.
10. Look at installs, not just uploads
Uploading a build is not the same as it being tested. Before you ask for feedback, check that people actually installed it and on which devices. If nobody on an older OS version installed, you have not tested that OS version.
On AppForShare: install analytics on Pro and Team show devices, OS versions, models, countries and a daily series. Team adds who installed. Owners on any plan get an email and push when a build reaches 5, 25 and 100 installs.
11. Retire old builds
Old builds in circulation cause duplicate bug reports and confused clients. When a build is replaced, remove it, or at least make the newest build obvious in your notes. There is no way to roll back an app that is already installed; a tester who needs an older version installs it from that build's link, if it is still live.
On AppForShare: each project keeps its builds, so the newest one is easy to find. A deleted build can be restored for 7 days, then the file is removed for good.
A quick map of practices to plans
| Practice | Free | Pro | Team |
|---|---|---|---|
| Own link and QR code per build | Yes | Yes | Yes |
| Password protected links | Yes | Yes | Yes |
| "What changed" and readiness check | Yes | Yes | Yes |
| Release notes on the install page | No | Yes | Yes |
| Link life | 7 days | While subscribed | While subscribed |
| CI uploads and webhooks | No | Yes | Yes |
| Install analytics | No | Yes | Yes |
| Private projects, tester emails, who installed | No | No | Yes |
Put it into practice
None of this needs a big process. One link per build, honest build numbers, notes that say what changed, a decision about who can open the link, and a CI step that does the upload cover most of it. If you want those pieces in one place, create a free account and upload your next build. Pro is $12 a month and Team $39 a month when you need release notes, CI uploads or private tester projects; every limit is on the pricing page. For the basics of link installs, see over the air app installation.
