Aggressive iOS Version Drops Are a Platform Mistake

iOS 16 shipped two weeks ago. That means it's deployment-target season at every mobile org I know about. The proposal lands in some architecture meeting: "now that iOS 16 is out, let's drop iOS 14." The reasoning sounds correct. Less compatibility code, fewer test devices, cleaner stack, more new APIs available. A senior engineer presents the case. Leadership nods. The minimum version on master ticks up by one.

The decision is almost always wrong, and the reason it is wrong is not the engineering. It is the framing.

The right mental model is not "what is the minimum OS we support." It is "which features ship on which OS versions." Once you put the question that way, the right answer to "should we drop iOS 14" is almost always "not yet," and the reasons are obvious. The work to not drop iOS 14 is much smaller than the cost paid by the long tail of users who can't or won't upgrade. The product implications of an aggressive drop are larger than the engineering cleanup wins.

I have watched this decision land badly enough times that I want to walk through it carefully.

What's actually being proposed

"Drop iOS 14" is shorthand for moving from n-2 support (iOS 14, 15, 16) to n-1 support (15, 16). It is a real architectural change. It removes a few hundred @available(iOS 15.0, *) checks, lets you delete a chunk of pre-iOS-15 compatibility code, narrows the test matrix, and frees up engineering attention.

It also drops a user base. MacRumors' Mixpanel-sourced post on Sept 14 shows iOS 16 at 11.6% of iPhones two days post-launch versus iOS 15 at 8.5% the prior year. That's a fast adoption curve. But the long tail is doing the load-bearing work for any honest version-drop conversation. Six to twelve months from now, iOS 14 will still be on millions of active iPhones. Some of those users can't upgrade because their devices were end-of-lifed. Some of them won't upgrade because they're on a managed device, or on a carrier with restrictions, or because they're someone's parent who hasn't installed an update in three years.

The aggressive-drop proposal asks you to write those users off in exchange for engineering cleanup. The implicit claim is that the cleanup is worth more than the lost users. The math almost never supports that claim.

What Apple just did

The reason this conversation is louder this year than usual is that Apple itself dropped four years of devices for iOS 16. After three consecutive iOS cycles (13, 14, 15) where the supported-hardware list was identical, iOS 16 cut off iPhone 6s and 6s Plus, iPhone 7 and 7 Plus, the original iPhone SE, and the iPod touch. That's a step change. It is also Apple making a hardware-support decision, not a software-support decision.

The two decisions get confused in the meeting. They are different. Apple decided that the new iOS doesn't run on older hardware. You are deciding that your app doesn't run on older iOS. Apple's decision was made on the basis of hardware capability and four-plus years of device aging. Your decision is being made on the basis of engineering hygiene. The asymmetry matters: Apple's decision is one-way and unavoidable for the affected users; yours is a product decision you are choosing to make, and your users will judge you on it.

What the senior iOS discourse actually recommends

The closest thing to a published consensus is conservative. samwize's March 2022 piece is the canonical reference for the practical version of this decision. The line that lands: "Developers are most excited to kill off support for older platform, while business people are not." The recommendation is n-1 as the conservative floor, n-2 as the supportive floor, with the threshold being App Store Connect analytics showing the older version has dropped under whatever your team's tolerance is (usually 1-5%).

Keith Harrison's WWDC 2022 viewing guide put the production reality in one sentence: "Many of the new APIs need iOS 16 so it may be a while before you can use them." That is the realistic timeline. New APIs are usable as soon as your minimum OS hits the relevant version. New APIs are production-default much later, after the adoption curve has flattened and your eng team has confidence the APIs themselves are stable.

Paul Hudson's standard interview answer is "current minus 1" as the deployment floor. Eric Sadun, Ole Begemann, and Soroush Khanlou have variations on the same theme. There is no senior-iOS-blog tradition arguing for n-1 at launch. The "drop fast" position is largely an internal eng-leadership voice that doesn't get published. The public corpus is consistent.

The numbers most teams don't actually pull

Before you drop a version, three numbers should be on the table.

Your actual user-base split by iOS version. Not "the global adoption curve." Your users. Pull it from App Store Connect. The skew can be dramatic depending on geography, device demographics, enterprise penetration, and how long your app has been on the App Store. Apps with old user bases skew old. Apps with young user bases skew new. Use your number, not the public one.

