iOS in 2026: what is mandatory, what is optional, and what each one costs

Most writing about a new iOS release is aimed at developers picking what to build with. If you're paying for the app rather than writing it, you need a different cut of the same information. Which changes are compulsory, which ones buy you something, and which can sit for a year without hurting anyone.

The deadline that already passed

Since 28 April 2026, App Store Connect has rejected any submission that wasn't built with Xcode 26 and the iOS 26 SDK. That covers updates as well as new apps, so a one-line bug fix now needs the same rebuild as a major release.

One confusion here is worth clearing up, because it costs people money. The SDK you build with isn't the oldest iOS version you support. Moving to the iOS 26 SDK doesn't drop anyone on an older device. Your deployment target decides that, and you set it separately.

Your next update is a redesign, planned or not

An app built against the iOS 26 SDK picks up Liquid Glass, Apple's new material and control styling, on its native UI by default. Nobody asked for it and your designer never drew it, but buttons, sheets, tab bars and navigation all render differently than they used to. This catches almost everyone.

So the expensive part of that mandatory rebuild isn't the rebuild. It's the design and QA pass afterwards, across every screen, in light and dark, at large text sizes. Budget it as a small design project and it goes fine. Treat it as a build-and-ship and your users will tell you in the reviews.

There's an Info.plist flag that opts your app out and keeps the old look. It buys you one release cycle. Apple retires these escape hatches on a schedule of its own, and an app still wearing the iOS 18 look in 2027 reads as abandoned.

iOS 27, arriving in September

Developer betas landed in June. The change with real commercial weight is App Intents, which is now how the rebuilt Siri reaches into an app. SiriKit is on a deprecation clock.

App Intents is how you tell the system what your app can do, so something outside the app can trigger it: Siri, Spotlight, Shortcuts, and the widgets people keep on a lock screen. When someone can say what they want and land inside your app already doing it, that's a distribution channel you aren't paying for.

• •Do it if your app has a few clear repeated actions. Log a workout, start a timer, check a status.
• •Skip it if your app is mostly browsing or one long session, where there's no obvious verb to hand Siri.
• •Either way it isn't urgent this quarter, unless you already have work planned in that part of the app.

Foldables

iOS 27 adds adaptive layout APIs for hinge state and multiple display configurations. Apple doesn't announce hardware through APIs, but nobody builds that groundwork for fun.

For an existing app the question is whether its layouts were written to adapt or written to a size. Screens built against fixed dimensions carry a debt that comes due when the hardware arrives. Far cheaper to pay that down inside work you had scheduled anyway.

What we would fund, in order

• •The SDK rebuild and the design pass behind it. The QA is where the money goes.
• •Accessibility and large text checks in the same pass, since the new material changes contrast and you're already on every screen.
• •App Intents for your handful of core actions, if you have them.
• •Adaptive layout cleanup, folded into whatever feature work is already scheduled.

What we wouldn't fund yet is rebuilding anything to chase an API with no visible result for users. Every release ships a long list of those. Almost none of them change what a customer notices this year.