RevenueCat outlined a practical framework for deciding when to raise a subscription app’s minimum iOS requirement, using a mix of Apple adoption data and cross-app subscriber behavior. The details were laid out in the company’s official post.
The central tension is not technical purity versus “support everyone.” It is a compounding growth trade: every blocked install on an older iOS version is a customer you do not get back, while every extra week spent on backward compatibility is product velocity you do not recover.
Table of contents
Jump to each section:
- What the adoption data actually suggests about paying users
- The real business tradeoff behind a minimum iOS bump
- Why 2026 makes “minimum iOS 26” a different kind of decision
- A simple way to run the numbers before you cut off older iOS users
- What this means for marketers
What the adoption data actually suggests about paying users
Apple’s iOS 26 adoption snapshot (79% of all iPhones, and 86% of iPhones introduced in the last four years running iOS 26) creates an easy mental shortcut: “most users are already there.” RevenueCat’s platform-level subscriber view complicates that.
Across apps on RevenueCat, about 88% of paid subscribers who opened the app in the last 90 days were on iOS 26. iOS 18 still represented 9.4% of subscribers and 9.6% of revenue. Looking at new transactions, 85% occurred on iOS 26.
One observation worth remembering: OS adoption is not your audience, it is a blended average across many business models.
The post also highlights why averages mislead. Large, mass-market apps can pull platform-wide behavior toward broader device coverage. In contrast, a niche subscription product may skew newer. In a side-project app cited in the piece (“Weather Up”), roughly 94% of paying users active in the past 90 days were on iOS 26.
Strategic tension: teams often treat “minimum OS” as an engineering default. In practice, it is a segmentation decision that reshapes your funnel.
The real business tradeoff behind a minimum iOS bump
Raising a minimum OS version has two costs:
- Existing users on older versions keep the app, but get stuck on the last compatible build.
- New users on older versions cannot download at all.
The second cost is the one that compounds. The blocked users are not just “lost this month.” They are removed from future conversion opportunities, upgrades, and referrals.
A conservative benchmark in the discussion came from David Smith’s experience: nine months into the iOS 18 cycle, requiring the latest OS would have reduced new downloads by about 9% for his app. His threshold was to wait until older versions fall to around 1% of new downloads.
A more aggressive stance in the post is essentially: if older iOS versions represent under ~10% of new paying users and the speed gained is real, the trade can be worth it.
Memorable insight: A minimum iOS decision is not about who you disappoint, it is about which constraint you choose to carry, funnel loss or shipping drag.
Why 2026 makes “minimum iOS 26” a different kind of decision
The post argues that 2026 changes the calculus for some subscription apps because the “support older versions” tax has gotten more visible, especially around design and QA.
Three concrete points from the piece shape that argument:
- App Store submissions must be built with the iOS 26 SDK (as of April 28), which means modern UI behavior (including Liquid Glass) is already part of the shipping reality for iOS 26 users.
- Apple confirmed iOS 27 runs on the same devices as iOS 26 (iPhone 11 and newer). So moving to an iOS 26 minimum does not exclude users whose hardware could otherwise run the next version.
- TelemetryDeck data cited in the post suggested iOS 18 had dropped to about 10% of active devices by the end of June, implying the “cost” side shrinks with time.
The practical example in the post is intentionally unglamorous: a developer choosing iOS 26 minimum partly because they did not own an iOS 18 device anymore. That is a quiet operational risk, especially when the remaining users may be paying subscribers.
Another observation that cuts through the debate: backward compatibility is cheap right up until it is not. “Two design systems in one binary” is not a rounding error.
A simple way to run the numbers before you cut off older iOS users
The most useful part for operators is the suggested four-part check. Instead of debating the minimum iOS version in abstract, the post recommends pulling recent data (last 90 days) and looking at behavior by OS version.
1) New users by OS version
Example provided: for Weather Up, 83% of new users in the past 90 days were on iOS 26 or newer.
2) New purchases by OS version
Example provided: for Weather Up, 85% of new purchases in the past 90 days were on iOS 26 or newer.
3) Active subscribers by last-seen OS version
Example provided: for Weather Up, 94% of active subscribers were on iOS 26 or newer, with 8.5% already on the iOS 27 beta.
4) What the floor buys you
This is the step teams skip, and it is the one that decides everything. If raising the minimum iOS version does not change what you can ship or how fast you can ship it, then you are mostly just paying the acquisition cost for little return. But if the app’s UI or frameworks meaningfully benefit from the newer OS (Liquid Glass was the example), velocity gains can be real.
A subtle but important point raised: your OS mix is not a fixed property of your product. It can shift with traffic source. App Store search and featuring may skew broader, while a major launch moment can pull in earlier adopters.
Memorable insight: Minimum OS is a growth lever disguised as a technical setting, because it changes who can enter your funnel.
What this means for marketers
Marketers usually do not set the minimum OS version, but they live with the consequences. This is a product policy decision that changes reach, conversion quality, support load, and creative expectations.
1) Treat OS support as audience strategy, not compatibility hygiene
If older iOS users are a meaningful slice of revenue, a minimum bump is not “cleaning up tech debt.” It is a deliberate decision to narrow who the product is for, and the messaging should reflect that reality.
2) Segment your funnel metrics by OS the same way you segment by channel
The post’s recommended views (new users, new purchases, active subscribers by OS) mirror marketing questions: who discovers, who converts, who sticks. If OS version is a proxy for device age and device age is a proxy for purchase intent, OS becomes an audience quality signal, not just a support burden.
3) Plan launch moments around the audience you are choosing
If a team raises the minimum iOS version to ship faster with newer UI patterns, the launch narrative should target the users most likely to be on that OS. The “wrong” traffic source can make a reasonable product decision look like a growth mistake.
4) Make the tradeoff visible in retention language, not just acquisition math
The counterargument in the discussion was essentially “better available and maybe buggy than not available.” That is harder to justify when the users most likely to hit edge-case bugs are paying subscribers. Marketing and product teams should align on what kind of customer experience risk is acceptable for the brand.
The deeper shift is that platform changes (SDK requirements, UI paradigms, device support lines) increasingly force product choices that ripple into marketing economics. As teams adopt faster design cycles and AI-assisted development, the temptation will be to raise floors more often.
The more interesting question is not “what minimum iOS should we support.” It is “what customer profile are we optimizing for, and can our growth model survive the users we exclude.”
Leave a Reply