iOS 27 for your next app: what's worth adopting (and what's on its way out)

Today, September 14, 2026, iOS 27, iPadOS 27, macOS 27 Golden Gate, watchOS 27, tvOS 27, and visionOS 27 all shipped. Five days after the Surprise and Shine event, what Apple announced at WWDC 2026 lands on real devices.

For those of us building apps, that means two things: there are new APIs worth adopting, and there are deprecated pieces that start to weigh you down. This post reviews both as a shopping list — each section answers a direct question: would you put this in your next app? And when something replaces something else, I say so, because staying current on what’s leaving matters as much as knowing what’s arriving.

The iOS 27 SDK adds 3,760 new public Swift APIs and deprecates 363 across 149 frameworks (miniswift SDK diff). I won’t cover them all — I’ll cover the ones that actually move the needle on a typical app.

1. Foundation Models — now with third-party providers

What it is. The framework Apple introduced in iOS 26 to call the on-device model (the same one that powers Apple Intelligence) from a native Swift API, with typed outputs via @Generable. In iOS 26 it was “Apple’s model or nothing.” In iOS 27 it opens up: two new protocols, LanguageModel and LanguageModelExecutor, let any provider ship an integration as a Swift Package. Google’s Gemini is available through the Firebase Apple SDK, and Anthropic (Claude) is a launch partner (WWDC26 — Foundation Models, DEV Community coverage).

Also new: multimodal prompts (pass images alongside text), tool calling (the model can invoke functions you expose — including Vision for OCR or barcode readers), on-device fine-tuning, expanded context, and a larger model (byteiota — iOS 27 Foundation Models). The API is backwards-compatible: code written for iOS 26 Foundation Models compiles and runs in 27 with no changes.

Would you put this in your next app? Yes, if the app can skip a backend because of it. Concrete cases that fit: summarize content inside the app, extract structure from a photo (a shopping list from a receipt), local semantic search, an assistant chat that doesn’t depend on a server. It’s free, private, and offline — the best combination an LLM feature can have on mobile.

What it replaces. Nothing directly — it’s an alternative to calling an external API (OpenAI, Anthropic, etc.). Now you can also use those same providers through the unified framework, instead of assembling your own HTTP client.

2. Swift 6.4 — typed throws in Task and concurrency ergonomics

What it is. Xcode 27 ships Swift 6.4 (SwiftLee — What’s New in Concurrency, Michael Tsai — Swift 6.4). The most useful bits for day-to-day work:

Typed throws in Task. Before, Task { try something() } produced a Task<T, Error> — a generic error type. Now you can declare the concrete type: Task<T, MyError>. Small change, big impact: the catch stops needing downcasts.

// Before
Task {
    do { try await fetchOrder(id: id) }
    catch { print(error) } // what error is this?
}

// iOS 27 / Swift 6.4
Task<Order, OrderError> {
    do { try await fetchOrder(id: id) }
    catch { print(error.reason) } // the type is OrderError
}

async defer. You can now use await inside defer for clean asynchronous cleanup.
withTaskCancellationShield. Protects cleanup code from observing cancellation mid-flight.
Warning if you ignore a Task that can throw. The compiler flags leaving an orphaned Task whose throw you’ll never see.

About Swift 7 and concurrency warnings. It’s been said that “Swift 6 warnings become errors in Swift 7.” Technically true, but Swift 7 is projected for 2027-2028 (Medium — Road to Swift 7) — not imminent. Still, addressing data-race warnings now is worth it: when it arrives, you won’t be plugging leaks against the clock.

Would you put this in your next app? Typed throws in Task is instant adoption — zero cost, clearer error handling. The other changes are opt-in when you need them.

3. SwiftUI: adaptive toolbars, native reorder, lazy prefetch

What it is. iOS 27 introduces SwiftUI APIs designed to make the UI settle into whatever screen size shows up — not just because of the iPhone Duo foldable, but broadly (Adaptive SwiftUI Toolbars in iOS 27, What’s new in SwiftUI iOS 27):

visibilityPriority(.high | .low | .automatic) on toolbar items — tells the system which items to move to overflow first when space gets tight.
ToolbarOverflowMenu — put secondary commands there permanently so they stop competing for space.
topBarPinnedTrailing — anchor an item to the trailing edge regardless of screen width. Handy for the share button, typically.
toolbarMinimizationBehavior(_:for:) — controls whether the nav bar minimizes on scroll.

Also: native reorder in List and Grid, and lazy loading with prefetch for smoother scrolling. And in document-based apps, direct-to-disk access from SwiftUI (before you had to drop down to AppKit/UIKit).

