TestFlight Alternatives for iOS
Instant install, no review wait

TestFlight, Firebase App Distribution, Diawi and BetaDrop: the limits side by side

Every competitor figure below was read off that vendor's own documentation and re-checked in August 2026. None of it is quoted from memory, and where a vendor does not publish a number the cell says so instead of guessing. The sources are listed under the table, so any cell here takes about a minute to verify yourself.

Checked August 2026 against developer.apple.com/testflight, Apple's App Store Connect Help pages for TestFlight and maximum build file sizes, Apple's device registration overview, Firebase App Distribution's documented quotas, its tester setup guide, Firebase pricing and Diawi's plan comparison. Vendors change these; if you are making a decision that depends on one, open the link. Longer write-ups of two of the columns live on our Firebase App Distribution comparison and Diawi comparison.

What TestFlight costs you

Not money. TestFlight is included with the Apple Developer Program, and you need that membership to sign an ad hoc build anyway, so the $99 a year is a wash. What it costs is time and reach.

Beta App Review before external testers see build one

Builds added to an external group are submitted to Apple automatically, and the first one has to be approved before anybody outside your team can install it. Subsequent builds usually pass without a fresh review, but a significant change can pull you back into the queue at the worst moment.

Internal testing caps at 100 people

Internal testers must be users on your App Store Connect team, and there are at most 100 of them. Everyone else (clients, contractors, a designer at the agency) is an external tester, which is the path that goes through review.

Every tester needs the TestFlight app and an Apple Account

Two installs and a sign-in stand between you and a build on someone's phone. For a colleague that is friction. For a client who wants to see the thing today, it is often the point at which the demo does not happen.

Builds stop working after 90 days

A TestFlight build expires 90 days after upload whatever state your testing is in, so a long-running pilot needs a rebuild and a re-upload purely to keep an unchanged app installable.

An over-the-air link removes the first three outright: the build is installable the moment the upload finishes, there is no internal-versus-external split to fall the wrong side of, and the tester needs nothing but a browser. The fourth it changes rather than removes: the expiry stops being a fixed platform rule and becomes a number you pick per build, but the ceiling you can pick up to on a free account is shorter than TestFlight's 90 days, not longer. What none of it removes is Apple's signing rules: the .ipa still has to carry an ad hoc or enterprise profile, and for ad hoc that means each tester's UDID was in the profile when you exported. The UDID checker collects those, and the provisioning profile decoder shows which devices a profile already covers.

The 90-day build expiry is not the Beta App Review wait

These two get run together constantly, including in earlier versions of this page. They are different mechanisms. Beta App Review is a gate; the 90 days is a clock. They apply at different moments, to different testers, and only one of them can be avoided by testing internally.

Beta App Review is a gate, and it only stands in front of external testers

Apple's documentation is specific: when you add the first build of an app to a group, that build is sent to App Review, and a review is required only for the first build. Subsequent builds may not require a full review (checked August 2026). Two things follow. Internal testing, the 100 App Store Connect users on your own team, has no review at all, so “TestFlight makes you wait for review” is only true of testers outside your team. And “may not require” is not a promise: a build that adds a permission prompt, changes what the app does, or rewrites the beta description can be pulled back into the queue on a Friday afternoon. Apple publishes no turnaround target for beta review, so the honest planning assumption is “usually quick, occasionally not, never something you can put in a client email as a time.”

The 90-day expiry is a clock, and it starts at upload

Apple's wording is that your build becomes unavailable for testers after 90 days (checked August 2026). The countdown begins when the build is uploaded. It does not care whether the build went through review, whether anybody installed it, or whether your test cycle has finished. It applies to internal testing as well, which is the part people are most often surprised by: skipping the review gate does not stop the clock. When a build expires, the fix is not a setting. It is a new build, a new upload, and for external groups the possibility of another trip through review if the change is large enough.

They compound, and that is where quarter-long pilots come apart

Because the clock starts at upload and review happens inside it, the days a build spends in the queue are days off the 90. A build that clears review on day four has 86 days of testing left, not 90. For a two-week sprint that is invisible. For a pilot that has to survive a full quarter, it is the difference between one upload and two. The second one lands in the middle of the pilot, when the tester group is already busy and nobody wants to think about distribution.

The over-the-air route has two clocks of its own, and neither is Apple's