The conversion rate of "user on iOS 14" to "user who upgrades within 90 days." This is the number that tells you how forgiving a drop is. If 80% of your iOS 14 users move to a newer OS within three months, dropping is mostly a temporary user-pain event. If 20% do, you're writing them off.

The retention and revenue characteristics of the population you'd be dropping. A common pattern: the long-tail users are disproportionately your most loyal long-term users. They installed the app years ago, they use it weekly, and they are on the OS the iPhone they bought four years ago shipped with. Dropping that population is a much harder business decision than dropping a randomly selected slice of users. You can usually proxy this from your analytics pipeline by joining the OS-version cohort against your existing retention dashboard, or by cross-referencing App Store Connect cohorts with revenue. The data already exists. Almost no team pulls it.

The third number is the one most teams skip. They look at "what percentage of users are on the old OS" and stop there. The right question is who those users actually are and what they're worth.

Staged feature gating, the alternative

The alternative to "drop the version" is "stage the features." Your minimum OS stays at iOS 14. New features that require iOS 16 APIs ship as iOS 16-only. The old surface continues to work on iOS 14, 15, and 16. The user base sees a deliberate feature gating in the UI ("This requires iOS 16") for the small set of new capabilities that genuinely require the new OS.

This sounds harder than it is. The pattern is mostly @available checks at well-defined seams, with a degradation strategy that the design and product teams sign off on. The total volume of code is not enormous. The cost is the discipline of doing it deliberately rather than building everything against the newest APIs and finding out three weeks before ship that nothing works on iOS 14.

The benefits are real:

You don't write off users.
You get to use iOS 16 APIs where they help, instead of waiting two years.
You decouple the deployment-target question from the new-feature question, which were tangled in the original framing.
You get clean, visible evidence of which features required the OS bump. This matters when the next version comes out and someone asks "what did we get from raising the floor."

The cost is intellectual discipline at the platform level. You have to write down what is and isn't available below the new OS. You have to enforce it in code review. You have to make sure your CI runs on the supported version range. None of this is exotic. All of it is the kind of work the platform team should be doing anyway.

When dropping a version is actually right

The narrower set where I would actually recommend dropping:

The user base under the floor is genuinely tiny and stable. samwize's 1-5% range is the right zone; for high-retention apps I'd anchor at the low end, around 1%. Stable meaning the population isn't replenishing. If it's been at 1% for six months and showing no decline, those users are not coming back to a newer OS, and you're maintaining compatibility for a vanishing audience.

A critical capability requires the new OS. Not a "we'd like to use it" capability. A "we cannot ship the next major feature without it" capability. Even then, consider whether staged feature gating gets you most of the way.

The compatibility burden is materially hurting product velocity. Real material hurt, with numbers attached. Not "the team complains about it."

When all three conditions hold, the drop is defensible. They rarely all hold at once.

A decision rubric for the next planning cycle

If you're a mobile platform lead this October, the question I would put to your eng leadership is not "should we drop iOS 14." The question is "what does our user base look like by OS, and what is our 12-month feature roadmap actually requiring."

Pull the App Store Connect numbers. Project the adoption curve forward six months. Map the new-feature roadmap against required OS versions. The answer to "what should our deployment target be" usually emerges from that data in five minutes.

The teams I see making good calls are the teams that treat this as a data exercise, not an engineering hygiene exercise. The teams making bad calls are the teams that go around the room in the architecture meeting and let the loudest voice for "let's drop it" win because nobody is doing the user-side math.

This is the same shape as the build-time tax I wrote about in February: the engineering side of the calculation is visible, the user side of the calculation isn't, and the decision gets made on the visible side. The teams that account for both sides make better calls.

Where I land

Aggressive iOS version drops are a platform mistake because they optimize a cost the platform team feels and discount a cost the user feels. The right move at the start of every new iOS cycle is not "what's our new minimum OS." It is "which features ship on which OS versions." Staged gating beats version dropping for almost every team almost every year. Engineering cleanup is real but smaller than it feels. User pain is real and larger than it feels.

If you're in a planning meeting this week and someone proposes dropping iOS 14, the right response is "pull the App Store Connect numbers first, then we'll decide." If the numbers support it, drop. If they don't, stage. The conversation gets easier when it's about evidence rather than vibes.

iOS 16 is good. So is iOS 15. So, for a meaningful slice of your users, is iOS 14. Don't write them off in the September meeting.