Ich war bei KI-Tools bisher eher zurückhaltend und habe Cursor nicht ausprobiert, als es gehypt wurde, weil mir unwohl dabei war, einer KI vollen Projektzugriff zu geben. Ich habe im Grunde auf Apples datenschutzfreundlichere Lösung gewartet. Aber als sich herausstellte, dass es sich einfach nur um ChatGPT (oder andere Modelle) handelt, dachte ich mir, dann kann ich genauso gut Drittanbieter-Tools ausprobieren. Also teste ich seit der WWDC Xcode 26 (Beta 5) gegen Cursor und Claude Code, um zu sehen, welches Tool mich produktiver macht.
Und ich bin ehrlich froh, dass Apple auf serverbasierte LLMs umgeschwenkt ist, statt nur auf lokale Modelle zu setzen. Nachdem ich inzwischen gesehen habe, wie großartig Claude Code mit dem richtigen Context Engineering sein kann, weiß ich, dass eine rein lokale Lösung Jahre gebraucht hätte, um brauchbare Qualität zu erreichen. Apple hat hier richtig entschieden, die ursprüngliche Swift-Assist-Idee zu verwerfen, aber sie hatten offensichtlich nicht genug Zeit, eine vollständige Lösung für das erste Release zu bauen. Als jemand, der dem Apple-Ökosystem für die Entwicklung treu ist, ist es frustrierend, solche offensichtlichen Lücken in einem potenziell großartigen Tool zu sehen. Zum ersten Mal in meiner 14-jährigen Entwicklerkarriere nutze ich Xcode also nicht mehr als meinen täglichen Begleiter.
Claude Code in Cursor fasst zusammen, welchen Kontext es dank Context Engineering hat.
Ich bin stattdessen dazu übergegangen, Claude Code in Cursors Terminal laufen zu lassen – so bekomme ich Cursors Editor-Awareness zusammen mit Claude Codes überlegenen Tools wie Websuche, Planungsmodus und dem großzügigen 5-Stunden-Nutzungsfenster. Ich setze voll auf das Chat-Interface und versuche, der KI durch umfangreiches Context Engineering (Richtlinien, Referenzdokumentation) beizubringen, wie sie guten Code schreibt. Xcodes KI-Integration hingegen – obwohl vielversprechend durch die native IDE-Position – fehlen grundlegende Features, die diese Art von KI-getriebenem Entwickeln produktiv machen.
Hier ist, was mich davon abhält, zurück zu Xcode zu wechseln.
Die 7 fehlenden Features in Xcode AI
1. Request-Queuing war die erste Einschränkung, die mir in Xcode sofort aufgefallen ist. Beim Entwickeln wechseln die Gedanken und Fragen schnell. Auf jede Antwort warten zu müssen, unterbricht meinen Rhythmus komplett. Eine der besten Möglichkeiten, bei der Arbeit mit KI Zeit zu sparen, ist vorauszudenken, während man wartet. Sowohl Cursor als auch Claude Code lassen mich nahtlos Anfragen anreihen und halten mich im Flow. Xcode blockiert einfach jede Eingabe.
Xcode 26 blockiert neue Chat-Eingaben, während die vorherige verarbeitet wird.
2. Context-Engineering-Unterstützung ist der Bereich, in dem Xcode komplett versagt. Es gibt keine Unterstützung für Kontextdateien wie .cursorrules oder CLAUDE.md. Ohne automatisches Laden von Kontext ist all die Arbeit, die ich in Context Engineering gesteckt habe – der KI meine Coding-Standards, Architekturmuster, Fehlerbehandlungsansätze und mehr beizubringen – in Xcode schlicht nicht möglich. Ich muss meine Richtlinien in jeder Unterhaltung aufs Neue erklären. Claude Code und Cursor laden automatisch meine übergeordneten Richtlinien und verstehen dann, wann welche detailliertere Richtlinie gelesen werden muss. Das verwandelt KI von einem generischen Code-Generator in einen tatsächlich nützlichen Assistenten. In Xcode leider nicht.
Der Coding Assistant teilt mir mit, dass es keine Möglichkeit gibt, ihm etwas über mein Projekt oder meine Richtlinien beizubringen.
3. Build-Validierung zeigt, dass Xcode nicht für KI-getriebene Entwicklung konzipiert wurde. Die KI kann ihre eigenen Codeänderungen nicht durch Builds validieren und hat nicht mal Zugriff auf die Build-Ausgabe, wenn ich sie selbst starte. Sie kann nicht mal die Konsolenausgabe lesen, wenn ich sie explizit darum bitte. Klar, Xcode erlaubt es, nach dem Build einen Fehler auszuwählen und die KI um eine Korrektur zu bitten – aber das ist für einen anderen Workflow gedacht. Es ist nur nützlich, wenn man selbst Code schreibt und einen Fehler macht, was selten vorkommt. Aber wenn die KI Code für mich schreibt? Build-Fehler treten ständig auf. Selbst bauen und dann manuell auf “Beheben” klicken zu müssen, ist super nervig. Die KI sollte einfach selbst bauen und die Fehler sehen können. Mit Claude Code lasse ich es einfach xcodebuild ausführen und die KI sieht alle Fehler sofort. Sie fragt mich zwar um Erlaubnis, aber wenn ich zustimme, kann sie iterieren, beheben und neu bauen, bis alles kompiliert – ohne manuelles Eingreifen.
Der Coding Assistant teilt mir mit, dass er die Konsolenausgabe nicht lesen kann.
4. Git-Integration fehlt komplett – kein Durchsuchen der History, kein Vergleichen von Versionen, keine automatisierten Commits nach meinen Richtlinien. Ich kann der KI nicht sagen, sie soll meinen aktuellen Code mit einer früheren Version vergleichen, um Dokumentationsdateien basierend auf den letzten Änderungen zu aktualisieren, oder funktionierenden Code aus früheren Commits zurückholen. Claude Code kann meine Git-History durchsuchen, funktionierenden Code aus früheren Commits wiederherstellen und ordentlich formatierte Commits erstellen, indem es die tatsächlichen Änderungen analysiert und eine passende Nachricht findet, die meinen Commit-Richtlinien folgt. Es kann sogar helfen, Dokumentation zu aktualisieren, indem es vergleicht, was sich seit der letzten Version geändert hat.
Der Coding Assistant teilt mir mit, dass er nicht auf die Git-History zugreifen kann.
5. Terminal- und CLI-Zugriff ist die größte Lücke. Kein Kommandozeilenzugriff bedeutet kein swift-format, keine eigenen Skripte, keine Automatisierung. Als Indie-Entwickler, der viele Aufgaben gleichzeitig jongliert, ist das eine ernsthafte Einschränkung. Ich kann der KI nicht beibringen, vor einem Commit einen Code-Formatter auszuführen, kann sie nicht meine Test-Suites starten lassen und keine der eigenen Skripte ausführen, die meinen Entwicklungsprozess beschleunigen. Claude Code führt jeden Terminal-Befehl aus, den ich brauche. Es formatiert Code vor Commits, führt meine Test-Suites aus, startet Deployment-Skripte, verwaltet Abhängigkeiten und übernimmt meinen gesamten Automatisierungs-Workflow. Ein einziges Terminal-Tool gibt Zugriff auf alles – git, xcodebuild, Paketmanager, was auch immer. Moderne KI kann das!
❇️ Wenn Apple allein den Terminal-Zugriff hinzufügen würde, wären die obigen Punkte 3 und 4 ebenfalls gelöst! Natürlich ist voller Kommandozeilenzugriff riskant. Aber Claude Code löst das elegant, indem es beim ersten Mal um Erlaubnis fragt und eine Allow- & Deny-Liste in einer einfachen Konfigurationsdatei unterstützt.
6. Projektdatei-Einschränkungen zeigen, dass Xcode nicht für moderne KI-Context-Engineering-Workflows ausgelegt ist. Viele Projekte erstrecken sich über mehrere Repositories – wie TranslateKit mit seiner App, dem Server und den Open-Source-Paket-Komponenten. Meine Context-Engineering-Richtlinien liegen im übergeordneten Ordner, der kein Xcode-Projekt enthält, und trotzdem brauche ich KI-Zugriff darauf über alle Komponenten hinweg. Wenn ich einen Ordner in Xcode ziehe, um ihn im Editor zu öffnen, bekomme ich nur einen Fehler. Xcode kann nur einzelne Textdateien, Xcode-Projekte oder Swift-Package-Manifestdateien öffnen – aber keine beliebigen Ordner. Außerdem werden Dotfiles versteckt, sodass ich Dinge wie GitHub Actions Workflows nicht sehen oder bearbeiten kann. Cursor dagegen öffnet jeden Ordner, zeigt versteckte Dateien an und funktioniert über meine gesamte Multi-Repo-Entwicklungsumgebung hinweg. Das sollte Xcode auch können!
Der Fehlerdialog, wenn ich versuche, einen beliebigen Ordner in Xcode zu öffnen.
7. Websuche und Dokumentationszugriff fehlen ebenfalls komplett. Die KI kann nicht mal in Xcodes eigenen heruntergeladenen Dokumentationsdateien suchen. Wenn ich aktuelle Informationen oder API-Referenzen brauche, bin ich auf mich allein gestellt. Claude Code hat eine eingebaute Websuche. Wenn ich nach den neuesten Swift-Evolution-Proposals oder neuen APIs frage, die auf der WWDC25 vorgestellt wurden, findet es einfach die Antwort. In Xcode 26 nicht.
Nach den neuen Frameworks gefragt, die Apple 2025 eingeführt hat, halluziniert es zu 100 %.
Diese sieben Einschränkungen ergeben zusammen ein grundlegendes Problem: Xcodes KI fühlt sich an wie eine Tech-Demo und nicht wie ein Produktivitäts-Tool. Jedes fehlende Puzzleteil zwingt mich zurück in manuelle Workflows, die Claude Code nahtlos erledigt.
Mein Fahrplan für Apple: 5 Release-Meilensteine
So könnte Apple diese Lücken schließen und mich 2026 zurück zu Xcode bringen:
Xcode 26.1 (Oktober 2025):
Fügt Request-Queuing und Kontextdatei-Unterstützung hinzu (z. B. Xcode.md). Diese Features sollten einfach zu implementieren sein und kein Risiko unerwünschter Nebeneffekte haben.
Xcode 26.2 (Dezember 2025):
Spezifische Tool-Integrationen für git, xcodebuild und swift-format. Da diese alle in Xcode integriert oder Apple-Technologien sind, können Apple-Ingenieure ihre bestehende Erfahrung nutzen, um diese Tools der KI mit sicheren, konservativen Aktionen bereitzustellen.
Xcode 26.3 (März 2026): Websuche, Integration der neuesten Dokumentation und Öffnen beliebiger Ordner mit Zugriff auf versteckte Dateien. Diese Integrationen sind alle risikoarm, brauchen aber Zeit, um sie richtig umzusetzen.
Xcode 26.4 (Mai 2026): Voller Terminal-Zugriff mit befehlsspezifischen Allow-/Deny-Listen.
Ich verstehe Apples Sicherheitsbedenken, aber Entwickler können mit der Verantwortung umgehen. Vertraut uns die Tools an, die wir brauchen, Apple, bitte!
Xcode 27 (September 2026, angekündigt auf der WWDC 26): Features, “die nur Apple bieten kann”, wie tiefe Simulator-Integration (stell dir vor, die KI navigiert durch deine App, um zu testen, ob ihre Änderungen wie erwartet funktioniert haben), oder SwiftUI-Preview-Zugriff (damit die KI sehen kann, wie ihr UI-Code aussieht). Vielleicht sogar ein “App Builder”-Modus, der SwiftUI zu einem sekundären Artefakt macht und App-Entwicklung einem ganz neuen Publikum zugänglich macht. Hier könnte Apple uns mit etwas überraschen, das wir nicht haben kommen sehen. Nicht nur “aufholen”, sondern die Konkurrenz wirklich übertreffen.
Das Fazit
Ich habe Xcode immer geliebt und möchte es ehrlich wieder exklusiv nutzen. Apple hat einzigartige Vorteile, die kein Wettbewerber bieten kann – nahtlose IDE-Integration, Simulator-Steuerung, SwiftUI-Preview-Funktionen. Aber im Moment ist Claude Code dramatisch leistungsfähiger, mit einem 5-fachen Produktivitätsunterschied. Aufgaben, die in Xcode Stunden dauern, erledigt Claude Code in Minuten – hauptsächlich weil es für einfache Dinge wie “Build drücken” nicht von mir abhängt.
Apple muss sich beeilen. Mit jedem Tag, der vergeht, etablieren mehr Entwickler tiefe Workflows mit anderen Tools. Ich werde jedes Point-Release gespannt verfolgen, und sobald Xcodes KI konkurrenzfähig wird, bin ich der Erste, der zurückkehrt. Bis dahin halte ich Claude Code in meinem Terminal offen und träume von dem Tag, an dem Xcode mich wieder umhauen wird und den Wandel zu einer AI-first-IDE schafft.
Wie sind eure Erfahrungen mit Xcodes KI-Integration? Habt ihr Workarounds für diese Einschränkungen gefunden, oder nutzt ihr auch Alternativen?