Apple WWDC 2025: Developer APIs and Features Worth Shipping Against Now

If you sat through the WWDC 2025 keynote and the follow-on sessions, you already know Apple shipped a lot. The harder question is figuring out which announcements are ready for production today versus which ones are still in early-access territory where shipping too early will cost you more in rewrites than waiting another quarter.

This article cuts through the keynote polish and focuses on the APIs and platform changes that are stable, well-documented, and worth building against before iOS 26 hits general availability.

What you'll learn

• Which Apple Intelligence APIs are ready for production use and how to call them
• What Swift 6.2 changes affect your existing concurrency code
• How the new App Intents expansion opens up deeper system integration
• Where the VisionOS 2 spatial APIs fit if you're building for that platform
• Common mistakes developers are already making with the new design system

Prerequisites

You'll need Xcode 17 (currently in beta) and a device or simulator running iOS 26 beta to test anything covered here. The Foundation Models API requires a device with Apple Silicon — A17 Pro or M-series — so keep that in mind when planning your minimum deployment target. A basic familiarity with Swift concurrency (async/await, actors) is assumed throughout.

Apple Intelligence Moves On-Device: The Foundation Models API

The biggest developer story from WWDC 2025 is the Foundation Models framework. Apple is giving you direct access to the on-device language model that powers Apple Intelligence features, without any network round-trip. This is not a wrapper around a remote API — it runs locally, which has real implications for latency, privacy, and offline capability.

The API surface is intentionally constrained. You get a LanguageModelSession that you configure with a system prompt and then send turns to. Apple controls the underlying model weights and can update them via OS updates, so you're building against a capability contract rather than a specific model version.

import FoundationModels

let session = LanguageModelSession(
    instructions: "You are a concise product description writer. Reply in plain text only."
)

let response = try await session.respond(
    to: "Write a two-sentence description for noise-cancelling earbuds."
)
print(response.content)

The latency on-device is genuinely fast for short completions — well under a second on an A17 Pro in early testing. The model is smaller than anything you'd run remotely, so don't expect it to reason through complex multi-step problems. It excels at classification, short-form generation, and structured extraction where you control the prompt tightly.

Apple also added Structured Output support, where you define a Swift type conforming to Generable and the model guarantees a valid instance back. This is more reliable than parsing free-form JSON strings.

import FoundationModels

@Generable
struct ProductTag {
    let name: String
    let category: String
    let confidence: Double
}

let session = LanguageModelSession()
let tag = try await session.respond(
    to: "Tag this product: 'Over-ear wireless headphones with ANC'",
    generating: ProductTag.self
)
print(tag.category) // "Audio"

If your app already calls a remote model API for lightweight tasks, this is a direct replacement worth evaluating. For a broader picture of how on-device AI compares with cloud-based model calls in real apps, the article on edge AI chips and what new hardware means for developers covers the tradeoffs in more depth.

Swift 6.2: Concurrency Gets More Practical

Swift 6.0 introduced strict concurrency checking and, in many codebases, produced an avalanche of compiler errors. Swift 6.2 walks back some of that friction without abandoning the safety model. The most practical change is default actor isolation for main-actor types, which reduces the number of explicit @MainActor annotations you need to scatter through view code.

There's also a new nonisolated(unsafe) keyword that lets you opt specific stored properties out of actor isolation checks when you know access is safe but can't prove it to the compiler. Use it sparingly — it's an escape hatch, not a pattern.

For most teams, the practical impact of 6.2 is that migrating a moderately sized app to Swift 6 language mode is now much more tractable. If you've been deferring that migration, now is a good time to try it with the 6.2 toolchain.

UIKit and SwiftUI: What Changed and Why It Matters

SwiftUI Animation APIs

SwiftUI gained a proper Phase Animator revision that lets you sequence multi-step animations with explicit phase tracking. Previously, chaining animations reliably required dropping into UIKit or using fragile DispatchQueue.main.asyncAfter delays. The new API gives you a clean enum-driven state machine for animation phases, which pairs well with the new Liquid Glass design language Apple introduced this year.

UIKit Bridging Updates

Apple improved the UIHostingController and UIViewRepresentable bridges significantly. Size reporting from hosted SwiftUI views back to UIKit is now more predictable, which was a persistent source of layout bugs in mixed-stack apps. If you maintain an app that still has substantial UIKit infrastructure, this alone is worth testing in the beta.

Liquid Glass and the Design System Shift

Apple's new visual language, Liquid Glass, isn't just a cosmetic update — it changes how several system components render and respond to light. If your app uses custom navigation bars, tab bars, or sheet presentations, you will need to review them against iOS 26. The translucency and blur behaviors have changed under the hood.

The practical advice here is to run your app on an iOS 26 simulator before anything else. Flag any component that uses UIBlurEffect directly or overrides barTintColor. Apple has deprecated a handful of older appearance APIs and the deprecation warnings will point you to the replacement calls.

Don't try to replicate Liquid Glass manually with custom shaders or Core Animation layers. Apple will iterate on the look, and any hand-rolled approximation will look wrong by the time iOS 26.1 ships.

The New App Intents Expansion

