Sharing what's confirmed from the WWDC26 ML labs, sub-question by sub-question — and flagging where Apple's direct answer is needed. Context window + overflow: On-device is 4096 tokens, shared between input and output. PCC is 32K. Overflow handling is developer-managed, not automatic — there's no silent truncation you can rely on. The framework added token-counting APIs (check context size, count tokens before sending) and the response reports input/output/cached token usage. Use those to chunk or summarize proactively. Guided generation / schema complexity: There's no published hard limit on nesting depth or enum/array/optional counts. The practical guidance from the labs was to keep schemas as flat and simple as the use case allows, since deeply nested structures are harder for the model to satisfy reliably. The failure mode is a generation error rather than silent malformed output. Best practice: validate the decoded result and be ready to retry. The exact complexity ceiling is something only the Foundation Models team can give definitively. Tool calling reliability: Tool calling is not guaranteed deterministic — the model can produce arguments that don't validate. The recommended pattern is to treat the tool boundary as a validation gate: check arguments inside your Tool implementation before acting, and either throw (letting the model retry) or repair to the nearest valid value. Don't trust raw tool arguments. Image input constraints: Passing images can change which tier services the request — worth testing whether your image prompts stay on-device or escalate to PCC, since that affects latency and the context budget. Exact resolution/count/format limits weren't given numerically in the labs, so that's one to confirm with the team. Version detection / drift: This is the hard one. Since the model ships and updates with the OS, drift between releases is real, and no model-pinning API was mentioned. The recommended mitigation is the Evaluations framework — build an eval set of your core cases and run it against each OS beta to catch drift before users do. Evaluation-as-regression-testing is currently the answer, not pinning. Latency / concurrency / background: From the labs — background inference works but can be rate-limited when the system is busy (a distinct error you can catch and retry). On Mac you're not rate-limited in the foreground. Keep work chunked so the system can pause/resume around thermal pressure. Realistic latency and safe multi-session concurrency limits are hardware-dependent and best confirmed directly. Net: context window, overflow, drift mitigation, and tool validation have clear working patterns today. The exact numeric limits (schema depth, image specs, concurrency ceilings) are worth getting from the Foundation Models team directly rather than inferring. — Divya Ravi, Senior iOS Engineer

The pattern that works today is wrapping your tools rather than intercepting at the framework level. Instead of looking for a framework-level interception hook, implement your Tool conformance so that the tool's call method is itself the approval gate. Inside it, before performing the actual work, run your validation/approval logic — check the arguments, apply your own repair if they're malformed, and either proceed, throw, or return a result that asks for confirmation. For dynamic approve/reject specifically: have the tool return a result indicating "needs confirmation" rather than executing, then surface that to the user, and on approval invoke the actual operation in a follow-up turn. This keeps the model from autonomously executing high-impact actions — the tool acknowledges but defers the real work behind your confirmation surface. For argument validation/repair before execution: don't trust the model's tool arguments blindly. Validate against your own constraints inside the tool, and if they're off, you can either throw (letting the model retry) or coerce to the nearest valid value. This is essentially defensive programming at the tool boundary. There isn't a first-class "intercept all tool calls" middleware in the framework that was surfaced at the labs — the tool boundary itself is currently the right place to put this logic. If you need it centralized across many tools, a small protocol wrapper that all your tools adopt gives you one place for the approval/validation logic. — Divya Ravi, Senior iOS Engineer

This is the gap everyone building on PCC needs answered. Based on what was discussed at the WWDC26 ML labs, here's the practical reality: When you cross the free PCC threshold, Apple hasn't published a paid fallback program — which means you can't rely on PCC scaling automatically for a commercial app at volume. The safe architecture today is to build the fallback in before you ship, not after you hit the limit. The pattern that holds up: abstract your inference behind a protocol so the model tier is swappable. Route to on-device first where the task allows it (free, no threshold), use PCC for the cases that genuinely need it, and have a third-party provider (via the Language Model protocol) configured as the overflow path for when you exceed PCC eligibility. The new Language Model protocol makes this swap close to a one-line change. The architectural principle: don't let PCC be a single point of failure your business depends on with no defined cost ceiling. Treat it as one tier in a routing strategy, not the foundation. I've actually been building exactly this routing layer as an open-source package — happy to share patterns if useful. — Divya Ravi, Senior iOS Enginee

This is one of the trickiest parts of incremental SwiftUI adoption. The core issue is that SwiftUI's NavigationStack and UIKit's UINavigationController each want to own the navigation stack — and they fight when nested. The best practice that holds up: pick one framework to own navigation at each level, never both in the same stack. If your app's shell is UIKit, keep UINavigationController as the owner and host SwiftUI screens in UIHostingController as pushed view controllers. Drive pushes from UIKit — don't put a NavigationStack inside a hosted SwiftUI view that's already inside a UINavigationController. For SwiftUI screens that need to push, use a coordinator pattern: the SwiftUI view calls back to the UIKit coordinator, which performs the push. If a section is fully SwiftUI, wrap that whole section in a single UIHostingController and let NavigationStack own everything inside it — don't push individual SwiftUI screens via UIKit within that section. The anti-pattern that causes the "bad fast" behavior is alternating: UIKit pushes a SwiftUI view, which has its own NavigationStack, which pushes another view that calls back to UIKit. Pick the owner per section and keep handoffs at clear boundaries. For state, use a shared coordinator/router object (observable) that both worlds read from, rather than letting each framework track its own path. — Divya Ravi, Senior iOS Engineer