Would you put this in your next app? Yes. The toolbar APIs are zero cost and get you adaptive UX for free. Native reorder especially — if your app has a reorderable list, you stop maintaining your own drag-and-drop.

What it replaces. The custom reorder that plenty of people write with GestureRecognizer or .onDrag/.onDrop. And the layouts you used to gate on if horizontalSizeClass == .compact { ... } give way to letting the system decide.

4. App Intents — mandatory for Siri, SiriKit officially on the clock

What it is. Apple formally deprecated SiriKit at WWDC 2026 (byteiota — SiriKit Deprecation, Medium — Your App Is Invisible to Siri). Starting with iOS 27, App Intents is the only way Siri can call into a third-party app. If your app doesn’t expose App Intents, Siri can’t discover it, invoke it, or include it in multi-app workflows.

Important timing detail: SiriKit still compiles for another couple of years (Apple gave a two- to three-year window), but from today, any SiriKit-based app is invisible to the new Siri with Apple Intelligence. It gets no voice traffic, no Spotlight indexing, no participation in Apple Intelligence personalization. The hard compile deadline is far off; the hard relevance deadline is today.

Would you put this in your next app? New app: start with App Intents from day one. Existing app on SiriKit: migrating is the next priority — not because the app breaks, but because it disappears from the assistant experience.

What it replaces. SiriKit, period. The architecture changes: instead of mapping into a fixed domain vocabulary (messaging, lists, etc.), you define arbitrary actions with typed parameters and privacy declarations.

5. NowPlaying framework — one API for every playback surface

What it is. A new iOS 27 framework that unifies how your app appears on Lock Screen, Control Center, Dynamic Island, CarPlay, and StandBy — before, each was a separate integration (WWDC26 — Meet the Now Playing framework).

Two key protocols: MediaSessionRepresentable (describes your content: title, artwork, playback state; registers commands: play, pause, skip) and RemoteMediaSessionRepresentable (for external playback, syncing via app extensions and APNs).

CarPlay bonus: a MiniPlayer in the Now Playing template, and a progress bar that finally lets the user jump to a specific spot in a song, podcast, or audiobook from CarPlay.

Would you put this in your next app? Yes, absolutely, if your app plays audio or video. It collapses four separate integrations into a single API.

What it replaces. It doesn’t retire MPNowPlayingInfoCenter immediately, but the new framework is where the load goes from here. For new apps, start here.

6. SwiftData — observers, sectioned queries, Codable types

What it is. Four concrete additions in iOS 27 (InfoQ — SwiftData 27, Michael Tsai — SwiftData in appleOS 27, The Swift Dev — ResultsObserver/HistoryObserver):

ResultsObserver — observes changes to a fetch outside a SwiftUI view. Before, you had to wrap everything in a @Query inside a view, or write your own diffing. Now an @Observable can react to the store directly.
HistoryObserver — observes the persistent history of the store. Useful for syncing with remote servers or keeping other systems current. Exposes an eventCounter that increments on each transaction.
.codable attributes. Persist custom types (including ones you don’t control) by marking Schema.Attribute as codable. Note: they’re opaque, so you can’t use them in predicates or sort descriptors.
Sectioned queries and enum predicates. The @Query macro takes sectionBy, and predicates accept enums directly.

Would you put this in your next app? Yes, if you already use SwiftData. Observers are the big shift — if you had a “service” layer wrapping SwiftData because you couldn’t observe outside a view, that layer simplifies.

What it replaces. The pattern of wrapping SwiftData in a hand-rolled observable service. And sectioned queries replace groupings you used to do in the View with Dictionary(grouping:by:).

7. Widgets and Live Activities — new canvas, landscape Dynamic Island

What it is. Two related but separate things:

systemExtraLargePortrait — a new widget family, 4×6 canvas. On iPhone: portrait only, fills an entire Home Screen page. On iPad: landscape only. On Mac: both (9to5Mac — Extra-large widgets).
Live Activities in the landscape Dynamic Island. Compact and minimal presentations used to hide in landscape; now they show. A new environment value isDynamicIslandLimitedInWidth lets you adapt the layout in tests (WWDC26 — Live Activities essentials).

Would you put this in your next app? The XL widget: yes, if you have content worth showing with more room (a dashboard, a timeline). The landscape Dynamic Island: yes, right away, if you have Live Activities — it’s adjusting two views, not a whole new feature.

What it replaces. Nothing — it’s additional capacity, not a replacement for existing families.

Heads up. Apple updated App Store guideline 4.5.3: no using Live Activities for unsolicited marketing. If your app uses them for ads or promotions the user didn’t ask for, review will reject.