The first is the link expiry, which is a number you choose per build: 24 hours for an upload made without signing in, up to 7 days on a free account, and further on a paid one. The second is easy to forget and breaks installs in a way that looks like a hosting problem: the provisioning profile the build was signed with has its own expiration date, and once it passes, that .ipa stops installing no matter how long its link stays live. A long link paired with a short-lived profile is the classic failure here. The provisioning profile decoder reads the expiry date and the provisioned device list straight out of a .mobileprovision file, which is the thirty-second check worth doing before you promise a client that a link will still work at the end of the pilot.

When TestFlight is the better choice

There are eight situations where we would tell you to use TestFlight, and knowing them up front saves you discovering the ceiling halfway through a test cycle. The first four are about reach and the tooling Apple gives you; the last four are the ones people hit unexpectedly, usually a week into a project when a limit turns out to have been set by hardware, geography or the calendar rather than by software.

You need more testers than ad hoc provisioning allows

Ad hoc distribution registers each device: up to 100 per product family per membership year, with every UDID in the profile before you export. TestFlight registers nothing and scales to 10,000 external testers. Past a couple of dozen devices this is the whole argument.

You want a public link anyone can join

A TestFlight public link lets a stranger enrol themselves without you touching a provisioning profile. Nothing built on ad hoc signing can do that, because the build has to be signed for the device before it exists.

You want Apple's crash reports and feedback screenshots

Testers can send a screenshot and a note straight from the TestFlight app, and crashes come back symbolicated in Xcode's organiser. An OTA install link gives you the install and nothing after it.

You are rehearsing App Review

A TestFlight build travels the same submission pipeline your release will, so it surfaces entitlement, privacy-manifest and metadata problems while they are still cheap to fix.

The build is not for an iPhone or an iPad

Apple's own documentation lists TestFlight across iOS, macOS, tvOS, watchOS and visionOS (checked August 2026). The over-the-air itms-services route puts an .ipa on iOS and iPadOS and stops there, so a Mac, Apple TV, Watch or Vision Pro build that has to reach someone else's hardware goes through TestFlight or through a channel that platform supports natively.

You cannot get your testers' device UDIDs

This is the ad hoc route's real ceiling, and it is a people problem rather than a technical one. A client's IT department that will not run a UDID lookup, a tester three time zones away, a device you will never hold. Each of those blocks an ad hoc build before signing even starts. TestFlight registers no devices, so the tester's hardware is none of your business.

Testers need to pull new builds themselves

TestFlight testers install the app once and get updates through it, and Apple lets you keep up to 100 builds shareable at a time (checked August 2026). An install link is a fresh URL per build, so somebody has to send it. That is a two-second job if your CI does it, since the BetaDrop CLI prints the install URL on its own with betadrop publish --ci, and an annoyance if a human is pasting it by hand every afternoon.

A build has to stay installable for a full quarter, untouched

The honest one. TestFlight's 90 days is longer than anything a free BetaDrop account can set: free tops out at 7 days, and an upload made without signing in lasts 24 hours. If a pilot has to run for three months and nobody will be around to re-upload, TestFlight's fixed window is the longer of the two. Paid plans move the ceiling well past 90 days, but that is a different sentence and it costs money.

What running both actually looks like

Most teams that end up happy are not choosing one tool. They are giving each one the job it is good at. TestFlight carries the wide external beta: the build that has been through review, the public link on the pilot page, the group of several hundred people you will never meet, the crash reports. The over-the-air link carries the build that exists this afternoon: the branch a designer needs to poke at before standup, the fix a client asked about an hour ago, the release-candidate a QA contractor has to smoke-test before you spend a review cycle on it. The two do not interfere: the same archive can produce an App Store export for TestFlight and an ad hoc export for the link, and nothing about hosting an .ipa yourself changes what App Store Connect will accept later.

The practical rule we would give a team splitting this way is to make the choice on the tester rather than on the build. Anyone whose device UDID you already hold (your own team, the agency, the two people at the client who do the actual testing) gets the link, because for them it is instant and there is nothing to install. Anyone whose device you do not control goes through TestFlight, because collecting a UDID from a stranger is a worse experience than asking them to install one app. When the split is drawn there, neither tool ever becomes the bottleneck, and neither one ends up being blamed for the other's limit.

If the public link is the part you are weighing, our note on what a TestFlight public link is and what it costs you goes through it, and the guide to distributing iOS apps without TestFlight covers the export and signing steps end to end.

Frequently asked questions