A free InstallOnAir alternative for iOS and Android

BetaDrop vs InstallOnAir

InstallOnAir figures are transcribed from their own pages, checked August 2026: the two-day guest window, the eight-day signed-in window and the "generous upload limits" non-answer on file size come from their FAQ; the accepted file types from their features page; the extension prices from the Extend Expiry Date dialog on their homepage. Where they publish no number, the row says so rather than guessing. Both products change. Check theirs before deciding on numbers alone.

What InstallOnAir's free tier actually costs you

Nothing, in money. The price is a countdown rather than an invoice. Their FAQ states both windows plainly: a build uploaded without signing in is reachable for up to two days, and registering raises that to eight (checked August 2026). Signing up is the only free way to move that number; past it, more time is something you buy. The Extend Expiry Date dialog on their homepage prices it per build: $1 for a month, $4.99 for six months, $9.99 for a year. For one build that is genuinely cheap. For a build a week it is a small decision you make every week, and the builds you forget to extend go quiet on their own.

The second cost is a number nobody publishes. Asked directly whether there is a file size limit, their FAQ answers with a description ("generous upload limits") and no figure. That is fine until you are the person pushing a large game build up a hotel connection with no way to know in advance whether it will be accepted, and it is the reason the size row in the table above reads Not published rather than carrying a number we made up. BetaDrop states 500 MB per file and means it, so the answer is available before the upload rather than after it.

The third is worth knowing about before you plan a test round around a date: their own pages disagree about how long a registered build lasts. The features page says registering keeps a build active for 60 days; the FAQ says a signed-in build is saved up to 8. Both were live in August 2026. We have no way to tell you which one the server enforces, so treat the shorter figure as the one your tester is likely to meet, and read the expiry date the upload screen prints afterwards. That field, not a marketing line, is what governs the link.

Set against that, the BetaDrop shape is one you can plan with: a signed-in free account picks the expiry per build at upload time, up to a ceiling of 7 days, and a value past the ceiling is clamped rather than silently honoured. A client demo link can outlive an internal smoke-test link, both can be revoked immediately, and neither needs a payment to survive the fortnight. What that costs on our side is storage: a free account gets a fixed allowance across everything it has uploaded, which is the dial you eventually meet instead of a clock.

Where InstallOnAir is still the right call

• An anonymous link that has to survive the weekend. This row goes to them and it is not close: an InstallOnAir upload made without an account lasts up to two days, while a BetaDrop guest link lasts 24 hours. If you refuse to sign in anywhere and the link has to still work on Monday, theirs is the one that does. Signing in flips the comparison entirely, but that is the point: you have to sign in.
• You have a zipped .app, not an .ipa. Their drag-and-drop accepts "ipa, zipped .app or apk". BetaDrop takes .ipa and .apk only, so a bare .app bundle has to be packaged first, which is real work you would rather not do at 6pm.
• One build, kept alive, no subscription. A dollar to hold a single link open for a month is hard to argue with when you have exactly one build and no intention of paying monthly for anything. Buy the month, move on.
• A build larger than our published cap. Because they publish no ceiling, we cannot tell you theirs is higher. But if your artifact is over 500 MB you already know ours will refuse it, and trying theirs costs one upload.
• Nothing is broken. If your links live there, your testers know the flow, and eight days comfortably covers your review cycle, there is no case here worth your afternoon.

The case for moving is narrower than a comparison page usually admits: you want a link that outlives the week without buying an extension for each build, you want the size ceiling written down before you start the upload, and you want the whole thing scriptable from CI. If two of those three describe your afternoon, the switch is one upload long.

Switching to this InstallOnAir alternative: moving a build across

There is no migration in any real sense. Both services do the same job the same way: you hand over a signed artifact and they hand back an over-the-air link. Nothing on the Xcode or Gradle side changes, no SDK goes into the app, and your testers learn nothing new. What you are actually moving is where the link lives.

1. Take the same .ipa or .apk you would have dropped on InstallOnAir. Do not re-export it; the artifact is identical.
2. Drop it on Upload IPA or Upload APK. Your first upload needs no account. Signing in is what buys the longer expiry and the per-build choice, so if the reason you are here is the clock, sign in.
3. BetaDrop parses the build before it hands back a link, so the bundle ID, version and build number are on screen. That is the moment you notice you uploaded yesterday's artifact, rather than the moment a tester tells you. For iOS it generates the itms-services manifest that makes Safari install the app directly, exactly as InstallOnAir does.
4. Send the link, or have testers scan the QR. They install from the phone's browser. No account, no invitation, no review wait.
5. If the upload is part of a build pipeline, stop dragging files: the CLI publishes and prints the install URL in one command, which is the piece InstallOnAir has no documented equivalent for.

npm install -g @betadrop/cli
betadrop login --token bd_live_xxxxxxxx
betadrop publish ./MyApp.ipa --name "Sprint 14" --notes "Fixes the checkout crash"

None of this changes iOS signing, on either host. An ad-hoc .ipa installs only on devices whose UDID is in the provisioning profile, and an enterprise build still needs the trust step on the device. That is Apple's rule rather than the host's. The UDID checker collects device identifiers, the provisioning profile decoder shows which devices a profile already covers, and the IPA inspector reads the signing details straight out of the file before you share it.

Frequently asked questions