Quickstart
What you need
- A built
.ipaor.apk, under 500 MB on the free tier. If you are on iOS, it must already be signed for distribution — hosting does not sign anything. - A tester with the device in their hands and a browser on it. Nothing to install first, no account, no invitation.
- Nothing else. No account, no credit card, no CLI — those come later on this page and only if you want them.
1. Upload the build
Go to the IPA uploader for iOS or the APK uploader for Android and drop the file onto the page. There is no sign-up wall in front of this step — the upload starts immediately, and the free tier takes a file up to 500 MB.
While it uploads, the app name, version, build number, bundle identifier and icon are read out of the archive itself, so the install page a tester sees is labelled with your app rather than a filename. Only .ipa and .apk are accepted; an .aab cannot be installed on a device and is not publishable — use the AAB inspector if you only need to look inside one.
2. Copy the install link
When processing finishes you get an install link and a QR code for it. A guest upload's link has the shape betadrop.app/app/<id>; the same upload made while signed in produces betadrop.app/install/<id>. Both render the same install page — the two shapes exist because guest builds and account builds are stored differently, not because they behave differently for the tester.
Send the link however you already talk to your testers. The QR code is the better choice when the person is in the room: they point a camera at your screen and skip the step where a URL is retyped with one character wrong. Guest links last 24 hours, which is the one number worth noting before you paste it into a document someone will read next week.
3. The tester opens it on the device
The install page detects the device and shows the right path. It has to be opened on the device being installed to — a link opened on a laptop shows the build details and the QR code, not an install button, because a desktop browser cannot install a mobile app.
- Android: the APK downloads and the system installer opens. The first time, Android asks permission for the browser to install unknown apps — that is a one-off toggle per browser, not per build. The full walkthrough covers the prompts, and "App not installed" covers the usual failures (signature mismatch with an already-installed copy, wrong ABI, downgraded version code).
- iOS: Safari shows the system install prompt and the app appears on the home screen. Two things outside any host's control can stop it. An ad-hoc build installs only on devices whose UDID was in the provisioning profile when the IPA was signed. An enterprise-signed build installs anywhere but needs its certificate trusted once — Settings → General → VPN & Device Management.
If the iOS prompt never appears at all, the problem is usually the itms-services handoff rather than the build — that has its own checklist, and the OTA explainer describes what is meant to happen.
4. Sign in to keep the build longer
Everything above works without an account. Signing in — still free — changes four specific things, and it is worth knowing which four rather than assuming an account is simply "better":
| Guest upload | Signed-in build |
|---|---|
| Fixed 24 hours lifetime | You choose the expiry per build — 3 days by default, up to 7 days on the free tier, longer on paid plans |
| Link lives wherever you pasted it | A dashboard listing every build, with download counts and device breakdown |
| Live until it expires | Revoke the link early, or put a password on it — available on every plan |
| Nothing to claim it to | Claim a guest upload you made earlier: the same file is bound to your account, so the link already in a Slack thread keeps working |
Claiming is worth spelling out because the alternative sounds like re-uploading and is not. The existing file is bound to your account and its download count comes with it; what does not migrate is the per-event history, so device and country rows start from the moment you claim.
5. Automate it
The manual flow is the right way to try the product and the wrong way to run a release cycle. The same upload from a terminal is two lines:
npm install -g @betadrop/cli
betadrop login # browser sign-in, or --token bd_live_…
betadrop publish ./app-release.apk # prints the install link and a QR codeFrom there: the CLI reference has every flag, the GitHub Action reference turns it into a workflow step, and the MCP server lets an AI assistant do it on request. For complete pipelines rather than reference, the integrations pages carry working workflows for Gradle, Xcode and fastlane.
Frequently asked questions
Does my tester need a BetaDrop account, or an invitation?
Neither. They open the link in whatever browser is on their phone and install from the page. There is no tester list to manage, no email invitation to accept, and no seat to pay for — which is the whole difference from TestFlight and from Play Console's closed testing. The consequence to be aware of is the other side of the same coin: anyone holding the link can install the build, so treat an install link like a password. On a signed-in build you can put a password on the link from the dashboard, on any plan, and shorten the expiry — both are worth doing for anything you would not want forwarded.
The iOS install says the app cannot be installed. What went wrong?
Almost always signing rather than distribution. An ad-hoc build only installs on devices whose UDID was in the provisioning profile at the time the IPA was built, so a device added after the build was signed will fail no matter how it is delivered. An enterprise-signed build installs anywhere but needs its developer certificate trusted once under Settings → General → VPN & Device Management. Neither is something a distribution service can change: BetaDrop hosts and delivers the exact file you uploaded, and Apple's rules about which devices may run it apply unchanged.
How long does the install link stay alive?
An upload made without signing in lasts 24 hours. A build uploaded to a free account starts at 3 days and can be extended up to 7 days; paid plans extend it much further. Expiry is per build and you set it, so a client demo can outlive a quick internal check. When a build expires the file is deleted from storage rather than hidden, so plan on re-uploading for the next round instead of treating a link as an archive.
I uploaded as a guest and then signed up. Do I lose that build?
No — sign in and claim it. Claiming binds the existing file to your account, so the link that is already in a Slack thread keeps working and nothing is re-uploaded. The download count comes across with it. What does not come across is the per-event history: device, country and timeline rows start from the moment you claim, because guest installs and account analytics are recorded separately.
How big can a build be?
Up to 500 MB per file on the free tier, which covers most debug and release builds of a normal app. The ceiling is enforced by the server, so the CLI, the GitHub Action and the MCP server are not a way around what the browser uploader allows — they all hit the same limit. The only tier that raises it is Studio, at 1 GB; otherwise the fix is a smaller artifact, and stripping debug symbols or splitting by ABI usually recovers the most.
