Siri Is Finally
Evolving toward
"Lobster AI."

This segment sets the interpretive frame for the entire event. Apple places the technologies, frameworks, and tools that developers use every day within the same platform roadmap conversation. Everything that follows returns to the question of how developers can make better apps.

The opening also places Liquid Glass and Apple Intelligence at the same level. This signals that Apple is handling AI, design, interface, and developer tooling simultaneously, and asking how apps can maintain their craft and domain expertise through all of it.

The three themes can serve as a reading map for this page: first, how intelligence enters apps; then, how platform UI, Swift, and SwiftUI make apps more adaptive; and finally, how Xcode 27 brings agentic coding into everyday engineering.

Apple positions Apple Foundation Models as the core of Apple Intelligence while emphasizing that third-party apps can also use them through the Foundation Models framework. This is platform strategy: packaging model capabilities into a developer-callable API.

The headline additions this year are image input and server models. Developers can use on-device models or reach for Private Cloud Compute or their own cloud provider when the task demands more.

The low-cost entry threshold for Private Cloud Compute is a significant signal about Apple's view of developer AI adoption barriers: it recognizes that model capability, privacy, cost, infrastructure, and distribution friction all matter. Actual terms should be confirmed in official documentation.

The Origami sample turns the Foundation Models framework from an API name into an understandable product flow. The user provides text, images, or material information; the app uses the model, Vision, translation, and generation to produce a workable origami tutorial.

The most important takeaway here is that AI is now embedded in the core task of an app. The model can be chained with images, text, OCR, barcode readers, guided generation, and tool calling into a complete workflow.

The video also shows that server models such as Claude and Gemini can be integrated via the Language Model protocol. This means Apple has left an open door at the framework level for model providers, so developers don't have to lock their entire AI architecture to a single model.

The concept behind Dynamic Profiles is that models, tools, and instructions can be swapped based on the task at hand. For apps, this is more like packaging different working modes as profiles rather than hardcoding a single fixed prompt.

Apple then introduces the Evaluations framework, Foundation Models instrument, FM CLI, Python SDK, and RAG tool. These fill in what's typically missing from AI engineering: testing, observability, debugging, data ingestion, and cross-language workflows.

Open-sourcing the Foundation Models framework and making it runnable on servers signals that Apple wants the same Swift APIs to cover both apps and servers. For Swift developers, this lays the groundwork for end-to-end AI workflows.

Core AI addresses a separate layer of need. Some tasks will use Apple Foundation Models; others require developers' own models, such as specialized vision, speech, classification, or LLM tasks running on-device.

The video mentions PyTorch conversion, optimization, ahead-of-time compilation, instruments, and a visual debugger. All of this points in one direction: Apple wants custom models to be part of the formal development toolchain, advancing from research models to verifiable app features.

The scenario range is wide, from small vision models on iPhone to multi-billion-parameter LLMs on Mac. When actually shipping, developers will need to weigh model size, device compute, latency, power, and privacy.

This App Intents segment is about how system intelligence understands an app. Developers must structure the app's content, entities, and actions so that Siri, Shortcuts, widgets, and Apple Intelligence can discover, understand, and invoke them.

In the Origami demo, the user asks Siri in natural language who's coming and what they're bringing, then directly triggers sending a message. This means app content is beginning to enter the system-level semantic index and action layer.

The View Annotations API adds screen-level operation. Users can say phrases like "the second message" or "this photo," and the system needs to map the visual elements on screen to entities and actions inside the app.

This segment closes the AI section. Apple organizes what developers can do into three categories: use Siri to enhance natural language experiences, use Foundation Models for generative features, and use Core AI to run custom models on-device.

These three layers represent different entry points. Siri and App Intents form the system integration layer; Foundation Models form the general-purpose model capability layer; Core AI forms the custom model deployment layer. Developers can choose based on their app's nature, and don't necessarily need all three.

The transition to design signals that once AI is inside an app, the interface, layout, readability, and developer tools also need to be revisited alongside it.

Liquid Glass 27 covers visual style, readability, depth, dark edges, highlights, background diffusion, and user adjustment between transparency and tint.

For developers, the implication is that apps using standard APIs will automatically benefit from more consistent sidebars, toolbars, scroll edges, icons, and window radii. That said, app identity and content readability still need to be checked independently.

It's also tied to accessibility. Settings like Reduce Transparency and Increase Contrast affect how the effect renders, so Liquid Glass can't be judged from static screenshots alone. It needs to be tested with real content and real user settings.

iOS app resizing is a practical platform change. An app can no longer assume it will always run in a fixed phone form factor, because iPad, Mac, and iPhone Mirroring will all place the same app in a more flexible space.

