Minimum iOS and download size: two gates, and two figures nobody can compute

Two fields on your App Store product page settle things before anyone reads a word of your description. The minimum iOS version decides who can install — a device on an older release does not get a lesser experience, it gets none. The download size is one of the few costs a person can see before tapping Get, printed next to every rival's.

Both come back from Apple's public API on effectively every app. And the two questions developers actually ask about them — what share of devices does my minimum shut out, and am I over the cellular limit — cannot be answered from anything Apple publishes. That is the finding; what follows is why, and what to compare instead.

The two fields arrive, reliably

Worth establishing first. On 2026-08-20 I pulled the top 25 software results for eight US search terms — photo editor, weather, budget tracker, meditation, pdf scanner, habit tracker, language learning, recipe — and checked both fields on all 200.

minimumOsVersion came back on 200 of 200. fileSizeBytes came back usable on 200 of 200, and arrived as a string in all 200, not a number. An earlier sweep in this repo found both fields on 108 of 108 apps across five search results. So neither is a field you must code around missing — but both are fields you parse rather than trust, and the parsing is where it goes wrong.

Apple publishes one adoption number, and it is not a breakdown

Here is the whole of it, from Apple's App Store support page, checked on 2026-08-20:

• iOS 26 runs on 79% of all devices, and 86% of devices introduced in the last four years.
• iPadOS 26 runs on 68% of all devices, and 79% of devices introduced in the last four years.

Apple attaches one sentence about where those come from:

"As measured by devices that transacted on the App Store on June 7, 2026."

That is one pair of figures for the current release. There is no share for iOS 18, none for iOS 17, none for iOS 16 — no per-version distribution anywhere on the page.

So the sentence everyone wants — "requiring iOS 17 excludes N% of devices" — is not computable from public data. Not approximately, not with a caveat, not by interpolation. The denominator does not exist.

Several third-party sites publish exactly that figure anyway, often to one decimal place and for every version at once. None of it can come from Apple, which publishes one number and it is about iOS 26. A tenth of a percent invites a confidence the underlying data cannot support.

So the 79/86 pair is dated context. It never becomes a denominator.

No current Apple page states a cellular download limit

The received wisdom is that an app over 200 MB will not download over cellular. I went looking for that number at Apple and could not find it on any current page.

I searched the extracted text of those pages rather than eyeballing them, because Apple's help paths return HTTP 200 for URLs that do not exist. The iPhone User Guide article ran 32,661 characters of body text and contained zero occurrences of "MB" and zero of "200". The size-reduction documentation contained no occurrence of "cellular", "over-the-air", or any MB threshold.

The only first-party statement I found is nearly nine years old, and it is a raise, not a ceiling:

"We've increased the cellular download limit from 100 MB to 150 MB, letting customers download more apps from the App Store over their cellular network."

That is Apple, in 2017. Whether that number still stands is exactly what I could not establish. The widely-repeated 200 MB figure appears in press coverage and forum posts, never on a current Apple page I could find; iOS 13 is also reported to have turned the hard block into a prompt, likewise unconfirmed first-party.

So this post states no size cutoff, and neither does the tool. Not as a constant, not as a warning, not as the edge of a histogram bucket — any bucket boundary on a size chart reads as the threshold. If your users are on metered connections that is a real constraint, but not one anybody can pin to a number Apple currently publishes.

What you can compare instead

Both fields are exact and public for every app, and a search result is a defensible cohort: the apps a person is choosing between when they see yours. Position in that set is worth knowing even though the absolute questions are not.

From the same 2026-08-20 sample, 25 apps per result:

Two things stand out. The median app in all eight results required iOS 15.x or 16.0, while Apple's current release is iOS 26 — the middle of a search result sits well behind the newest version. And the size spread inside one result is enormous: weather ran 7.4 MB to 441.9 MB, a factor of sixty between two apps competing for the same tap.

That spread is the argument for comparing at all. "Is 180 MB big?" has no answer. "Is 180 MB big for a pdf scanner, where the middle of the result is 171.4 MB" does.

The median minimum is an observed cohort value, never an average. Averaging iOS 15.0 and iOS 16.0 would print 15.5, a version nobody requires and nobody could ship against.

Two ways these numbers break quietly

Version strings are not consistently formatted, so a string sort is wrong twice over. In my 200-app sample, bare 15, 16 and 17 sat alongside 15.0, 16.0 and 17.0 — all three majors in both forms — plus 18.0 and 18.0.0. Apple renders both forms too: Tezza's API value is the bare string 17 while its product page reads "Requires iOS 17.0 or later". Sort those as text and one requirement splits into two rows in your distribution — and 15.6 orders above 15.10, because 6 > 1 by character. Both are fixed by parsing to numeric components and comparing component by component.

Size is decimal MB, not MiB. Two live listings, both checked against their own product pages on 2026-08-20:

Divide by 1024² and you show a developer a number that disagrees with the page in front of them, by about 5%. Not hypothetical: a formatter in this repo's own compare page still divides by 1024², a known bug that has not been fixed. Worth grepping your own code for.

What this cannot tell you

The comparison above is relative, and that is all it is:

• It cannot tell you how many devices your minimum excludes. Apple publishes no per-version breakdown, so that number is unavailable to everyone — including the tools that print it.
• It cannot tell you whether your size crosses a cellular threshold, because no current Apple page states one.
• It cannot tell you what either costs you in installs. Nothing public connects a minimum iOS or a download size to a conversion rate; that link, if it exists for your app, shows up only in your own analytics.
• It cannot tell you what a given device actually downloads. Apple's size-reduction documentation describes thinned builds per variant, and says of the size report: "The uncompressed size is equivalent to the size of the installed app on the device, and the compressed size is the download size of your app." So one number on a product page cannot be what every device fetches, and Apple does not document which variant the listed size is.
• The two endpoints can disagree. Verified in this repo for one app, same country, seconds apart: lookup returned v2.14.20 dated 2026-07-30 while search returned v2.14.21 dated 2026-08-05. Both fields move on a version bump, so building your app from one endpoint and the cohort from the other grades you on your previous build.

There is no score here, and no advice to change either number. Raising a minimum iOS deletes compatibility branches and opens newer APIs — a legitimate engineering decision, not a mistake to correct. A smaller binary is not automatically better either: for many apps the on-device assets and models are the product. Position is the output; the trade is yours.

Install friction runs this comparison against your app's own search result; language coverage does the same for the languages your binary declares.