WWDC 2026: ein gutes Jahr für alle, die On-Device-KI entwickeln

Mit KI entworfen; von mir recherchiert, redigiert und auf Fakten geprüft — wie ich schreibe.

Das Jahr, in dem der ganze Stack in Bewegung kam

In den meisten Jahren tut sich auf der WWDC bei ein oder zwei Themen, die mir wichtig sind, etwas. Der Rest bleibt stehen. 2026 war anders: Modelle, Runtime, Auslieferung, App-Layer und die Tools, in denen ich das alles baue, haben in derselben Woche einen Sprung gemacht. Wenn das eigene Produkt komplett auf On-Device-KI auf Apple Silicon setzt, kann eine WWDC kaum besser laufen.

Hier also mein Rundgang durch die Ankündigungen der diesjährigen Konferenz, die für meine Arbeit relevant sind, und warum ich trotz Vorbehalten optimistisch aus der WWDC-Woche gegangen bin. Die Betas sind jetzt verfügbar; für alle verfügbar wird das Ganze diesen Herbst.

Die Modelle sind reifer geworden

Beim Foundation Models Framework hat sich dieses Jahr am meisten getan, und fast alles läuft auf dasselbe hinaus: mehr Auswahl, weniger Verdrahtung.

Es gibt jetzt ein öffentliches Protokoll. Eine einzelne LanguageModelSession kann damit wahlweise das On-Device-Modell, Apples größeres Modell in Private Cloud Compute, ein heruntergeladenes MLX-Modell oder — über Swift-Pakete von Anthropic und Google — Claude und Gemini verwenden. Das On-Device-Modell akzeptiert jetzt Bilder als Eingabe, und das Framework bringt integrierte Tools mit, die das Modell aufrufen kann: OCR, einen Barcodeleser und ein Spotlight-gestütztes Such-Tool für komplett lokales Retrieval.

Hängen geblieben bin ich vor allem an Private Cloud Compute. Das ist jetzt für Entwickler verfügbar — ohne API-Key, den man speichern muss, und für kleinere Entwickler innerhalb von Limits kostenlos. Zwei Jahre lang war mein mentales Modell strikt binär: entweder ein kleines Modell auf dem Gerät des Nutzers oder mein eigener Cloud-Service, mit den Keys und der Rechnung, die dazugehören. Eine datenschutzfreundliche Zwischenstufe, die ich nicht selbst bauen muss, ist wirklich willkommen, solange ich in der UI klar mache, was lokal läuft und was nicht.

Eine schnellere Runtime mit größerer Reichweite

Darunter liegt MLX, die Runtime, die ich für mein ausgeliefertes 3B-Modell nutze. Sie ist dieses Jahr schneller geworden: Metal 4-Unterstützung, GPU Neural Accelerators und Training, das über Thunderbolt auf mehrere Macs skaliert. Eine Runtime, die ich in Produktion nutze und die ohne Arbeit meinerseits schneller wird, nehme ich gern mit.

Spannender finde ich die größere Reichweite. MLXLanguageModel verbindet den gesamten mlx-community-Katalog auf Hugging Face — Tausende vorquantisierte Modelle — mit derselben Session-API. Früher bedeutete ein Modell-Prototyp, erst einmal eine Runtime zu verdrahten; heute reicht fast schon ein anderer String. Das spart genau dort Zeit, wo es rein ums Experimentieren geht.

Messen, was ich früher von Hand geschätzt habe

In meinen Runtime-Praxisnotizen habe ich zwei leicht peinliche Gewohnheiten eingeräumt: Tokens von Hand durch das Chat-Template zu zählen und nie eine exakte Verarbeitungszeit festgenagelt zu haben. Dieses Release räumt beides eher nebenbei auf. Das Framework stellt contextSize und tokenCount(for:) bereit, und Antworten enthalten jetzt einen usage-Wert — inklusive der Information, wie viele Eingabe-Tokens aus dem Cache kamen und wie viele Ausgabe-Tokens fürs Reasoning verbraucht wurden. Genau diese Messgröße hatte ich bisher in Log-Zeilen nur angenähert.

