Beta Distribution Report 2026

The four findings

1. 79.6% of uploads are made by someone who never signed in. 17,535 of 22,031 uploads came from people without an account, 3.9 for every one made from an account, spread over 9,989 distinct devices. Any measurement of this category that starts from a signed-in user table is describing the smaller fifth of it.
2. 31.6% of uploads are never delivered to anyone. 6,971 of 22,031 uploads had no recorded delivery at all. The rate barely moves between the two halves — 32.0% of account uploads and 31.6% of guest uploads — so it is a property of the act of uploading, not of how committed the uploader was.
3. The top 1% of uploads carry 42.4% of all deliveries. 221 uploads, belonging to 156 distinct owners, account for 42.4% of the 37,271 deliveries recorded. The median upload is delivered 1 time and the 90th percentile 2.
4. When an upload is delivered at all, 94.1% of first deliveries happen within an hour. And that is not an artifact of a short window: restricted to the 11,272 delivered uploads among the 16,614 made at least 7 days before the window closed, the first-hour share is 93.9%, which is the same answer. Both versions are charted below.

Four out of five uploads have no account behind them

17,535 uploads, 79.6% of the population, were made without signing in; 4,496 came from 1,853 accounts. That is 3.9 anonymous uploads for every account upload, and it is the single most consequential fact on this page: a study of this category built from account records would miss most of the behaviour it set out to describe.

The two halves are not the same population wearing different hats. 99.1% of guest uploads had already been retired by expiry when the data was taken, against 60.7% of account uploads, because an anonymous upload gets a short fixed lifetime and an account holder can choose a longer one. That difference is exactly why the previous edition, which kept only what was still live, saw almost none of this.

998 guest uploads in the window were later claimed into an account. Of those, 529 have their account row inside this window too, and those are counted ONCE, as the account upload they became, which is why the guest figure here is 17,535 and not the 18,064 guest rows the window contains. The Methodology below states that rule in full.

Nearly a third of uploads are never delivered to anyone

6,971 uploads, 31.6% of the population, had no recorded delivery at all. That is an upper bound rather than a settled figure: an upload made near the end of the window had hours in which to be installed, not a month. Another 11,149 were delivered exactly once, which is the shape of a developer checking their own link before sending it.

The interesting part is what does NOT vary. 32.0% of account uploads and 31.6% of guest uploads were never delivered — 1,437 and 5,534 respectively. Signing up, choosing an expiry, and coming back to a dashboard make almost no difference to whether the artifact ever reaches a device.

A delivery here is a row in the install-event log, counted against the build and, for a build claimed from a guest link, against that guest link as well. The per-upload download counter is not used: a claim starts a fresh counter on a new row while the deliveries stay on the guest row, so counting the column reports uploads as untouched that had already been handed to a tester.

The useful reading is not that testers are lazy. It is that a large share of build sharing is not distribution at all: it is a developer producing an artifact, parking it somewhere addressable, and moving on. Any tool in this category that reports uploads as a success metric is counting that behaviour as delivery.

The top 1% of uploads carry 42.4% of all deliveries

Deliveries per upload: median 1, 90th percentile 2, 37,271 in total. The busiest 221 uploads — held by 156 distinct owners, so this is a broad group and not one team's traffic — account for 42.4% of them. A small number of links behave like a release channel, and everything else behaves like a handoff between two people.

The two halves of the population carry almost the same load: 18,025 deliveries against 19,246, from 4,496 account uploads and 17,535 guest ones. An account upload is delivered more often on average, and there are far fewer of them.

For anyone sizing infrastructure for this workload, that concentration is the design constraint: capacity has to be planned for a handful of links, while the median link costs almost nothing to serve. No single upload's delivery count is published, because a maximum is one owner's exact value; the total is, so every percentage on this page can be recomputed from the counts beside it.

An upload that gets delivered is usually delivered within the hour

This population is the exact complement of the never-delivered one above: 6,971 uploads were never delivered and 15,060 were, which is every upload in the window, because both sections count the same log. Of the 15,060 uploads whose first delivery the window could time, 14,165 were delivered within an hour of upload.

