Is it safe to share test builds through a free install link service?
· 9 min read
When you share a test build through a free install link service, you hand three things to someone else: the app file, the email addresses of the people you send it to, and the first impression your client or tester gets when they open the link. Most of these services are run by honest small teams and work well. Still, "is it safe" is a fair question, especially for agencies sending unreleased work to clients under an NDA. This article is a checklist you can run against any service, including ours. InstallOnAir is used as one worked example because people search for it by name; the same questions apply to Diawi, Loadly, AppForShare and every other tool in this space.
A note on sources: the InstallOnAir details below are as published on their site in November 2026. Policies change, so read the current terms and privacy pages before you decide. AppForShare details come from our own published policies.
1. Who runs the service, and under which law
A link service holds unreleased builds for days or months. You should be able to name the company behind it, the country it operates from, and where its terms are published. This is not about trusting one country over another. It is about knowing who to contact and which rules apply if something goes wrong.
- Is there a company name in the terms, not only a brand?
- Is there a support address that a person answers?
- Are the terms, privacy policy and refund policy published and dated?
Worked example. As published on their site in November 2026, InstallOnAir's terms say the service is owned and operated by Logistic Infotech Pvt Ltd and governed by the laws of India. Logistic Infotech is an app and web development agency, and the InstallOnAir home page also offers consulting and custom development. Support is by email and a live chat widget. That is a clear answer to the question, which is what you want.
AppForShare. AppForShare is run by ZenTalk LLC, Houston, Texas. Support is [email protected] or the contact page. Our terms, privacy policy and refund policy are public.
One thing worth checking if you work with agencies: some link services are run by companies that also sell app development. That is common and not a problem in itself, but if your client is choosing a vendor, they may prefer a tool whose operator does not compete for the same work.
2. What your client sees on the install page
The install page is the part of the service your client actually looks at. For a client review, the page is part of your delivery. Look at it from their side.
- Are there third party ads or sponsor cards next to your app?
- Does the page share visitor data with advertising partners?
- Can you remove the service's own branding, and on which plan?
Worked example. As published on their site in November 2026, InstallOnAir runs Google AdSense and sells sponsor slots on the build install page, the upload success screen and the dashboard. Its privacy policy says it shares personal data with ad partners such as Google, in the sense used by the California CPRA. Ads are a normal way to keep a free tool free, and the policy is open about it. Whether that suits a client review is your call.
AppForShare. There are no third party ads on our install pages. Install pages of Free and guest builds show one small card about AppForShare itself ("Testing an app of your own?"); Pro and Team builds never show it. On Team you can use a white label install page (your logo and colours, the "Shared with AppForShare" line hidden) and a custom domain. Our website uses Google Analytics 4 with Consent Mode and no ad cookies, and visitors in the EEA, UK and Switzerland are asked first.
3. Who can open the link
An install link is a secret only until someone forwards it. Check what stands between a forwarded link and your build.
- Password per build. Can you set one, and on which plan?
- Private projects. Can you limit a build to invited testers only?
- Link expiry and controls. Does the link stop on its own, and can you stop it early?
- Search engines. Are install pages kept out of search results?
Worked example. As published on their site in November 2026, InstallOnAir describes its links as private and unlisted, not searchable or indexed. We found no password option on its home, features, pricing, FAQ or terms pages. Links expire after 3 days for guests and 7 days on a free account unless you pay to extend them.
AppForShare. Every account, Free included, can set a password per build. On Team, private projects open only for invited testers, the team and the client. Links expire after 3 days for guests and 7 days on Free; Pro and Team links stay live while subscribed, and on those plans you can pause a link, set a stop date or cap installs (see install link controls). For a longer list of what to check before you send a build, read control who installs your beta build.
4. Where the file lives and how it is served
- Is everything served over HTTPS?
- Are download links signed and short lived, or is the file at a fixed public address?
- Where is the file stored, and for how long after you delete it?
Our published facts, since they are the only ones we can vouch for: HTTPS everywhere; files stored on Google Cloud Storage in the US (us-east4) in a private bucket, served only through signed, short lived download links. A deleted build can be restored for 7 days, then its file is removed for good. An old link or QR code never points to someone else's build, because link addresses are never reused. If a service does not publish these points, ask its support before you upload anything under NDA.
5. Your account and the people on it
- Is two step sign in available?
- If several people upload, are there roles, so a contractor cannot delete builds?
- Can you connect CI with a token instead of sharing a password?
On AppForShare, every account can turn on two step sign in with an authenticator app, with 10 one time recovery codes. Team adds roles (Admin, Developer, Viewer). CI uploads on Pro and Team use an API token from Settings, never your password. As published on their site in November 2026, InstallOnAir lists no team accounts, roles or API, so this part of the checklist mostly does not apply there; it matters once more than one person handles builds.
6. Upload rules and abuse handling
A service that hosts any file for anyone will be used to spread repackaged apps. You want one that refuses that, because install link domains that host abuse can end up blocked or flagged, and your client's browser may then warn them away from your build.
Worked example. As published on their site in November 2026, InstallOnAir's terms forbid modified or repackaged apps and side loading tools, and allow builds to be refused automatically.
AppForShare. Builds whose app ID belongs to a large company that never ships test builds here (Google, Meta, Apple and similar) are refused, as are known malware app IDs. Guest uploads whose app name reads like a hack, mod or cheat are refused with a request to sign in if it is your own app. Abuse reports are reviewed by staff. To be clear about the limits: this is an app ID and name check, not a malware scan. No link service should be the only thing standing between your testers and a bad file; your own signing is.
7. Data kept about testers
- What is logged when a tester opens the page or installs?
- How long are IP addresses, device IDs and analytics kept?
- Which outside processors receive data?
Our answers: IP addresses are stored hashed. Install analytics are kept 13 months, UDID lookups 1 day, sessions and webhook logs 30 days. Processors are Google Cloud, Cloudflare, Stripe, SendGrid and, for AI features only, the Google Gemini API. Account emails go out with click and open tracking turned off. The full list is in our privacy policy.
The checklist in one table
| Question | InstallOnAir (as published, Nov 2026) | AppForShare |
|---|---|---|
| Company and law | Logistic Infotech Pvt Ltd, laws of India | ZenTalk LLC, Houston, Texas |
| Ads on install page | AdSense and sponsor slots | None from third parties; small AppForShare card on Free and guest |
| Password per build | Not mentioned on the site | Free and up |
| Invited testers only | Not mentioned on the site | Team |
| API, roles, team accounts | None listed | API on Pro and Team; roles on Team |
| Rules against repackaged apps | Yes, in the terms | Yes, app ID and guest name checks |
Where InstallOnAir is ahead on the free tier, fairly stated: bigger free uploads (200 MB against our 50 MB guest and 150 MB Free), free emailing of the link and install counts on the free dashboard. For the full side by side, see AppForShare vs InstallOnAir, and for general hygiene before any share, security checks before sharing a build.
Common questions
Is InstallOnAir safe to use?
It is a long running service with published terms and a named operator, and its terms forbid repackaged apps. Whether it fits your case depends on the points above: ads on the install page, data sharing with ad partners and no published password option are the ones agencies usually weigh.
Can a link service read my app's code?
It stores the file, so technically the operator has it. That is why the questions about who runs the service, where files are stored and how long they are kept matter. Never put secrets such as production API keys into a test build.
Do install link services check files for malware?
Do not assume so. AppForShare checks app IDs and, for guests, app names; it does not scan files for malware. Ask any service what it actually checks.
Is a password enough for a build under NDA?
A password stops casual forwarding. For stricter cases, use a private project limited to invited testers, and an iOS build signed only for the testers' devices.