App Intents got a significant expansion that makes it the right path for any feature you want exposed to Siri, Spotlight, the Action button, or Apple Intelligence. The key addition is App Intent Domains, which lets you declare that your intent conforms to a system-understood semantic domain like .photos, .messaging, or .media.

When your intent declares a domain, Apple Intelligence can invoke it as part of a composed task the user requested in natural language, even if the user never explicitly named your app. That's a meaningful discoverability unlock.

import AppIntents

struct ShareClipIntent: AppIntent {
    static var title: LocalizedStringResource = "Share Clip"
    static var description = IntentDescription("Shares a video clip from the library.")

    @Parameter(title: "Clip")
    var clip: ClipEntity

    func perform() async throws -> some IntentResult {
        // sharing logic here
        return .result()
    }
}

If you previously implemented SiriKit Intents (INIntent subclasses), Apple has signaled that the migration path is App Intents and the old framework is in maintenance mode. Plan that migration for this cycle if you haven't already. The pattern here echoes what happened when Anthropic opened up structured tool-calling in their APIs — compare that to the Model Context Protocol implementation guide if you want to see how structured capability declaration plays out in practice.

Live Activities and the Lock Screen API Refresh

Live Activities received two meaningful updates. First, interactive Live Activities can now include toggle controls and simple button actions that execute an App Intent without opening the app. This was possible before only in limited form; the new API is cleaner and doesn't require a notification payload to trigger it.

Second, the Smart Stack on watchOS now pulls Live Activity data directly from the paired iPhone app using a new feed mechanism. If your app has a Live Activity, you get watchOS presence nearly for free — you declare the data model once and the system handles the display.

The update budget for Live Activities is still rate-limited, so don't architect a feature that requires high-frequency pushes. Design for the constraint from the start rather than trying to work around it later.

VisionOS 2 and the Spatial APIs Worth Knowing

VisionOS 2 continues to refine the windowing model and adds a few APIs that make it easier to build apps that feel at home in the spatial context rather than just being iPad apps floating in space.

The Volumes API is more capable this year, supporting dynamic resizing and programmatic anchor updates. If you're building a 3D content viewer or a data visualization tool, Volumes are now a reasonable production target rather than an experiment. The SharePlay for spatial updates also deserve attention — synchronized shared experiences in visionOS are significantly easier to implement with the new coordination APIs.

For most teams without an existing visionOS presence, the honest advice is to spend time on the Foundation Models and App Intents work first — those ship to a much larger user base. Come back to visionOS-specific features once you've covered the iOS 26 baseline.

For context on how Apple's spatial and AI bets fit into the broader developer platform story, it's worth reading through how Google I/O 2025 approached developer priorities — the contrast in platform strategies is instructive for planning your own roadmap.

Common Pitfalls Developers Are Already Hitting

Based on beta feedback threads and developer forums, a few issues are coming up repeatedly.

• Foundation Models API availability checks: The API is only available on supported hardware. You must call LanguageModelSession.isAvailable before attempting to create a session. Apps that skip this check will crash on unsupported devices.
• Swift 6 strict concurrency in test targets: Enabling Swift 6 language mode in your main target but not your test target creates subtle inconsistencies. Enable it in both at the same time.
• Liquid Glass breakage in custom tab bars: Any tab bar built using UITabBar.appearance() global mutations is likely to look broken on iOS 26. Move to per-instance configuration using the new UITabBarController appearance APIs.
• App Intent parameter type mismatches: The new domain-conforming intents have stricter parameter type requirements. Passing a custom entity where the domain expects a system entity type causes a silent fallback at runtime — test your intents in the Shortcuts app explicitly.
• Structured Output schema size: Apple's on-device model has a context limit. Very large @Generable types with many nested properties can cause the session to throw a context-length error at runtime. Keep your output schemas flat where possible.

The pattern of new platform APIs breaking existing UI customizations is a recurring theme — similar issues showed up when developers first adopted dynamic island APIs. If you're wondering how AI coding tools handle these kinds of beta-era surprises, the breakdown of where AI coding agents break down in production is relevant reading before you lean on them heavily for WWDC adoption work.

Wrapping Up: What to Ship Against Now

WWDC 2025 gave developers a lot to absorb. Here's how to sequence your work so you're not rewriting things twice.

1. Run your app on iOS 26 beta this week. Catch Liquid Glass visual regressions and deprecated API warnings before they become last-minute blockers at submission time.
2. Prototype one Foundation Models use case. Pick the lowest-risk feature in your app that involves short text generation or classification and replace it with an on-device LanguageModelSession call. Measure latency and accuracy against your existing solution.
3. Migrate at least one SiriKit Intent to App Intents. Even if you only move one intent this cycle, you'll understand the domain declaration model and be ready to move faster on the rest.
4. Enable Swift 6 language mode in a feature branch. Don't wait for a big-bang migration. Address the concurrency warnings incrementally and merge them over several weeks.
5. Audit your Live Activity update budget. If you're using push-to-update Live Activities, verify your server-side push frequency is within Apple's documented limits before iOS 26 ships to users — enforcement behavior can change with new OS versions.

The APIs that matter most this cycle — Foundation Models, App Intents domains, and the SwiftUI animation improvements — are stable enough to build against now. Start with the Foundation Models API if your app touches any text processing or content generation; the on-device privacy story alone is worth the migration conversation with your product team.