Wir leben wirklich in verrückten Zeiten. Neue KI-Tools und Ideen verändern die Arbeit von Entwicklern fast täglich – kaum habe ich Zeit investiert, meinen KI-Workflow zu verbessern, kommt schon das Nächste raus und lässt den gerade aufgebauten Workflow alt aussehen. Das ist das Gegenteil davon, wie sich Apple-Plattform-Entwicklung früher angefühlt hat. Neue Tools landeten traditionell in einer einzigen jährlichen Enthüllung, und die WWDC-Woche war für mich so etwas wie Weihnachten während der Arbeitszeit: gemütlich, planbar und aufregend.
Diese Gemütlichkeit bröckelt schon eine Weile. Open-Source-Swift, der Swift-Evolution-Prozess, Packages und Tools, die alle paar Wochen erscheinen, Swift on Android – all das hat das Geschehen Stück für Stück aus dem WWDC-Rahmen rausgeschoben. Aber so richtig aufgebrochen sind die Dinge mit ChatGPT und Claude Code. Ehrlich gesagt war ich KI-Tools in der Prä-Agent-Ära skeptisch gegenüber, als „KI für Entwickler” hauptsächlich Chat-Fenster und Autovervollständigung bedeutete. Das hat sich für mich irgendwann in den letzten zwölf Monaten geändert, und seitdem versuche ich herauszufinden, wie mein Entwicklungs-Workflow überhaupt noch aussieht. Wie viele andere auch.
Umso mehr habe ich mich gefreut, als Apple die WWDC26 für die Woche ab dem 8. Juni angekündigt und es klar formuliert hat: „unglaubliche Updates für Apple-Plattformen, einschließlich KI-Fortschritten und spannender neuer Software- und Entwickler-Tools.” Also habe ich mich hingesetzt und mich gefragt: Was sind die fünf Dinge, die nur Apple liefern könnte und die meinen Agentic-Engineering-Workflow am stärksten verbessern würden? Hier ist, was dabei rausgekommen ist.
ℹ️ Etwa 33 % der Punkte aus meinen früheren WWDC-Wunschlisten wurden tatsächlich umgesetzt. Zwei aus meiner WWDC24-Wunschliste sind irgendwann angekommen: Multi-Auswahl im String Catalog auf der WWDC25 und das neue
RenderPreview-Tool im Xcode-26.3-MCP-Server (mitten im Zyklus, im Februar). Apple liefert also – manchmal eben außerhalb des WWDC-Reveals.
#1 – Eine UI-Introspection-API auf LLM-Niveau
Wenn ich meinen Agent prüfen lassen will, ob ein Screen nach einer Code-Änderung wirklich richtig aussieht, habe ich heute zwei Optionen: Screenshots an ein multimodales Modell schicken (langsam, teuer, brüchig) oder den Accessibility-Tree per Peekaboo / xcodebuildmcp abfragen (besser, aber die AX-API wurde für Screen-Reader entworfen). Der AX-Tree sagt dir „das ist ein Button mit dem Label ‘Speichern’” – er sagt dir nicht, dass der Button 44pt hoch ist, einen Eckradius von 12 hat, in einem HStack mit 16pt Spacing sitzt, über eine 0,3-Sekunden-Transition eingeblendet wird und beim Tippen einen asynchronen Netzwerk-Call auslöst.
Xcodes View Debugger zeigt vieles davon schon. In einer laufenden App siehst du jeden View mit Frame, Modifier-Stack, Constraints, Layer-Properties und angehängten Gesture-Recognizern in strukturierter Form. Was fehlt, ist ein textueller, maschinenlesbarer Export dieser Daten. Stell dir vor, mein Agent könnte die laufende App fragen: „gib mir den vollständigen Layout-Tree als JSON, mit Größen, Farben, Gesten, Animationen und Async-Hooks an jedem interaktiven Element.” Klick-Intents werden deterministisch. Der Agent kann auf die richtige asynchrone Operation warten, statt zu pollen. Nach einem Tipp kann er das neue Layout lesen und mit dem erwarteten Zustand vergleichen – ohne jemals einen Screenshot zu machen.
Und wenn der Simulator Hot-Reloading bekäme wie SwiftUI Previews – und dieselbe Introspection-API auch von den Previews selbst bereitgestellt würde – würde der Iterations-Zyklus für menschliche und für agentengetriebene UI-Arbeit von Minuten auf Sekunden zusammenschrumpfen.
Der Accessibility-Tree ist die falsche Abstraktion für Agents. Er ist auf Screen-Reader-Nutzer optimiert, die linear navigieren. Agents müssen die echte View-Hierarchie ablaufen: klickbare Regionen, scrollbare Bereiche, Lade-States, Animations-Timing, Async-Hooks. Ein „Animationen für KI-Auswertung deaktivieren”-Toggle nur im Debug-Modus von Xcode würde Agents erlauben, eine ganze App in Sekunden statt Minuten zu erkunden. Und größer gedacht: Eine systemweite Variante dieser API – von jeder App bereitgestellt, nicht nur denen unter dem Debugger – würde Agents jede App auf dem System navigieren lassen, wobei Entwickler im Debug-Modus zusätzliche Goodies obendrauf bekämen.
Ich wünsche mir eine strukturierte Layout-/Style-/Gesten-API, an die Agents andocken können – plus einen „Animationen deaktivieren”-Debug-Toggle und dieselbe Oberfläche in SwiftUI Previews und im Simulator mit Hot-Reloading.
#2 – Eine Swift-DSL für intent-basierte UI-Flows
Ich gebe es zu: Ich schreibe keine UI-Tests. Null. CrossCraft, TranslateKit, Posters – keine davon hat UI-Tests. Jedes Mal, wenn ich es probiert habe – damals 2024 und davor – brachen sie beim nächsten Layout-Tweak, und ich verbrachte mehr Zeit damit, den Test zu reparieren, als den Bug, den er fangen sollte. Ich hab’s aufgegeben. Seither keinen einzigen mehr geschrieben.
Das Problem ist nicht das Testen – sondern das Verankern. Tests heute binden sich an Accessibility-IDs, Button-Labels oder Pixel-Positionen, also brechen sie alle, wenn man Next in Continue umbenennt oder durch ein Chevron-Icon ersetzt. Was ich eigentlich ausdrücken will, ist Intent: „tippe den Button, der zum nächsten Screen führt.” Ein Mensch, der das liest, weiß, was zu tun ist – egal, was draufsteht.
Wenn Wunsch #1 dem Agent eine strukturierte Sicht auf den Bildschirm gibt, gibt dieser hier dem Entwickler eine Swift-native DSL, um die Flows zu beschreiben, die der Agent durchlaufen soll. Eine kleine Markup-Sprache, von Apple entworfen, ausgedrückt durch dasselbe Macro-Toolkit, das uns @Observable, @Model und #Preview gegeben hat:
#UIFlow("Erstelle ein 9×9-Puzzle vom Home-Screen aus") {
action("ein neues Puzzle starten")
choose("9×9", from: "dem Grid-Größen-Picker")
action("Erstellung bestätigen")
wait("bis die Generierung abgeschlossen ist", timeout: .seconds(30))
expect("ein leeres 9×9-Puzzle-Grid wird angezeigt")
}Die Verben sind absichtlich intent-förmig. action("ein neues Puzzle starten") benennt nicht den Button – sondern das Ergebnis. Wenn ein Screen von mir keine eindeutige „neues Puzzle starten”-Affordance hat, ist das ein Usability-Bug, den der Test fängt, bevor er irgendwas anderes fängt: Ein LLM mit dem vollständigen Layout-Tree ist ein ziemlich guter Stellvertreter für jemanden, der die App zum ersten Mal ausprobiert. Findet der Agent keinen klaren Treffer, hat meine Informationsarchitektur wahrscheinlich ein Problem.
Und wie bei Performance-Baselines könnte das System beim ersten erfolgreichen Lauf einen Referenz-Snapshot persistieren – kein pixelgenauer Sollwert, sondern den Layout-State, den ich vorher abgesegnet habe. Bei jedem weiteren Lauf vergleicht der Agent: dieser State war gut, das ist der neue State, der User will „ein leeres 9×9-Grid” – war das in der Referenz wahr, ist es das jetzt noch? Genau die richtige Unschärfe für Tests, die nur dann fehlschlagen, wenn auch ein Mensch sagen würde: hier ist was kaputt.
Ich wünsche mir eine von Apple entworfene Swift-DSL, in der ich UI-Flows nach Intent beschreibe, Agents führen sie gegen die laufende App aus, und Referenz-Snapshots sagen dem Agent, ob das Layout noch zu einem von mir abgesegneten State passt.
#3 – Leistungsfähigere On-Device-LLMs
Von den fünf ist das der Punkt, den ich am liebsten gleich heute angehen würde. On-Device-LLMs gewinnen bei Privatsphäre, Latenz und Kosten, und ich würde meine externen API-Calls an Dutzenden Stellen liebend gerne dagegen austauschen. Aber SystemLanguageModel.default ist auf 4.096 Tokens Input + Output kombiniert gedeckelt – dasselbe Limit auf dem iPhone wie auf meinem 36-GB-M4-Max-Mac-Studio. Keine Möglichkeit, mehr Kontext anzufordern, kein Weg zu einem größeren Modell, und für den User auch keiner, sein eigenes mitzubringen.
Das ist eine doppelt vertane Chance. Auf dem Mac Studio liegen über 30 GB ungenutztes RAM, das das System nicht einsetzt, um mir eine bessere Antwort zu geben. Und Drittanbieter-Modell-Macher – Mistral, Qwen, wer auch immer nächstes Jahr ein starkes Swift-Coding-Modell mit 14B Parametern bringt – haben keinen Weg, sich an die System-Schnittstelle anzudocken, gegen die Apps schon heute bauen.
Was ich mir wünsche, ist eine anforderungsbasierte API. Zwei orthogonale Achsen, die der Entwickler an der Aufrufstelle ausdrücken können sollte:
Inferenz-Budget – wie viel Denkzeit kann sich dieser Call leisten? Eine Notiz zu kategorisieren muss instant gehen; ein langes Dokument zusammenzufassen darf ein paar Sekunden für einen gründlicheren Durchgang dauern.
Modell-Fähigkeit – wie leistungsstark muss das Modell sein? Einen Kalendereintrag zu taggen läuft auch auf dem kleinsten verfügbaren Modell; eine ausgefeilte E-Mail entwerfen oder über strukturierte Daten zu argumentieren will das größte, das das Gerät gerade noch ausführen kann.
Plus das Offensichtliche: das minimale Kontextfenster, das der Prompt tatsächlich braucht. Heute sieht die On-Device-API ungefähr so aus – sauber, aber an SystemLanguageModel.default gekoppelt:
let session = LanguageModelSession()
let response = try await session.respond(to: prompt)Stattdessen würde ich gerne die Anforderungen des Calls an der Session-Grenze deklarieren und das System das passende Modell aussuchen lassen:
let session = LanguageModelSession(
requirements: .init(
minimumContextTokens: 32_000,
capability: .high,
inferenceBudget: .relaxed
)
)
let response = try await session.respond(to: prompt)Das System gleicht diese Anforderungen mit dem ab, was tatsächlich verfügbar ist – welche Modelle installiert sind, wie viel RAM frei ist, wie ausgelastet die Neural Engine ist – und wählt aus. Es sollte außerdem Anfragen so queuen, dass der RAM nie überläuft: Ich habe meinen Mac Studio oft genug zum Absturz gebracht, weil ich zwei Modelle parallel laufen ließ, und Inferenz sollte nicht die eine Ausnahme sein, die ich von Hand koordinieren muss, wenn Swift async jede andere Ressource im System schon erledigt.
Was ich mir am stärksten von Apple wünsche, ist ein Bekenntnis zu nutzerinstallierten Drittanbieter-Modellen als First-Class-Konzept. Der User geht in Systemeinstellungen → Apple Intelligence → Installierte Modelle und wählt: Apples eigenes, Mistrals, einen Qwen-Coder-Fine-Tune – das, dem er vertraut und für das er Speicherplatz hat. Apps ändern keine einzige Zeile, weil sie mit dem System in Capability-Begriffen sprechen, nicht in Modell-Namen. Erfüllt das vom User gewählte Modell die Anforderungen, nimmt das System es; tut es das nicht, fällt es auf irgendein installiertes Modell zurück, das passt. Die App interessiert nicht, welches Modell den Call übernommen hat – nur, dass ihre Anforderungen erfüllt waren. Apple bleibt Herr über den API-Vertrag; der User bleibt Herr darüber, welches Modell auf seinem Gerät lebt.
Gleiches Thema: ein einziges systemweites Modell-Register. Ich habe heute das parakeet-tdt-0.6b-v3-Modell, das OpenWhispr verwendet, auf der Platte liegen – und zwei andere Transkriptions-Pipelines, die ich nutze, haben jeweils ihre eigene Kopie desselben Modells heruntergeladen. Bei einem Qwen-Modell dasselbe: LM Studio hat es, und ein separates Projekt von mir zieht sich seine eigene Kopie über die CLI runter, statt das schon vorhandene wiederzuverwenden. Das ist Chaos. Ein einheitliches Install-Register würde jeder App auf dem Mac erlauben, das schon Vorhandene zu finden und wiederzuverwenden, statt dass jedes Tool sein eigenes pflegt.
Und wenn wir schon dabei sind: bitte launcht in der EU am ersten Tag. 🙏
Ich wünsche mir eine anforderungsbasierte On-Device-LLM-API mit nutzerinstallierbaren Drittanbieter-Modellen, vom System verwaltetem RAM und Request-Queueing, einem einzigen geteilten Modell-Register – und EU-Parität ab Tag eins.
#4 – Ein headless Xcode für KI-Agents
Ich verbringe inzwischen die meiste Zeit damit, nicht Code zu schreiben. Ich schreibe Specs, reviewe PRs von meinen Agents und schaue, wie TestFlight-Builds auf meinem iPhone landen. Ich baue gerade eine Mac-mini-App, die meine Claude-Code- und Codex-Sessions über alle meine Projekte hinweg orchestriert – im Grunde das, was PlanKit und TandemKit heute machen, mit der Sandcastle-Idee einer Mac-App, die man von einer Companion-App fernsteuert – als native macOS-App verpackt, mit TestFlight-Beta-Auslieferung, sodass ich unterwegs reviewen kann. Der Mac mini steht da, Agents arbeiten autonom, und ich schaue mir das Ergebnis an, ohne je selbst Xcode zu öffnen.
In diesem Workflow muss ich Xcode selten sehen. Die IDE-Fenster, der Project Navigator, der Source-Editor – die sind nicht mehr für mich. Die sind für meinen Agent. Und mein Agent braucht keine Fenster; er braucht eine API.
Was ich wirklich will, ist ein Xcode Server in der Menüleiste: ein headless Build-Daemon, der die volle MCP-Oberfläche exponiert, Builds über mehrere Projekte hinweg plant (damit zwei große Swift-Compiles nicht um die Cores kämpfen), Derived-Data per Projekt auf Anforderung aufräumt und nie ein einziges Fenster öffnet. Stell dir xcodebuild --daemon vor, mit den smarten Teilen der IDE, aber ohne UI. Für Entwickler, die noch von Hand programmieren, bleibt das volle Xcode – aber für die unter uns, die Flotten von Agents über viele Apps hinweg dirigieren, würde ein fensterloses Xcode ernsthaft Ressourcen und Reibung sparen. (Ich werde das Build-Scheduling und die Derived-Data-Teile am Ende wahrscheinlich sowieso in meiner eigenen App umsetzen – aber eingebaut wäre es eben schöner.)
Ich wünsche mir einen headless, Agent-First-Xcode-Server, der in der Menüleiste lebt.
#5 – Ein neues Paradigma für LLM-natives Development
Hier ist der spekulative. Das letzte Mal, dass Apple Entwickler wirklich überrascht hat – die Art Ankündigung, die niemand auf dem Bingo-Zettel hatte – war SwiftUI 2019. Fast sieben Jahre her. KI-Agents sind die seismische Verschiebung dieser Generation in unserer Arbeit, und ich frage mich: Sind Swift und SwiftUI noch die richtigen Primitiven für diese neue Welt?
Vielleicht wären LLMs zuverlässigere Code-Generatoren, wenn die Sprache, für die sie generieren, mit ihnen im Kopf entworfen worden wäre – weniger mehrdeutige DSL-Fallen, mehr orthogonale Komposition, Layout und Verhalten in einer einzigen deklarativen Form ausgedrückt, die zugleich menschenlesbar und für Agents introspektierbar ist. Vielleicht ist es gar keine neue Sprache, sondern ein neues Paradigma, das ich mir noch gar nicht so richtig vorstellen kann. Was es auch ist – ich hoffe auf diesen Moment.
Apple hat mit dem „KI-Fortschritte”-Framing die Latte hochgelegt. Wenn das, was am Ende für Entwickler rauskommt, nur ein Gemini-getriebener Siri und kosmetische Polituren oder Bug-Fixes am Xcode-Coding-Assistant sind, ist das eine Enttäuschung. Zeigt mir, dass ihr die Plattform neu denkt.
Ich wünsche mir ein KI-natives Paradigma – den nächsten SwiftUI-Moment.
Fazit
Apple sitzt an einer seltenen Stelle – das Unternehmen kontrolliert das Silizium, das OS, die IDE, den App Store und das Modell. Fast jeder Wunsch auf dieser Liste ist etwas, das nur dieser integrierte Stack wirklich gut kann. Genau deshalb baue ich immer noch auf Apple-Plattformen, statt umzusteigen, und genau deshalb hoffe ich, dass die WWDC26 das Jahr wird, in dem Apple sich beim KI-Tooling voll auf diesen Vorteil stützt, statt es wie ein Bolt-on zu behandeln. Ich werde diese Liste während der Keynote offen haben.
Was steht auf deiner? Sag’s mir auf Bluesky oder Mastodon.
P.S. – Ich habe das nicht in die Top 5 aufgenommen, weil es sich eher wie ein Bug als wie ein Wunsch anfühlt, aber mein eigentlicher Spitzenplatz ist dieser Dialog:
Bitte, bitte, bitte hört auf, mir das 50-mal am Tag zu zeigen. In jeder. Einzelnen. Session. Wieder. Und wieder. Und für den Fix muss man auch nicht auf die WWDC warten. Schon mal vielen Dank im Voraus. 🤍 (Ich nutze diesen Workaround.)