Außerdem gibt es ein neues Swift Evaluations Framework, um Feature-Qualität zu quantifizieren und Regressionen zu erkennen, wenn sich Prompts ändern. Das war für mich die auffälligste Ankündigung. Ich hatte für die Pipeline von Narration Room bereits einen DSPy-inspirierten Tuning-Harness gebaut: Golden Fixtures halten pro Pipeline-Stufe Eingabe, erwartete Ausgabe und Schwellenwerte fest; jede Stufe wird bewertet und mehrfach ausgeführt, damit ich die Run-to-Run-Varianz sehe; und ein Vergleichsschritt markiert, wenn eine Prompt-Änderung eine Metrik unbemerkt verschlechtert. Apples Framework deckt die Messseite derselben Idee ab, nur jetzt als First-Party-Werkzeug. Mein eigener Harness geht noch einen Schritt weiter und optimiert auch — ein Teacher-Modell schlägt Prompt-Umschreibungen vor und behält nur die, die besser abschneiden — was Apple nicht ausgeliefert hat. Dass Apple jetzt ein eigenes Framework in dieser Form liefert, ist beruhigend; es spricht dafür, dass ich auf einem vernünftigen Weg war und nicht nur meiner eigenen Vorliebe gefolgt bin.

Gezieltere Auslieferung

Ein mehrere Gigabyte großes Modell auszuliefern ist ein eigenes Problem, wie ich in einem früheren Artikel ausführlich beschrieben habe. Dieses Jahr bringt iOS 27 lokalisierte asset packs für Managed Background Assets, sodass ein Nutzer nur das herunterlädt, was für seine Sprache nötig ist, statt den gesamten Download. Meine eigenen Modelle sind nicht nach Sprache aufgeteilt, daher passt es für meinen Fall nicht perfekt. Aber kleinere, gezieltere Downloads sind genau das, worüber ich ohnehin schon nachgedacht hatte. Gut zu sehen, dass Apple sich in diese Richtung bewegt.

Ein angenehmerer App-Layer

Hier geht es um die kleinen Verbesserungen, die sich am Ende summieren. In SwiftData ist @Attribute(.codable) jetzt ein offiziell unterstützter Weg, einen Codable-Werttyp direkt zu persistieren, ohne daraus eine eigene Entity machen zu müssen — genau der Ausweg, den ich gesucht hatte, um einen strukturierten Wert neben dem Datensatz zu speichern.

SwiftUI hat eine Reihe von Quality-of-Life-Änderungen bekommen: Liquid Glass-Feinschliff, den bestehende Views automatisch ohne zusätzlichen Code übernehmen, einen reorderable()-Modifier für Drag-to-reorder, AsyncImage mit integriertem Caching und feinere Kontrolle über Toolbars bei wechselnden Interface-Größen. Für sich allein ist nichts davon eine Schlagzeile. Zusammen nehmen diese Änderungen aber eine Reihe kleiner Ärgernisse aus dem Alltag — und genau dadurch fühlt sich die Arbeit an der App leichter an.

Ein echter Weg zur Auffindbarkeit

Das beobachte ich mit Interesse. App Intents haben App Schemas und Entity Schemas bekommen, mit denen eine App eigene Inhalte zum semantischen Spotlight-Index beitragen und Aktionen in natürlicher Sprache für Siri und Apple Intelligence verfügbar machen kann. Für eine App, deren Kern das Material ist, das ein Nutzer erstellt, ist ein unterstützter Weg, diese Inhalte außerhalb der App durchsuchbar und per Aktion erreichbar zu machen, genau die Art von Fähigkeit, die ich gern auf der Plattform sehe. Ich verspreche hier nichts; ich halte nur fest, dass dieser Weg jetzt dokumentiert ist.

Die Tools sind dort angekommen, wo ich arbeite