8. Swift Testing — XCTest interop for incremental migration

What it is. Xcode 27 / Swift 6.4 ships the interoperability mode between Swift Testing and XCTest (WWDC26 — Migrate to Swift Testing, InfoQ — Swift 6.4 features) that was missing for migration to be realistic:

Limited. Cross-framework XCTest issues surface as warnings.
Complete. Those warnings become errors.
Strict. Fatal error, pointing at every spot XCTest still lives.

Bonus: XCTAssert calls now surface as proper issues in Swift Testing, and #expect works inside XCTestCase.

Important clarification: XCTest is not deprecated. Migrating to Swift Testing remains optional. What changed is that incremental migration is now viable — Apple recommends leaving most XCTests in place, writing new tests in Swift Testing, and migrating the ones you touch most.

Would you put this in your next app? New app: yes, Swift Testing from day one. Existing XCTest suite: adopt Swift Testing for new tests, leave the old ones where they are.

What it replaces. Long-term, XCTest. Short-term, nothing — they coexist.

9. Xcode 27 — on-device completion and agentic coding

What it is. Xcode 27 changes the daily flow of writing code on two levels (Xcode 27 On-Device AI, byteiota — Xcode 27 Agentic Coding):

On-device completion. Autocomplete, method prediction, multi-line suggestions — all running on the Mac’s Neural Engine. Zero code is sent to the cloud for daily autocomplete. This is the new default.
Agentic coding. For heavier tasks (planning a feature, refactoring, localizing, running and debugging tests), an agent with Claude, Gemini, or GPT can operate inside the editor. It’s explicit opt-in — nothing goes to the cloud unless you turn it on.

For complex asks, the agent shows a planning interface: it describes steps, you review and approve before it executes.

Would you put this in your next app? It doesn’t change your app, it changes your flow. Adopting on-device completion is a free win: better autocomplete without the privacy trade-off. Agentic coding is worth evaluating when it makes sense — not “adopt for adoption’s sake.”

What it replaces. Index-based traditional completion, for the 90% case. Repetitive manual typing.

10. Breaking changes — what breaks the build if you ignore it

These are the ones Apple forces you to handle before shipping a binary against the iOS 27 SDK (Blake Crosley — ImageCreator deprecated, UIKit’s Scene Mandate, Stackademic — iOS 27 SDK Breaking Changes):

Launch screen required. Without one, App Store rejects the submit. Storyboard or LaunchScreen, either works — but you need one.
UIKit scene-based lifecycle mandatory. If your app is still on the old UIApplicationDelegate-only lifecycle, it won’t launch on iOS 27. You have to adopt UIWindowScene and UISceneDelegate.
Liquid Glass opt-out removed. The temporary Info.plist flag that let you disable Liquid Glass in iOS 26 is gone. Your app renders with the new material, period.
ImageCreator removed. The Image Playground API for generating images from code no longer compiles in iOS 27. During betas it compiled with warnings but failed at runtime; in the public release it stops compiling entirely.
ld64 removed. The old linker is gone. The -ld_classic flag no longer works.

And these are deprecated — not broken yet, but the clock’s running:

NSBundleResourceRequest / On Demand Resources → migrate to Background Assets.
PreviewProvider and its preview modifiers → migrate to the #Preview macro.
SwiftUI’s ReferenceFileDocument → migrate to ReadableDocument/WritableDocument.
@State is now a Swift macro (source-compatibility is there, but some edge cases may show up).
Several UIApplication status-bar accessors deprecated.

How to prioritize

If I had to order the above by urgency, this is how it’d stack:

Do it now (before the next build): launch screen, UIKit scene lifecycle, remove ImageCreator. Without these, you don’t ship.
Migration with a clock (this quarter): SiriKit → App Intents if applicable, PreviewProvider → #Preview, On Demand Resources → Background Assets.
Adopt when you touch the code: typed throws in Task, adaptive toolbar APIs, ResultsObserver/HistoryObserver in SwiftData.
Explore when it fits: Foundation Models with a third-party provider, NowPlaying framework if your app has playback, XL widget if you have content that earns the canvas.
Change your flow, not your app: On-device completion in Xcode 27 (free, no risk), agentic coding when the task justifies it.

The pattern is the same as every big Apple release: there are obligations (they break the build), migrations with a schedule (Apple gives time, but not forever), and voluntary adoptions (they improve the app but you can live without them). This year the obligations list is shorter than the migrations list, but SiriKit + Background Assets + #Preview earn their spot in the backlog now. And Foundation Models with an external provider changes what you can build without a backend — worth an afternoon of exploration when you can spare it.