That raw figure is censored by construction and cannot be trusted on its own: an upload made on the last day of the window had no opportunity to fall into a “more than 7 days” bucket, so the first bucket is inflated in a way no footnote fixes. The second chart is the fix. It keeps only uploads with at least 7 days of observable window — 11,272 of them were delivered — so every bucket up to 7 days was reachable for every upload in it. The first-hour share moves from 94.1% to 93.9%, which is the point: the concentration in the first hour is real, and the censoring was not what produced it.

The operational reading: a link that breaks in the first hour breaks the common case, so expiry policy, notification timing and support response are aimed at the wrong interval if they assume a long tail. What neither chart can support is the stronger claim that a slow delivery never happens — only that it is rare within seven days of upload, which is as far as this window sees.

What a beta build actually weighs

iOS uploads are heavier than Android uploads at every point measured: a median of 52.8 MB against 38.6 MB, and a 90th percentile of 211.5 MB against 145.5 MB. This report measures the gap and does not explain it: packaging, per-device slicing and compression all differ between the two formats, and none of that is measured here. The cohorts differ too, in the opposite direction to the obvious guess — the median iOS upload from an account is 47.2 MB while the median anonymous one is 52.8 MB.

The histogram, not the average, is the shape to design around. 70.1% of the population sits under 100 MB, while the heaviest bucket, over 350 MB, holds 498 uploads.

How far back uploads still reach

The minimum OS version recorded at upload is the deployment target the team chose, so it measures a decision rather than a device population. On iOS the largest single bucket is iOS 15 with 3,704 of the 13,562 uploads shown. On Android it is API 24 (Android 7.0) with 3,978 of 7,280. The long tail below iOS 10 is real: developers are still shipping betas against deployment targets a decade old.

What testers are running, and the half of it that is not publishable

Tester OS is read from the user agent of the device that opened the install page. On iOS that value is real: iOS 18 accounts for 79.0% of the 9,119 iOS install events in this population, and the 6 major versions that clear both floors are the only ones published.

What happens on an install page

69,899 install events were recorded in the window against this report's population: 27,614 install pages opened, 37,271 builds delivered, and 5,014 requests refused before delivery. For scale, the platform recorded 117,319 install events in the same window against uploads of every age; this report covers a month of uploads, not a month of traffic, and those are different things.

Note what these three numbers do not permit: deliveries outnumber install-page opens, because a delivery does not require an install page to have been opened first. There is therefore no conversion rate to compute from them, and this page publishes none. The one rate the data does support is refusals as a share of delivery attempts: 11.9%.

A refusal is worth splitting, because it is not one thing. The largest single reason is the one below reading “Link had expired”, at 2,572 events, which is a policy applying as intended. But 969 of them — 19.3% of all refusals — are the build file being missing on the server for a link that is still valid, which is this service failing rather than a policy applying. Publishing a service-failure rate as if it were a user outcome is the worst error this page could make, so the split is published rather than summarised.

What this report cannot tell you is how many of those 37,271 deliveries became working installs. The platform records a delivery, not an install outcome: the status column on a delivery row is written as a constant by the only code path that writes it, and iOS hands back no install-outcome callback, so no code path here can record a failed install. A failure count from this data would be zero by construction rather than by observation, which is why none is published. Nothing on this page says anything about install failure rates.

Reach, expiry and automation