Xcode 27 war der Teil, von dem ich wenig erwartet hatte und der mich angenehm überrascht hat. Die wichtigste Änderung für meine Arbeitsweise: Coding Agents laufen jetzt direkt im Editor. Die Konversation sitzt in einem Editor-Bereich neben Ihrem Code, ein /plan-Befehl sammelt Kontext, bevor der Agent Änderungen vornimmt, und der Agent kann Sub-Agents starten, die parallel den Code untersuchen. Ich arbeite ohnehin jeden Tag mit Coding Agents; für mich ist es deshalb eine echte Verbesserung, dafür nicht mehr in ein separates Fenster wechseln zu müssen.

Zwei weitere Änderungen passen direkt zu meinem Workflow. Für Lokalisierung gibt es jetzt einen Agenten, der Ihren Code liest und einen String Catalog einrichtet, zusammen mit einem Generate Translations-Button, der Projektkontext und sprachspezifische Stilvorgaben nutzt. Ich veröffentliche auf Englisch, Französisch und Deutsch, daher begrüße ich das — auch wenn ich alles, was veröffentlicht wird, weiterhin von Hand durchgehe, weil Tonalität über drei Sprachen hinweg eine Frage menschlicher Urteilskraft bleibt. Der neu gestaltete Organizer ergänzt außerdem eine Speichermetrik, die aufschlüsselt, wie viel Platz eine App und ihre Daten auf dem Gerät belegen. Wenn eine App Gigabytes an Modellgewichten herunterlädt, will ich genau wissen, wo der Speicher bleibt. Das ist kein Luxus.

Diktierfunktion und Stimmen

Spracheingabe und Stimmen haben dieses Jahr deutlich mehr Aufmerksamkeit bekommen. iOS 27 führt eine intelligentere systemweite Diktierfunktion ein, die in die Tastatur integriert ist — sie kümmert sich um Interpunktion, Großschreibung und Korrekturen, während Sie sprechen — und Siris Stimme klingt natürlicher; Tempo und Ausdruck lassen sich anpassen. Der Haken liegt bei der Hardware: Die leistungsfähigere Diktierfunktion und die ausdrucksstärkeren Stimmen nutzen ein größeres On-Device-Modell, das ein aktuelles Gerät mit ungefähr 12 GB Unified Memory braucht. Sie sind also auf die neuesten iPhones, iPads und Macs beschränkt.

Für Entwickler, die mit Sprache arbeiten, ist das Bild nüchterner. Das sind System- und Consumer-Features — eine bessere Tastatur, eine natürlichere Siri-Stimme — und nicht etwa ein neues Speech framework, das man direkt aufrufen könnte. Die Developer-Session mit Sprachbezug behandelte dieses Jahr generierte Untertitel, die auf derselben On-Device-Transkription aufbauen, statt eine neue API einzuführen. Meine eigene Transkription baut weiterhin auf dem SpeechAnalyzer vom letzten Jahr auf, und ich liefere weiterhin meine eigene Synthese aus, statt die Systemstimmen zu verwenden. Für Nutzer ist bei Sprache also viel passiert; aus Entwicklersicht war es ruhiger.

Worauf es hinausläuft

Mit etwas Abstand ist das Thema schwer zu übersehen: Die Plattform bewegt sich in Richtung der Anwendungen, die ich ohnehin baue — On-Device zuerst, flexibel bei den Modellen, datenschutzbewusst, mit Runtime, Auslieferung und Tooling, die gemeinsam besser geworden sind. Ein guter Teil der Infrastruktur, die ich von Hand gebaut hatte, hat jetzt ein offizielles Gegenstück. Das ist nichts, was man bedauern müsste. Es ist das Nützlichste, was eine Plattform tun kann: die mühsame Arbeit übernehmen, damit ich meine Zeit in die Teile stecken kann, die wirklich meine eigenen sind.

Wie es weitergeht

Wenn Ihnen solche Praxisnotizen helfen, ist der Newsletter der beste Weg, die nächste nicht zu verpassen.