For existing apps, this is a checkpoint: navigation, sidebars, content density, forms, lists, and empty states all need to be revisited, or the app will just look like a magnified phone screen on a large display.

The value of the resizable simulator and Previews is that these issues become visible during development, rather than surfacing when a user encounters a broken layout on Mac or iPad.

This SwiftUI segment focuses on everyday UI problems: reorderable containers, swipe actions for arbitrary containers, text selection, toolbar control, and async image cache. None of these are high-concept, but they directly reduce the boilerplate in building apps.

Apple also notes that SwiftUI, AppKit, and UIKit are increasingly sharing foundations, so controls like menu pickers, nested stacks, and layouts benefit in terms of performance. This means the platform frameworks are converging toward more consistent infrastructure.

For developers, the key read here is not just what new modifier names are available, but which interactions that previously required custom code can now be delegated to the standard framework. That has a real impact on maintenance cost.

The document infrastructure update pulls common document-based app needs into SwiftUI. Undo, autosave, Quick Look, sharing, version browsing, and writing only changed parts all make it easier for document-type apps to follow the standard path.

The Spatial Preview framework puts 3D model previewing into the development loop. Mac apps can stream models into the surrounding Vision Pro space, bringing developers closer to the actual spatial experience when adjusting content.

This segment is less flashy than the AI sections, but it shows that Apple is still expanding SwiftUI's applicable domain: not just general app UI, but document-based apps and spatial computing content as well.

The claim in this Swift segment is clear: Apple is pushing Swift toward mobile apps, services, embedded firmware, servers, WebAssembly, and C++ and Java interoperability.

The video lists Apple's internal adoption of Swift across Foundation, UIKit/AppKit, WebKit, QUIC, TrueType, firmware, drivers, and kernel components. This uses their own adoption as the argument for Swift as a systems language.

For outside developers, this segment reads as a long-term signal: Swift's value includes its syntax, cross-platform reach, cross-layer applicability, and the ability to cross existing language boundaries into more engineering contexts.

Swift 6.4 leans more toward everyday developer efficiency than the earlier sections: completion, fix-its, diagnostics, API grouping, and automatic imports. These improvements affect how often developers are interrupted during a typical coding session.

The point of anyAppleOS availability is reducing the complexity of conditional checks when targeting multiple Apple platforms. When an app needs to simultaneously support iPhone, iPad, Mac, and Vision Pro, small changes like this accumulate into real maintenance cost differences.

This segment works well as a reminder in presentations: platform updates also include IDE and language experience improvements that help engineers guess less, look things up less, and fix fewer things.

Xcode 27 addresses daily experience before agentic coding, and the order matters. The IDE itself needs to be faster, more stable, and more personalizable before agents have a chance to become part of the daily workflow.

The video covers launch performance, crash and spin fixes, debugging reliability, a 30% smaller footprint, iCloud-synced settings, new project creation, customizable toolbars, themes, Xcode Cloud, and Device Hub. These are all friction points developers encounter every day.

Device Hub's significance is putting simulator and physical device management in one place, with support for live resizing, pinch to zoom, and sensor controls. This connects directly to the resizable app testing needs mentioned earlier.

Xcode agentic coding is designed so that agent conversations open like documents that can be split and stacked, signaling that they are treated as engineering artifacts.

/plan is the key feature. The agent explores the project first, understands its architecture and patterns, proposes a Markdown plan and diagram, and waits for developer review before implementing. This is closer to genuine team collaboration than directly generating code.

The second half of the demo shows the agent running the app, operating the simulator, testing UI, doing localization, analyzing crash logs, reproducing issues, and applying fixes. This means the agent's role extends from "writing" to "verifying" and "improving."

Xcode 27 ships with specialist skills covering SwiftUI, accessibility, universal sizing, testing, and performance. This means the agent isn't just a general-purpose model but can carry Apple engineering and design knowledge.

Plugins can include skills, MCP tools, and any agent via the Agent Client Protocol. This means Xcode is becoming an agent client that can connect to external tools and external agents.

Naming Figma and GitHub explicitly is a strong signal: design files, code, tests, and PRs that were previously scattered across separate tools will be easier for an agent to connect into a single flow.

The final segment adds Reality Composer Pro 3, Game Porting Toolkit, and Metal command line tools, showing that developer productivity extends beyond general apps and Xcode to spatial content, game porting, and command-line debugging.

The official summary returns to the main tracks: App Intents, Foundation Models, Core AI, Design, Swift and SwiftUI, Xcode agentic coding. This can also serve as the chapter list for a follow-up learning path.

The closing guides viewers to 100+ sessions, Group Labs, forums, Meet with Apple, and Developer Centers. A public page like this one should position itself as a guide, not a replacement for official documentation and sessions.