• Uploads came from 172 countries and were delivered in 164, counting only the events that were deliveries; counting every touch of an install page instead gives 172, which is a different and larger claim. The anonymous half is the wider one: 169 upload countries against 123 for account uploads. All of these are counts of countries and nothing more — they say nothing about whether any particular upload crossed a border, which is a different measurement this report does not make.
• Expiry is an ACCOUNT-side setting, so this one covers the 4,496 account uploads only: a guest upload gets a fixed lifetime and never chooses. 4,394 of them, 97.7%, were set to expire on a clock rather than on a download or device cap. The remaining 102 split across 4 other settings, each under a floor, which is why no second bar appears even though the residual is larger than the row floor itself.
• 71 accounts held a live API token on 2026-09-03. That is a point-in-time count over all history rather than a windowed one, so it is not a rate against anything else on this page, and it is one of the 4 figures read as of the query date rather than fixed by the window. The windowed split of command-line against browser uploads is withheld in full: The upload-method split is all-or-nothing under three floors, and at least one of its buckets does not clear them in this window. Publishing the bucket that does clear them, beside the population total, would recover the other by subtraction.
• Uploads per uploader in the window: median 1 and 90th percentile 4 per account, against median 1 and 90th percentile 3 per anonymous device. Both halves are dominated by people who upload once.

Tool counters, which are running totals

These come from a counter table that holds one running total per tool and keeps no per-run rows, so they cannot be windowed and are not comparable with any figure above. They are published because the ordering between them is informative on its own: inspecting a build is a common enough job to be worth a tool.

Methodology

Population

The unit is an UPLOAD, and there are 22,031 of them: every row created inside the window, whether or not expiry has since retired it, from both halves of the product. 4,496 came from 1,853 signed-in accounts and 17,535 from 9,989 devices with no account at all. An upload made without signing in is the same product action as one made with an account, so it belongs in the population; leaving it out, as the previous edition did, hides four fifths of what the service does.

Retirement is not a filter

Expiry retires an upload by flagging its row; it does not delete it, and no production path issues a delete. This edition therefore counts retired uploads, and reports retirement as an attribute: 2,731 account uploads (60.7%) and 17,897 of the 18,064 guest rows (99.1%) had already been retired when the data was taken. The consequence is worth stating plainly: because nothing here depends on what was live on a particular morning, the population does not decay. Re-running the published query over the same dates returns these uploads rather than a shrinking remnant of them — minus any account the exclusion list has picked up since, which is what the next entry is about.

What a re-run does and does not reproduce

Everything else is fixed by the window: retirement is not a filter, so re-running the published query over the same dates returns these uploads rather than a shrinking remnant of them. But “reproducible” is not the whole truth and this page will not print it unqualified, because the second run of the query falsified it: two runs minutes apart returned populations six uploads apart. The following are read as of 2026-09-03 rather than fixed by the window, and a later re-run will move them:

• the exclusion list, which is evaluated at query time and can only grow, so a later re-run returns this population minus whatever has since been excluded
• the retired shares, which describe what expiry had already done when the data was taken
• the live API token count, which reads the clock
• the tool run counters, which are running totals

The double-count rule, because one upload can have two rows

Claiming an anonymous upload into an account inserts a NEW row against the same file and does not delete the anonymous one, so the same physical upload exists twice in the database. The rule is: an anonymous upload claimed into an account inside this window is counted once, as the account upload it became, and its pre-claim deliveries are attributed there too. The window contains 18,064 anonymous rows, of which 529 fold into an account upload, leaving 17,535; 4,496 plus 17,535 is 22,031. An anonymous upload claimed after the window closed, or by an account the exclusion rule removed, stays anonymous here, because there is no in-scope account upload for it to collapse into. The query emits both halves of that arithmetic as checks and the page fails to build if either is off by one.

What a delivery is

One row in the install-event log, of type “install”, timestamped inside the window, counted against the build and against the anonymous upload it was claimed from. The per-upload download counter is never used: for a claimed upload the pre-claim deliveries sit on the old row while the new row's counter starts at zero, so the column reports already-delivered uploads as untouched. Events are windowed as well as uploads, which is the other half of reproducibility — an unwindowed delivery count keeps growing after publication, and a reader re-running the query would have no way to tell an error from an older edition.

Censoring

An upload made on the last day of the window had hours in which to be delivered, not a month. So the never-delivered share is an upper bound, and the raw time-to-first-delivery distribution cannot place a late upload in a late bucket at all. That is why the timing section publishes two charts: the raw one, and one restricted to the 16,614 uploads made at least 7 days before the window closed, for which every bucket up to 7 days was reachable. The two agree to within a fraction of a point, which is a result rather than a reassurance.

