iOS 27 shipped. Do not raise your deployment target yet.
Every September a client asks whether to require the new OS. The device list this year makes the answer clearer than usual, and it is still no.
Apple released iOS 27 and iPadOS 27 on 14 September. On iPhone it supports the 15 Pro and Pro Max, the 16 line and later, iPhone Air and iPhone Duo. On iPad it needs an M1 or an iPad mini with A17 Pro.
Within a day we had the annual question from two clients: can we require it. The answer is almost always no, and this year the device list makes the reasoning unusually easy to show.
The device list did the argument for us
Look at what iOS 27 leaves behind on iPhone. Every non-Pro model before the 16 is gone. That is not an old-hardware cut, it is a recent-hardware cut, and it means a meaningful share of phones bought in the last two years cannot install it at all.
Those users are not upgrading this quarter. They are not upgrading next quarter either. Raising a deployment target to iOS 27 today does not ask users to tap Update, it asks them to buy a phone.
What raising the target actually buys
Usually less than people expect. The reason given is normally a specific API, and the honest follow-up question is whether that API is load-bearing or convenient.
If it is convenient, availability checks cost a few lines and keep everyone on board. If it is genuinely load-bearing, the feature needs a designed fallback anyway, because a feature that simply vanishes on older devices is a support problem wearing a product's clothes.
The performance work is free either way
Apple quotes app launches around thirty percent faster, recently captured photos loading roughly seventy percent faster, AirDrop transfers about eighty percent faster, and iPad file operations up to five times faster.
That is the best kind of platform improvement, because your users get it by updating rather than by you shipping anything. It is worth putting in a client update note, and it is worth remembering when someone reads your app's launch time as a regression on a device that has not updated.
What we recommend instead
- Keep the deployment target where it is and adopt new APIs behind availability checks.
- Build and test against the new SDK immediately, which is a separate decision from raising the minimum and carries none of the same cost.
- Pull your own OS-version distribution before the conversation. Every argument here is stronger with your actual numbers than with anyone's industry average.
- Revisit in roughly a year, once the current generation has had a full cycle to spread.
Build against the newest SDK. Require the oldest OS you can live with.
The exception worth naming is a brand new app with no installed base, or an internal tool on managed devices where the fleet is known. Those are real cases, and they are rarer than the number of times the question gets asked.
Sources
Reporting and images linked above belong to their respective publishers and are shown from their own servers. The analysis here is our own.
