WWDC26 für Entwickler: Foundation Models, Core AI und ein agentisches Xcode
Die Platforms State of the Union ist die Entwickler-Variante der WWDC-Keynote. Weniger Bühne, mehr Frameworks. Dieses Jahr ordnet Apple alles in drei Blöcke: Apple Intelligence, Plattform-Verbesserungen und Entwickler-Produktivität. Der rote Faden durch alle drei ist derselbe wie im Vorjahr, nur deutlicher: generative Modelle rücken von der Demo ins Fundament der Entwicklung, und das Werkzeug, mit dem man sie verbaut, wird selbst agentisch.
Apple Intelligence: drei Wege zum Modell
Im Zentrum stehen die Apple Foundation Models. Bemerkenswert ist schon, wie sie entstanden sind. Apple formuliert es in der Session so:
Working together with Google and leveraging the technologies behind their Gemini family of models, we created the latest Apple Foundation models to power our Apple Intelligence experiences.
Diese Modelle laufen on-device und auf Private Cloud Compute. Wie genau die Gemini-Technik einfließt, stellt die Berichterstattung unterschiedlich dar. Mehreren Berichten zufolge fließt Gemini vor allem ins Post-Training ein, indem Apple seine eigenen Modelle mit Gemini-Outputs verfeinert, statt Gemini selbst in Produktion zu betreiben (AppleInsider, MacRumors, Juni 2026). Apple selbst nennt in der Session keine Details zur Trainingsmethode. Für Entwickler ist relevant, was die Frameworks darauf aufsetzen, und davon gibt es dieses Jahr drei Ebenen.
Das Foundation Models framework wächst
Das Foundation Models framework ist Apples native Swift-API auf das On-Device-Modell, das auch Apple Intelligence antreibt. Vergangenes Jahr eingeführt, bekommt es dieses Jahr drei spürbare Erweiterungen.
Erstens multimodale Prompts. Man hängt ein Bild an den Prompt, und das Modell versteht es. Dazu ist das Vision framework integriert, das dem Modell fertige Werkzeuge gibt, etwa OCR für präzise Textextraktion und Barcode-Reader, alles on-device.
Zweitens Server-Modelle. Reicht das lokale Modell für einen komplexen Workflow nicht, kann dieselbe API jetzt ein Cloud-Modell aufrufen, etwa Claude oder Gemini, mit Tool Calling und Guided Generation. Jeder Anbieter kann ein Swift-Package bereitstellen, das dem Language-Model-Protokoll entspricht, und man tauscht das Modell per Zeile aus. Apple verkauft das als Konsequenz: das Framework sei damit der beste Weg, irgendein Large Language Model in einer App laufen zu lassen.
Drittens ein Kostenmodell, das den Einstieg senkt. Entwickler mit weniger als zwei Millionen erstmaligen App-Store-Downloads dürfen die Apple Foundation Models auf Private Cloud Compute ohne Cloud-API-Kosten nutzen. Das ist Zugang zu Frontier-Intelligenz, ohne dass Infrastrukturkosten ein Prototyp-Projekt ausbremsen.
| Modell-Ebene | Wo es läuft | Typischer Einsatz |
|---|---|---|
| On-Device-Modell | lokal auf Apple Silicon | kleine, häufige Aufgaben, keine Serverkosten |
| Private Cloud Compute | Apple-Server, privat | komplexere Aufgaben, kostenfrei unter 2 Mio. Downloads |
| Server-Modelle (Claude, Gemini) | Drittanbieter-Cloud | Frontier-Aufgaben, Tool Calling, Guided Generation |
Dazu kommt Werkzeug drumherum: ein Evaluations framework zum Testen und Validieren von Prompts, ein aufgewertetes Foundation-Models-Instrument zum Debuggen des Modellverhaltens, ein FM-Kommandozeilen-Tool, ein Python SDK und ein RAG-Tool auf Basis von Core Spotlight, das privat zur App bleibt. Und der größte Punkt zum Schluss: Das Framework wird noch diesen Sommer quelloffen und läuft dann mit denselben Swift-APIs auch auf dem Server. Damit lässt sich ein durchgängiger KI-Workflow überall dort betreiben, wo Swift deployt wird.
Dynamic Profiles statt fester Sessions
Die interessanteste Neuerung im Framework heißt Dynamic Profiles. Bisher erzeugt man eine LanguageModelSession mit festem Modell, festen Tools und festen Instructions. Dynamic Profiles lösen das auf. Mit der vertrauten Swift-Result-Builder-Syntax definiert man mehrere Profile in einer Session, und der Body löst sich zu jedem Zeitpunkt zu genau einem aktiven Profil auf.
In der Demo betreibt eine Origami-App drei Profile in einer Session: ein Brainstorming-Profil auf Private Cloud Compute mit hoher Temperatur für Kreativität, ein Tutorial-Profil mit tiefem Reasoning für die schwierigste Aufgabe, und ein kleines Profil, das Fachbegriffe wie „valley fold" erklärt und dafür das On-Device-Modell nutzt, um Serveraufrufe zu sparen. Modelle, Instructions und Tools lassen sich im Lauf austauschen, aber alle teilen sich dasselbe durchgehende Transcript. Das ergibt mehr kontextbezogene Intelligenz bei weniger Prompting.
Der entscheidende Satz fällt am Ende der Demo: Die drei Profile sehen aus wie drei KI-Agenten, und genau das ist Absicht. Dynamic Profiles sind als anpassbare Bausteine gedacht, aus denen man Agenten, Skills oder beliebige höhere Abstraktionen bauen kann. Apple liefert dazu ein quelloffenes Swift-Package mit vorgefertigten Tools für Skills und Context-Management.
Core AI für eigene Modelle
Wer ein eigenes Modell mitbringt und on-device laufen lassen will, bekommt mit Core AI ein neues Framework. Die Fachpresse ordnet es als Nachfolger von Core ML ein (MacRumors, Juni 2026). Core AI ist direkt in die Plattform eingebaut und auf Apple Silicon optimiert, mit einer modernen, speichersicheren Swift-API und Tuning bis hinunter zu eigenen GPU-Kerneln. Python-basierte Tools konvertieren und optimieren PyTorch-Modelle für die Core-AI-Runtime, und eine neue Toolchain bringt Ahead-of-time-Kompilierung, eigene Core-AI-Instrumente und einen visuellen Debugger, der Tensor-Werte bis zum ursprünglichen Python-Quellcode zurückverfolgt.
Der Anspruch ist Skalierung über die Geräteklasse hinweg. Apple nennt zwei Pole: ein kompaktes Vision-Modell in einer iPhone-App für Echtzeit-Kameraabfragen, und am anderen Ende ein Multi-Milliarden-Parameter-LLM in einer Mac-App für einen agentischen Assistenten. Beides ohne Serverabhängigkeit und ohne Token-Kosten.
Für Enthusiasten, die Modelle trainieren, erforschen oder fine-tunen, bleibt MLX die Wahl. Apple bestätigt in der Session, dass MLX jetzt Metal 4 und die GPU Neural Accelerators unterstützt und Training über mehrere Macs per RDMA über Thunderbolt skaliert. Das ist genau der Mechanismus aus der eigenen MLX-Cluster-Session, nur hier als Einzeiler erwähnt.
App Intents bringt die App zurück zu Siri
Die zweite Hälfte von Apple Intelligence dreht sich nicht um Modelle in der App, sondern um die App im System. Über das App Intents framework wird eine App für Siri und die Systemintelligenz sichtbar. Zwei Schema-Typen tragen das: Entity-Schemas beschreiben die Inhalte und Konzepte einer App, Intent-Schemas ihre Aktionen.
Trägt man die Inhalte über IndexedEntity in den Spotlight-Semantik-Index ein und lässt die Entities einem Entity-Schema entsprechen, kann Siri über die App-Inhalte schließen. In der Demo fragt der Sprecher außerhalb der App „Hey Siri, who’s coming to origami night?", und Siri antwortet auf Basis der Nachrichten in der App. Über ein Intent, das dem sendMessage-Schema entspricht, wird der Fund dann handlungsfähig: Siri schreibt eine Antwort zurück. Die neue View-Annotations-API verbindet Views mit Entities, sodass Nutzer auf das verweisen können, was on-screen ist, etwa „die zweite Nachricht" oder „dieses Foto".
Weil die Schemas systemdefiniert sind, profitieren die Intents von künftigen Updates. Wächst Siris Sprachverständnis oder kommen neue Sprachen dazu, funktionieren die bestehenden Intents dort mit, ohne Code-Änderung.
Plattform: Liquid Glass, SwiftUI und Swift bis in den Kernel
Der zweite Block sind die Fundamente, auf denen Apps laufen. Wer mit dem neuen SDK neu baut, bekommt schnellere Starts und mehr Reaktionsfreudigkeit, ohne eigenes Zutun.
Das Design mit Liquid Glass aus dem Vorjahr wird verfeinert. Liquid Glass diffundiert komplexe Inhalte dahinter jetzt sauberer, eine abgedunkelte Kante und hellere Glanzlichter schaffen mehr Tiefe, und ein Slider in den Einstellungen erlaubt jede Abstufung von ultra clear bis fully tinted. Apps, die Liquid Glass bereits nutzen, bekommen diese Verbesserungen automatisch, ohne Neukompilierung. macOS 27 unterstützt nun den „show borders"-Wert wie iOS, Sidebars reichen bis an die Kanten, und Icons in der Sidebar bekommen ihre Farbe über den Akzentton der App zurück.
Ein praktischer Punkt für iOS-Entwickler ist Resizability. iOS-Apps erscheinen an immer mehr Orten, auf dem iPad und über iPhone Mirroring auf dem Mac. Dieses Jahr lassen sie sich dort in der Größe verändern. Nach dem Rebuild mit dem aktuellen SDK ist eine App automatisch dafür angemeldet. Wer SwiftUI, Auto Layout oder Size-Class-Änderungen nutzt, ist nahe dran. Für eigene Views gibt es einen resizable iOS-Simulator, Previews über viele Bildschirmgrößen und einen Skill für Coding-Agenten, der typische Resizability-Probleme findet und behebt.
SwiftUI: weniger Code, mehr Tempo
SwiftUI bekommt das übliche Jahres-Paket aus Interaktionen, Geschwindigkeit und neuen Fähigkeiten. Bei den Interaktionen fallen drag-to-reorder und Swipe-Actions auf. Was früher viel Code war, ist jetzt .reorderable() am ForEach und .reorderContainer() am Parent, und das funktioniert in jedem Container, nicht nur in Listen. Swipe-Actions gibt es analog über .swipeActions() plus .swipeActionsContainer().
Beim Tempo zählt vor allem, was automatisch passiert. SwiftUI, AppKit und UIKit teilen sich zunehmend ein gemeinsames Fundament, sodass Verbesserungen überall greifen. Verschachtelte Stack-Layouts skalieren bis zu doppelt so schnell, weil unnötige Mehrfachmessungen wegfallen. State wird jetzt nur noch beim ersten Laden initialisiert, weil State intern lazy ist und von einer Dynamic Property zu einem Macro wurde. AsyncImage cached über Standard-HTTP-Caching, lädt Bilder also nur einmal.
| SwiftUI-Neuerung | Was sie bringt |
|---|---|
.reorderable() / .reorderContainer() | Drag-to-reorder in jedem Container, ohne viel Code |
Lazy State (jetzt Macro) | keine überflüssigen State-Objekt-Instanzen mehr |
AsyncImage HTTP-Caching | Bilder werden einmal geladen, nicht wiederholt |
| Document-Infrastruktur | partielles Lesen und Schreiben großer Dateien |
visibilityPriority / Overflow-Menü | Toolbars reflowen geordnet bei dynamischen Größen |
Bei den neuen Fähigkeiten stechen zwei heraus. Die neue Dokument-Infrastruktur gibt dokumentbasierten Apps First-class-Zugriff auf die Datei-URL, sodass sich nur die benötigten Teile einer Datei lesen und nur die geänderten Stücke schreiben lassen, nicht die ganze Datei. Und das Spatial Preview framework erlaubt Mac-Apps, ein 3D-Modell beim Streaming auf eine Apple Vision Pro räumlich werden zu lassen.
Swift 6.4 und ein Stück Kernel in Swift
Swift 6.4 zielt auf den Alltag. Warnungen lassen sich in einzelnen Code-Teilen unterdrücken und an anderer Stelle zu Fehlern hochstufen. Statt jede Apple-Plattform mit derselben Versionsnummer aufzulisten, genügt jetzt anyAppleOS. Die Einschränkung für async-Aufrufe in einem defer-Block fällt weg. Und der berüchtigte Fehler „The compiler is unable to type check this expression in reasonable time" trifft in vielen Fällen nicht mehr zu, weil der Code entweder durchkompiliert oder eine konkretere Fehlermeldung liefert.
Hinter den Sprach-Updates steht eine größere Bewegung. Apple schreibt eigene Schichten zunehmend in Swift. Die TrueType-Font-Engine ersetzt jahrzehntealten, handoptimierten C-Code durch Swift, das nicht nur speichersicher, sondern schneller ist. WebKit ersetzt sicherheitskritische C++-Komponenten inkrementell durch Swift. Die QUIC-Transportschicht wurde in Swift neu geschrieben und wird noch diesen Monat quelloffen. Und für die 27er-Releases beginnt Apple, Teile des Betriebssystem-Kernels in Swift zu schreiben. Swift ist damit nicht mehr nur die App-Sprache, sondern reicht bis aufs Bare Metal.
Ein Schnitt gehört dazu. macOS Tahoe war die letzte Version mit Intel-Support, die Migration zu Apple Silicon ist abgeschlossen. Das erlaubt Apple-Silicon-only-Binaries im Mac App Store, kleinere Downloads und Tests auf einer einzigen Architektur. Parallel entfällt die Möglichkeit, das alte Design zu erzwingen. Sobald eine App mit Xcode 27 neu kompiliert wird, nutzt sie automatisch Liquid Glass.
Xcode 27: agentisches Coding im Zentrum
Der dritte Block ist die Werkbank. Xcode hat dieses Jahr zwei Geschichten: das tägliche Gefühl und die Intelligenz.
Beim Alltag ist Xcode 27 dreißig Prozent kleiner, Apple-Silicon-only, und lädt Agenten, Dokumentation und weitere Komponenten im Hintergrund nach. Die Einstellungen synchronisieren über iCloud, inklusive Git-Konfiguration. Ein neues Projekt ist sofort offen, ohne Dateiname, Bundle-ID oder Setup, das alles lässt sich später nachholen. Die Toolbar ist anpassbar, und Themes ziehen Farbe durch die ganze App statt nur durch den Editor, pro Projekt verschieden. Spürbarer ist der neue Device Hub, der den Simulator ersetzt und mehr kann: Geräteeigenschaften wie Dark Mode oder Schriftgröße zur Laufzeit ändern, dynamisch in der Größe verändern, und physische Geräte aus derselben Oberfläche steuern. Xcode Cloud baut bis zu doppelt so schnell und unterstützt jetzt Apple Vision Pro und Metal-Apps.
Der eigentliche Sprung liegt in der agentischen Entwicklung. Agenten sind in jede Schicht von Xcode eingewoben und bekommen Werkzeuge, um ihre Arbeit zu prüfen: Tests laufen lassen, Ideen isoliert in Playgrounds testen, Previews in hell und dunkel und über Lokalisierungen prüfen. Neu ist, dass ein Agent die App im Simulator selbst bedienen kann, also tippen, wischen und Text eingeben, und am Ende einen Testbericht mit Screenshots liefert.
Der Demo-Workflow zeigt den Bogen. Der Sprecher beschreibt ein Feature, hängt /plan an den Prompt und bittet um ein Diagramm. Der Agent erkundet das Projekt mit Xcode-Werkzeugen, stellt Rückfragen, legt einen Plan in gerendertem Markdown neben der Konversation an, der sich review- und verfeinern lässt. Erst danach wird Code geschrieben. Dieselbe Maschinerie lokalisiert die App ins Französische, kontextbewusst statt Wort für Wort, und zieht über den Organizer die häufigsten Crashes der letzten Version, reproduziert einen, behebt ihn und validiert den Fix.
Den Unterbau bilden Plugins. Xcode 27 bringt das Wissen von Apples Ingenieuren und Designern als Korpus aus Skills, Dokumentation und MCP-Tools mit, gedacht als Spezialisten, etwa für SwiftUI, Accessibility oder Performance. Eigene lassen sich im selben Format hinzufügen. Ein Plugin kann Skills enthalten, also Markdown-Dateien, die dem Agenten neue Aufgaben beibringen, dazu Tools über das Model Context Protocol. Neu ist, dass ein Plugin über das Agent Client Protocol einen Agenten eigener Wahl mitbringen kann. Xcode integriert bereits Agenten von Anthropic, OpenAI und jetzt Google, und ACP-Unterstützung plus Gemini-Integration kommen schon in einem Xcode-26-Update, das am selben Tag erscheint.
Fazit
Drei Entwicklungen prägen die diesjährige State of the Union. Erstens entkoppelt Apple das Framework vom Modell. Foundation Models spricht on-device, Private Cloud Compute und Drittanbieter wie Claude oder Gemini über dieselbe Swift-API an, und Dynamic Profiles machen den Wechsel zwischen ihnen zur Laufzeit zum Normalfall. Wer eine KI-Funktion baut, wählt das Modell nach Aufgabe, nicht umgekehrt.
Zweitens wird Swift zur durchgehenden Sprache, von der App-Oberfläche bis in den Kernel, und das Foundation Models framework folgt nach, indem es quelloffen wird und auf dem Server läuft. Das ist die konsequente Fortsetzung einer Linie, die Apple seit Jahren zieht.
Drittens ändert sich die Arbeit in Xcode selbst. Xcode 27 behandelt den Agenten nicht als Beiwerk neben dem Editor, sondern als Akteur, der plant, baut, testet und Fehler behebt, gestützt auf Swift und die Apple-Frameworks. Dass Apple dafür offene Protokolle wie MCP und ACP übernimmt, statt einen geschlossenen Eigenweg zu gehen, ist die eigentliche Nachricht für alle, die heute schon mit Coding-Agenten arbeiten. Die Demos sind Demos, und wie gut der agentische Alltag wirklich trägt, zeigt erst die Praxis. Aber die Richtung ist eindeutig, und sie deckt sich mit dem, was außerhalb von Apples Garten längst Alltag geworden ist.
Für mich bleibt Xcode die beste IDE für Apple-Plattformen und erste Wahl überall dort, wo ich nicht ohnehin mit Neovim und Claude Code im Terminal arbeite. Zu hoffen bleibt nur, dass es geschlossen genug bleibt, um nicht in derselben sicherheitstechnischen Extension-Hölle zu landen wie VS Code.