For a new code editor on iOS 27, go with UITextView backed by TextKit 2 + the new viewport control delegate — not custom TextKit 1. The WWDC25 push toward TextKit 1 was because TextKit 2's viewport management wasn't flexible enough for gutter sync and precise line positioning. iOS 27's viewport control delegate fixes exactly that. Quick mapping: Line numbers/markers: use the viewport delegate to track visible line fragments, position a synced gutter view. NSTextLayoutFragment gives per-line geometry. Syntax highlighting: apply attributes via text storage, highlight incrementally on the visible range the delegate surfaces — not the whole document. Collapsible sections: TextKit 2's content storage lets you control which ranges lay out, instead of TextKit 1's manual range math. One caveat: confirm the specific delegate hooks meet your gutter-sync needs before committing — that's the part that historically forced people back to TextKit 1. — Divya Ravi, Senior iOS Engineer

It's tied to the SDK you compile against, not the runtime OS. Apps compiled against the iOS 27 SDK get Liquid Glass, and the compatibility flag is no longer respected for them. Apps still compiled against an older SDK keep the previous design on iOS 27, because the system keys design behavior off the linked SDK version. So: an older-SDK build from the App Store should still get the previous design on iOS 27. It's recompiling against the iOS 27 SDK that disables the opt-out and moves you to Liquid Glass automatically. Same pattern Apple has used for past major UIKit changes — gate on linked SDK so existing binaries don't shift under users, new builds adopt the new default. Worth confirming with a UIKit engineer here, but that's the established behavior. — Divya Ravi, Senior iOS Engineer

Existing intents will keep working, but App Schema adoption is what unlocks the full Siri AI experience. Your AppShortcutsProvider intents still work as they do today — phrase-based, usable in Shortcuts. But the new Siri AI capabilities (natural language without memorized phrases, on-screen awareness, personal context) flow through the schema-based intents and IndexedEntity content in the semantic index. For your case: Contacts probably maps to an existing schema. Tags and Visit Logs likely don't — so adopt IndexedEntity to get them into the semantic index even without a matching schema. On the 10-intent limit: that applies to AppShortcutsProvider phrases, not schema-based intents. Schema intents are discovered semantically, so they're not subject to that cap. — Divya Ravi, Senior iOS Engineer

Worth migrating — the difference is searchability vs. semantic reasoning. CSSearchableItem makes content findable by keyword. IndexedEntity contributes your entities to the semantic index that Siri AI actually reasons over — so Siri can understand and act on them conversationally, with attribution back to your app. Since you already maintain both CoreSpotlight items and App Entities, consolidating onto IndexedEntity removes the duplicate indexing path. For iOS 17 support: you'll need availability-gating — IndexedEntity for iOS 27+, your existing CoreSpotlight path as fallback. Not mapping to a schema domain doesn't block IndexedEntity — indexing works independently. — Divya Ravi, Senior iOS Engineer

No — Siri can still invoke your classic AppShortcutsProvider intents via phrase matching as it does today. What's schema-specific is the natural-language-without-phrases experience and on-screen awareness. Those flow through schema-conforming intents and entity mapping. So it's layered: schema intents get the full Siri AI semantic treatment, classic intents still work the established way. On-screen content gets passed to your intents through the View Annotations entity mapping — which needs schema or IndexedEntity adoption to work. — Divya Ravi, Senior iOS Engineer

My Take : this flag has almost no documentation, so sharing what's inferable from related APIs. Based on the naming convention alongside excludeCellularServices, excludeDeviceCommunications most likely scopes out traffic from device-to-device communication frameworks — things like AirDrop, Continuity features (Handoff, Universal Clipboard), and possibly Bluetooth-based device sync — from whatever filtering or tunneling context this flag applies to (network extension or VPN config, presumably). The practical reason this matters: if you're building a VPN or content filter and this flag isn't set correctly, you may inadvertently route or block local device-to-device traffic that users expect to bypass your tunnel entirely (like Handoff between their iPhone and Mac). Given how scant the docs are, this seems like a good candidate for a one-on-one with the Networking team if you can grab a slot — the behavior likely has edge cases around Continuity that won't be fully captured in a forum reply. — Divya Ravi, Senior iOS Engineer

This is a great catch — worth clarifying the distinction. The Swift rewrite mentioned in the State of the Union refers to the QUIC transport layer used internally by the system networking stack, not necessarily a drop-in replacement for the existing libquic that's been crash-prone for HTTP/3 adopters. These can be the same underlying implementation or a parallel new stack depending on how the migration is staged — worth confirming explicitly with the Networking team here since the messaging wasn't fully clear. For your immediate crash issue: if you've already filed feedback with a reproducible case, the most actionable workaround while this gets sorted is to scope HTTP/3 usage via URLSessionConfiguration — you can disable HTTP/3 negotiation per-session with assumesHTTP3Capable = false on specific session configs while keeping it enabled elsewhere, which lets you isolate the crashing code paths without abandoning HTTP/3 entirely. If the new Swift QUIC implementation is opt-in via a new URLSession flag in iOS 27, that would be the cleanest migration path — but I haven't seen that documented yet either. Following this thread for the answer. — Divya Ravi, Senior iOS Engineer

