How to send app builds to clients without confusion
· 7 min read
If you build apps for clients, the build itself is only half the delivery. The other half is getting it onto the client's phone without a support call, getting feedback you can act on, and ending up with a clear record of which version they approved. Agencies and freelancers lose real time on the second half: a client tests an old build, sends feedback in four different places, and three weeks later nobody can say which version was signed off.
This guide covers how to share app builds with a client professionally, from the first install to sign-off, and where AppForShare fits.
Why client builds go wrong
The same problems show up on almost every outsourced app project:
- "Which build is this?" The client has five links in their email and opens the first one.
- "It won't install." The iPhone is not in the Ad Hoc profile, or Android blocks the APK because the browser is not allowed to install apps.
- Scattered feedback. Some comments are in email, some in a chat app, some in a call nobody wrote down.
- Unclear approval. The client said "looks good" on a call. Later they remember approving something else.
Each of these has a simple fix, and most of the fixes are habits, not tools.
Before the first build: set up the client once
Collect device details early
For iOS, ask for every UDID the client will test on before you make the first build. A link install only works for builds signed Ad Hoc, Development or Enterprise, and an Ad Hoc build installs only on devices in its provisioning profile. Apple allows 100 devices per product family per membership year on an account, and removing a device mid year does not free the slot, so do not register devices casually.
Send the client to the free UDID finder. It works in Safari, needs no account, and lets them email the UDID straight to you. If they have trouble, this guide to finding the UDID walks through it.
For Android, tell the client in advance that their phone will ask to allow installs from the browser the first time. A short heads up avoids the "your app is a virus" email. Here is how that setting works.
Agree on how builds will be named
Clients do not care about build numbers, but they will quote them if you make it easy. Increase the build number on every delivery, show version and build on a screen in the app, and put the same number in the subject line of every delivery. "Version 1.4, build 212" is something a client can say on a call.
Write down what sign-off means
Before work starts, agree in writing what the client is approving at each milestone: a design build, a feature complete build, a release candidate. The kickoff document does not need to be long. It needs to say what will be delivered, how the client will review it, and what counts as approval.
Delivering each build
A good delivery message answers four questions without the client having to ask:
- Which build is this (version and build number)?
- How do I install it (one link or QR code, nothing else)?
- What changed and what should I look at?
- What do you need from me, and by when?
Send one link per build. Do not attach files to email, and do not reuse an old link for a new build. If a build replaces an earlier one, say so, and remove the old one so the client cannot open it by mistake.
Before sending, check the build is the one you meant. A quick look in the IPA inspector or APK analyzer (both run in the browser, the file is not uploaded) confirms the version, the signing type, and for iOS whether the client's UDIDs are in the profile.
Collecting feedback in one place
Pick one channel for feedback per version and stick to it. Feedback tied to a specific version is far more useful than a running email thread, because you know exactly which build the comment is about. When a client sends feedback by another route, copy it into the agreed place and reply there.
Turn feedback into tasks the client can see. Clients relax when they can see that their request is in progress, and it cuts down on "any update?" messages.
Getting sign-off on a version
A sign-off should name the exact thing approved. "The app" is not enough. A useful sign-off record includes the project, the delivery, the version and build number, the bundle id or package name, a hash of the exact file, the release notes, and who approved it and when. With the file hash, there is no argument later about which binary was approved.
This is a project record, not legal advice. If your contract needs a specific form of acceptance, talk to whoever writes your contracts.
How AppForShare handles client projects
AppForShare has client projects built for this flow. They are on Pro (2 active client projects) and Team (unlimited). A project marked Complete frees its slot. Here is what they include.
A client portal with no password
Each client project has one client (email, plus optional name and company). The client signs in to the portal with an emailed link, so there is no account or password to forget. In the portal the client sees:
- Tasks you mark as "Client and team", on a board (To do, In progress, In review, Done), with comments you mark as visible to the client.
- Every delivery and version: an AppForShare build with its install link, a file up to 25 MB with its SHA-256, or an https link.
- A feedback thread per version, where the client can post until the project is Complete.
The client can install the project's builds even when the project is private to invited testers. They get emails when they are invited, when a new version is ready, when your team replies, and when a client task is done. Your team gets an email when the client posts feedback.
Agreements and sign-offs
You can add one kickoff agreement per project and one agreement per delivery. You write the text, and it stays editable until it is signed. For each delivery version you can ask for a sign-off. The sign-off text is generated from the version: project, delivery, version number, platform and build version, bundle id or package, the SHA-256 of the .ipa or .apk, and the release notes.
The client reads the text in the portal, enters their full name, draws or types a signature and ticks a consent line. AppForShare records who signed what and when: the exact text and its SHA-256, name, email proven by the sign in link, signature image, IP address, browser and time. A signed PDF is emailed to the client and to you. Signed documents cannot be edited or deleted, and version notes lock once signed off. Unsigned requests get a reminder email at 3 days and again at 7 days.
Signed PDFs carry a document seal, and anyone can check a PDF on the public AppForShare verify page, where the file is hashed in the browser and not uploaded; changes to the text are detectable by its SHA-256. You can also download an evidence report for the project. AppForShare does not write your agreement and this is not legal advice.
Ending a project cleanly
When the work is done, mark the project Complete. Both sides become read only and the record is frozen. A project cannot be completed while something is still waiting for a signature. If a client contact leaves, you can sign them out everywhere or remove them; the board and deliveries stay with your team.
A simple delivery checklist
| Step | Done when |
|---|---|
| Devices | Client UDIDs are in the profile, Android install setting explained |
| Build | Build number increased and visible in the app |
| Check | Version, signing and devices confirmed before sending |
| Delivery | One link, notes on what changed, what you need back |
| Feedback | Collected per version in one place |
| Sign-off | Approval names the version, build and file hash |
| Cleanup | Old builds removed, project marked complete |
Try it on your next client delivery
Client projects, the portal and sign-offs are on Pro ($12 a month, 2 active client projects) and Team ($39 a month, unlimited projects, roles, private tester projects and a white label install page). See how it works for studios on the agencies page, compare plans on pricing, or create an account and set up your first client project. If you also ship branded versions of one app for several clients, read sharing white label app builds.