Exclusions

20 accounts are on the exclusion list and none of their uploads appear in any figure: any takedown, abuse strike, account suspension or refused upload screening, and on the guest side any upload named in a content takedown. That list is every such account in the database rather than a count of this window; 15 of them uploaded inside it, and 46 uploads were removed on that basis. The rule reaches the anonymous half too, where there is no account to exclude: those are removed by checking the takedown record directly against the upload, which removed 15 more. Abuse traffic is real traffic, and leaving it in would inflate the delivery and country figures with activity that has nothing to do with beta testing.

Suppression

Every bucketed breakdown must clear two floors in the query itself, not one: at least 50 rows AND at least 5 distinct owners, or distinct targets where the rows are events. An owner is the account for an account upload and the uploading device for an anonymous one; neither value leaves the query, only the count of distinct ones. A bucket that fails either floor is absent rather than rounded, and every affected chart names its own residual so nobody has to subtract. The second floor exists because the first cannot do the job alone: a 50-row bucket owned by two owners clears a row count and identifies a pair. The upload-source split carries a third floor — no single account may hold more than half of any published bucket — and is withheld in full in this edition, because publishing the bucket that clears the floors beside the population total would recover the other by subtraction. There are no exemptions, and the withheld bucket's size is not recorded anywhere that ships.

Identifiers

none: no app names, bundle identifiers, package names, accounts, e-mail addresses, IP addresses or subdomains. Country data is published as a count of countries and never as a per-country table, because a country with one upload plus a platform and a size is a re-identification path. No maximum is published anywhere, for the same reason: a maximum is one upload's exact value taken from inside a group too small to publish.

The user agent caveat

Chrome on Android freezes the OS version it reports in its user agent, so those rows pile up on one value and describe the browser, not the fleet. The Android version split is therefore withheld in full, at any threshold and with any footnote, and the query selects the iOS family only so a later edit cannot publish it by loosening a filter downstream. iOS user agents do not have this problem and that split is published.

Units and arithmetic

MB means 1024 x 1024 bytes, the unit the product prints. The window is 3 August 2026 to 2 September 2026 inclusive, 31 days, and its length is derived from its bounds rather than typed. Every percentage on this page is computed from the published counts at render time, so all of them can be recomputed from the numbers beside them — including the concentration share, whose denominator the previous edition withheld.

How this was measured

One committed SQL file produced every number here, run against the production database on 2026-09-03 over a read-only path documented at the top of that file. It runs inside a read-only transaction, which the database enforces rather than the author promising it, and it emits nothing but a section, a key and a count: the exclusion rule, both suppression floors and the window are applied in the query, before any data leaves the server.

The query also emits its own checks. Three of them must be zero — that the population partitions exactly into its two halves, that every in-scope delivery is attributed to exactly one upload, and that no upload's first delivery predates its own upload time — and the site refuses to build if any of them, or the 7 other identities a reader would check by hand, fails. That is not decoration: the previous edition shipped 45 individually correct figures, two of which could not both be true, because two sections were counting from different ledgers.

Its output is stored as a single data file in this site's repository, and this page renders from that file. No figure is typed into the prose, so a number cannot be right in the chart and wrong in the sentence. The report is refreshed quarterly with a new window; because retirement is no longer a filter, re-running the same file over the same dates returns this population rather than a shrinking remnant of it, with the as-of-query-date exceptions the Methodology lists. Each edition keeps its own window, and superseded editions are marked rather than silently rewritten — the notice at the top of this page is the current example. The query itself is published alongside the figures, as the SQL file that produced them, so the method can be read rather than taken on trust.

Where the data comes from

BetaDrop is the service these uploads were shared through. A developer uploads an .ipa or an .apk, with or without an account, gets one install link and a QR code, and testers install from a browser without accounts of their own. That is the whole surface the measurements above describe, which is also its limit: this is what beta distribution looks like on one service, not on every service.