Should you require the new iOS? A five-question checklist before you touch the deployment target

Every September someone on the team asks the same thing: now that the new iOS is out, can we just require it?

It sounds like housekeeping. It isn't. Raising your minimum OS is one of the few decisions that can quietly remove paying users from your app, and it's usually made in a five-minute conversation. Here is the checklist we use at APPDOOK to slow that conversation down.

1. Can every affected user actually update?

This is the question people skip, because they picture the user who just hasn't tapped Update yet. That user exists, but they're not the problem.

The problem is hardware. iOS 27, released on 14 September, runs on the iPhone 15 Pro and Pro Max, the iPhone 16 line and later, iPhone Air and iPhone Duo. Every non-Pro iPhone before the 16 is left out. That is a cut into phones people bought in the last two years.

For those users, a higher deployment target isn't a nudge to update. It's a request to buy a new phone. Most won't, and they won't email you about it either. They'll just stop getting updates, or stop finding you in the App Store.

2. Is the API you want load-bearing, or just convenient?

The reason given for raising the target is almost always one specific API. Ask honestly which kind it is.

If it's convenient, an availability check costs a few lines:

if #available(iOS 27, *) {
    useNewAPI()
} else {
    useExistingPath()
}

If it's load-bearing, you need a designed fallback anyway. A feature that silently disappears on older devices doesn't save work. It turns into support tickets.

3. Are you confusing "build with the new SDK" and "require the new OS"?

These are two separate decisions, and they get bundled together all the time.

Building against the newest SDK is cheap and you should do it immediately. You get the new APIs, and you see deprecation warnings early. Requiring the newest OS is expensive, for all the reasons above. You can do the first without the second.

The short version: build against the newest SDK, and require the oldest OS you can live with.

4. Do you have your own numbers?

Industry averages for OS adoption are interesting, but they're not your users. Before the conversation, pull the OS version split from your own analytics or App Store Connect.

Every argument in this checklist gets stronger, or weaker, once you can say "this would cut off X% of our active users" instead of "probably not many people".

5. Is this one of the real exceptions?

There are cases where requiring the newest OS is fine:

• a brand-new app with no installed base to leave behind
• an internal tool on managed devices, where you know exactly which hardware is in the fleet

Those are real. They're also much rarer than the number of times the question gets asked.

What to do instead

• Keep the deployment target where it is, and adopt new APIs behind availability checks.
• Build and test against the new SDK now.
• Bring your own OS version numbers to the discussion.
• Put the question back on the calendar for about a year from now, once the current hardware generation has spread.

That last step matters. "Not now" is a much easier answer to give when it comes with a date for "later".

We went through this year's device list in more detail, including why this cut is different from most years, in APPDOOK's notes on raising the deployment target.

Written by the APPDOOK team, a small product studio in Surat, India. If your team has a different rule of thumb for this decision, we'd like to hear it in the comments.