Technically compelling question — and on-device AI makes it more feasible than ever. A few thoughts as a fellow iOS engineer: The hardware capability is largely there. The Secure Enclave, Neural Engine, and on-device Foundation Models in iOS 27 could theoretically support continuous behavioral signal processing without any data leaving the device. Typing cadence, touch pressure patterns, accelerometer signatures during device handling — all processable locally. The privacy architecture Apple would need to solve is the binding problem: how do you continuously verify identity without creating a behavioral profile that itself becomes a privacy liability? A static biometric like Face ID is verified and discarded. A continuous behavioral model accumulates over time. Even on-device, that's a meaningful attack surface if the model can be extracted. The battery constraint is real but probably solvable — the efficiency cores on A18 and later handle continuous sensor sampling well. The Neural Engine inference cost for a lightweight behavioral model is manageable. My expectation: Apple's path here is more likely through passive signals that don't require a dedicated model — location consistency, usage pattern plausibility, paired device presence — combined with stepped-up authentication when anomalies are detected. That's closer to what they've already shipped with Stolen Device Protection than a full behavioral biometrics system. — Divya Ravi, Senior iOS Engineer

The password prompt during Secure Enclave PSSO registration is intentional by design — it's Apple's mechanism to verify the user's identity before binding the Secure Enclave key to their account. It's a one-time enrollment cost, not an ongoing authentication event. That said, there are two ways to reduce friction: First — pre-stage the registration silently via MDM before the user's first login. If you push the PSSO extension configuration via com.apple.extensiblesso payload with RegistrationToken pre-populated from your IdP, the password dialog can be pre-satisfied using SSO credentials the MDM already has. Check whether your IdP supports registration token pre-provisioning in their MDM integration. Second — if you're on Entra ID, the Microsoft Enterprise SSO plugin handles the Secure Enclave binding silently for Entra-joined devices when Company Portal is installed and the device is already registered. The password step is bypassed because Company Portal already holds the device registration credential. The password prompt being suppressed entirely without one of these flows isn't currently possible — it's a security boundary Apple has intentionally kept. — Divya Ravi, Senior iOS Engineer

Great context. Three things: Session cookies breaking SSO: The issue is ASWebAuthenticationSession relies on the system cookie store for session continuity. Session-only cookies don't persist between invocations, so each call looks like a fresh login to PingOne. Fix: move session state out of cookies entirely. Store the refresh token in Keychain with kSecAttrAccessibleAfterFirstUnlock and silently refresh without re-presenting the browser. Your custom framework already does the token exchange — just persist the refresh token there. SSO Extension with Intune: Microsoft ships an Enterprise SSO plugin that works with PingOne out of the box. Configure via MDM using the com.apple.extensiblesso payload — once deployed, every app gets silent SSO with no per-app code changes. Users authenticate once, all subsequent launches are silent. Workspace One supports the same via Hub integration, so you can pilot before the Intune migration completes. mTLS certificate popup: You can't suppress it on unmanaged devices — iOS requires explicit consent by design. On MDM-managed devices: provision the certificate via com.apple.security.pkcs12 MDM payload instead of bundling it in the app. MDM-provisioned certificates match domains silently without the selection UI. For proactive device integrity + longer session lifetime: combine with DCAppAttestService, pass the attestation result as a custom claim in your PingOne token exchange, and gate extended sessions on valid attestation rather than certificate presence alone. — Divya Ravi, Senior iOS Engineer

For enterprise with MDM, the answer is clear: ASWebAuthenticationSession + SSO Extension is the right stack, and MDM makes it cleaner not harder. The SSO Extension (ASAuthorizationSingleSignOnProvider) is exactly built for your use case — MDM can deploy the extension silently across all managed devices, and once it's in place, every app and Safari get SSO automatically without any per-app authentication code. That's your "stop implementing custom auth frameworks" goal solved. The key thing that trips people up with SSO Extension in enterprise: the extension must be installed on the device before your app tries to use it. With MDM this is straightforward — push the extension as a managed app first. Without MDM it's fragile. For the WKWebView history: Apple has been clear that WKWebView and UIWebView are wrong for auth flows because they can't share cookies with Safari or other apps. ASWebAuthenticationSession is the only correct approach for OAuth/OIDC flows — it shares the system cookie store and gets the SSO benefit automatically. Practical path forward: Use ASWebAuthenticationSession for any OAuth/OIDC flows Implement ASAuthorizationSingleSignOnProvider via your IdP's SSO extension Use MDM to deploy and configure the extension fleet-wide Most major IdPs (Okta, Azure AD, Ping) already ship SSO extensions — check if yours does before building custom What IdP are you using? That changes the specifics significantly. — Divya Ravi, Senior iOS Engineer