Free Diawi alternative for iOS and Android
500 MB builds, no install ceiling

Which alternative wins under which constraint

A comparison page that concludes with itself nine times is not a comparison. Here is the constraint under which each of these products, and not this one, is the right answer. Each line is a claim about what that vendor publishes, checked on 2026-09-03 against the source named in the table above.

Diawi

Diawi is the one to keep if what you have to hand is a zipped .app bundle rather than an .ipa, because it accepts that format and BetaDrop does not, and if a paid plan already covers your team then switching buys you nothing.

TestApp.io

TestApp.io wins when release history matters more than a single link, because its paid tiers set release expiration to Forever while its free tier keeps releases for a month.

AppsOnAir

AppsOnAir wins for a team that wants update prompts inside the app itself, because its paid tiers publish SDKs for Android, iOS, Flutter and React Native and this site ships no SDK at all.

InstallOnAir

InstallOnAir wins on the narrow case of paying one dollar to keep a single build alive a month longer, which is the cheapest per-build extension published by anyone on this list.

ShareIPA

ShareIPA wins if you want a password on a link that never asks you to sign in, since it publishes both and charges nothing for either.

Loadly

Loadly wins when a build has to stay installable indefinitely at no cost, because its page states links never expire and publishes a 2 GB ceiling to go with it, which no other free tier here matches on both counts at once. BuildShare publishes the same no-expiry claim, but no file cap beside it.

BuildShare

BuildShare wins for a small team that wants unlimited testers and password-protected links, which no cheaper plan on this list pairs: nine dollars a month.

Buildstash

Buildstash wins for game and desktop teams shipping multi-gigabyte artifacts, since its entry plan takes builds five times the largest cap anyone else here publishes.

What Diawi's free tier actually costs you

Three limits bite on the free plan, and the one that gets you is rarely the one you were watching. The upload cap is the visible one: you meet it before you have shared anything, and it is where most searches for a Diawi alternative start. The app expiry is the one you can plan around. The one that ends the evening is the installation count per app, because the link works for the first testers to reach it and then simply stops handing out the build, part way through the round of feedback you were waiting on. The figures for all three, and for every rung of the paid ladder that raises them, are in the matrix above, transcribed from Diawi's own published plan page rather than characterised.

The expiry is worth reading as a sequence rather than a deadline, because two separate things happen to the file. At expiry the app becomes unavailable: the link stops installing, but the build is still on Diawi's servers for a while and whoever uploaded it can re-enable it. Only after a second window does the file get deleted, and once that closes the link is unrecoverable, so the copy of the URL in your tester's chat history is worthless. How long each stage lasts depends on the plan; the current windows are published on diawi.com, so read theirs before promising a tester a date.

Where this Diawi alternative's limits sit

The numbers that matter, stated the same way so you can compare them without translating marketing copy. A build can be up to 500 MB, iOS .ipa or Android .apk. Android App Bundles are not accepted, so generate an APK from the bundle first. There is no cap on how many people install from a link, and no cap on how many builds you keep. What bounds that is storage, and a free account gets 1 GB in total across everything it has uploaded.

The account rule, stated plainly, because most pages in this category are vague about it and one of them is us in an older revision. Your first upload from a device needs no account: you drop the file, you get the link, nobody asks you for an email address. A second upload from that same device does ask you to sign in, and the free account is free. So the honest version of the claim is not “no signup ever”, it is “no signup to find out whether this works”. Signing in is also what buys you the longer expiry, the dashboard, revocation and the CLI token.

An upload made without signing in stays live for a fixed window, which is the case for a build you need in front of one person this afternoon. Sign in and the expiry becomes a property of the build that you pick at upload time, up to the free tier's ceiling, so the link for a client demo can outlive the one for a quick internal check, and either can be revoked straight away. Both figures are in the matrix above. It is a ceiling rather than an open field: a value past it is clamped down to it at upload, not honoured.

None of that changes iOS signing. An .ipa still needs an ad hoc or enterprise provisioning profile, and an ad hoc profile still has to name each tester's device before you export. That is Apple's rule rather than the host's, and it applies identically on Diawi and on every other row of the matrix. The UDID checker collects device identifiers, and the provisioning profile decoder shows which devices a profile already covers.

Where Diawi is still the right call

Three cases, and they are not rare. The first is format: Diawi accepts a zipped .app bundle alongside .ipa and .apk, which is occasionally exactly what you have to hand and which BetaDrop does not accept. The second is size at the top end: their Enterprise plan takes 1.2 GB uploads with paid add-ons past that, so an unusually large build is a genuine reason to stay. The third is inertia, and it is the strongest of the three: if your team is already on a paid Diawi plan with the install ceiling raised by add-ons, the tooling around it is settled and nothing on this page is worth the switching cost.

There is a fourth case that is about us rather than them. Every upload here is scanned and every Android build has its permission set screened, and a build whose Android permission set matches a covert-surveillance pattern is queued for a human to look at rather than refused. Malware and a hash already on the takedown list are refused outright. That is the right default for a public host, and it is an extra failure mode a paid Diawi account does not have.

The case for moving is narrower than a comparison page usually admits: you are on the free tier, the build is past its upload cap or needs more installs than that tier allows, and you do not want to pay to find out whether the build works. If that is you, the migration is not really a migration.

Moving a build across in two minutes

There is no import step, no project to create and no SDK to add, because the thing you are moving is a file you already build. The four steps below are the whole of it, and only the last one is worth doing more than once.

1. Export the signed .ipa or .apk exactly as you do for Diawi. Nothing about the Xcode or Gradle side changes. In Xcode 26 the export method for an ad hoc distribution build is written release-testing, not ad-hoc, which is a rename Apple made rather than anything to do with where you host the result (checked on 2026-09-03).
2. Drop the file on Upload IPA or Upload APK. Your first upload from a device needs no account; the next one takes a free sign-in.
3. Send the install link, or have testers scan the QR code. For iOS, BetaDrop generates the itms-services manifest that makes Safari install the app directly, which is the same mechanism Diawi uses, so nothing about the tester's experience changes.
4. Then stop doing steps 2 and 3 by hand. Install the CLI with npm install -g @betadrop/cli, create a token under Settings, Developer, API tokens, and the whole upload becomes one command that prints the install link:

betadrop publish ./build/MyApp.ipa

The same command is what the GitHub Action runs, so a build that lands on a branch can post its own install link without anyone opening a browser.

Frequently asked questions