- Bei Swift 6 und der aktuellen iOS-App-Entwicklung ist der Nutzen von LLM-basierten Tools deutlich geringer, wodurch sich gegenüber Android (mit Kotlin, Compose und Cursor) eine große Produktivitätslücke auftut
- Android-Teams können schnell entwickeln und aktuelle Funktionen auch auf älteren Betriebssystemen unterstützen, während iOS-Teams durch die neueste Swift-6-Syntax, Funktionseinschränkungen und mangelnde Framework-Unterstützung Produktivitätseinbußen sowie die Belastung einer Codebasis-Umstellung erleben
- Da LLMs das neue Concurrency-Modell und komplexe Muster von Swift 6 nicht verstehen, ist die Fähigkeit von LLMs zur Code-Automatisierung und -Beschleunigung eingeschränkt
- Die Einführung von Swift 6 selbst wird von einigen Entwicklerinnen und Entwicklern positiv bewertet, doch die mangelnde Kompatibilität mit LLM-Tools wird als Problem genannt
- Die Abwärtskompatibilität und entwicklerfreundliche Herangehensweise im Google-Ökosystem mit Android, Compose und Cursor treten deutlich hervor, während die Unzufriedenheit über das Tempo von Framework- und API-Updates bei Swift/Apple anhält
Entwicklungsproduktivität im Zeitalter von Swift 6 und LLMs
Wahrgenommene Produktivität bei iOS- vs. Android-Entwicklung
- Der Autor entwickelt in einem kleinen iOS-Team eine neue App mit Swift 6 und arbeitet parallel mit einem kleinen Android-Team
- Das Android-Team kann mit Kotlin, Compose und Cursor schnell entwickeln und aktuelle Funktionen unterstützen und deckt sogar Android 10 aus dem Jahr 2019 breit ab
- Das iOS-Team kann nur iOS 16 (2022) oder neuer unterstützen und erlebt mit der Einführung des aktuellen Swift 6 verschiedene Einschränkungen bei Funktionen wie Observable und Generic parameter packs
Das Missverhältnis zwischen Swift 6 und LLMs
- Die umfassenden Änderungen an Syntax und Frameworks in Swift 6 fielen zeitlich mit dem Aufkommen der LLM-Unterstützung zusammen, wodurch LLMs mit dem neuen Concurrency-System von Swift 6 nicht gut zurechtkommen
- LLM-Tools zur automatischen Code-Erzeugung oder für Vorschläge (z. B. ChatGPT, Claude, Cursor) haben Swift-6-bezogene Daten und Muster nicht ausreichend gelernt, was zu Grenzen bei der präzisen Code-Generierung führt
- Entwicklerinnen und Entwickler müssen Lücken, die das LLM nicht richtig versteht, manuell durch Kontext-Erklärungen, zusätzliche Regeln usw. ausgleichen → das führt zu Produktivitätseinbußen und wiederkehrender Arbeit
Meinungen und Erfahrungen aus der Community
- Einige iOS-Entwicklerinnen und -Entwickler äußern Neid auf die API-Abwärtskompatibilität von Android, die Reife von Compose UI und das Tool Cursor
- Es gibt zwar die Meinung, die Einführung von Swift 6 sei eine Fehlentscheidung gewesen, zugleich wird aber anerkannt, dass neue Muster und Lernaufwand nötig sind, und es gibt auch positive Bewertungen, wonach Ausdruckskraft und Qualität des Codes gestiegen sind
- Da Apples zentrale Frameworks noch nicht angemessen an das Swift-6-Concurrency-System angepasst wurden, berichten manche von Code-Komplexität und sinkender Produktivität durch die gemischte Nutzung mit GCD
- Einige Teams verschieben die Einführung von Swift 6 und lösen zunächst Kompatibilitätsprobleme mit der bestehenden Codebasis
Unterschiede zwischen dem Android- und dem Apple-Ökosystem
- Android stärkt die Produktivität von Entwicklerinnen und Entwicklern durch seine Backport-Politik für neue APIs und überwindet nach und nach langjährige Nachteile wie Fragmentierung und gerätespezifische Bugs
- Apple hingegen belastet Entwicklerinnen und Entwickler mit privaten/eingeschränkten APIs und langsamen Update-Richtlinien, sodass ähnliche Funktionen immer wieder selbst implementiert werden müssen
- Durch die Einführung von AI- und Automatisierungs-Tools wie Compose und Cursor verbessert sich die Produktivität der Android-Entwicklung noch schneller
- Bei iOS- und Swift-Entwicklerinnen und -Entwicklern häufen sich Fälle, in denen die schwierige Nutzung von LLMs zu Unsicherheit über Veränderungen bei Entwicklungstrends und die eigene Karriereposition führt
Fazit und praktische Implikationen
- Die Innovationskraft und Ausdrucksstärke von Swift 6 selbst werden hoch bewertet, doch wegen der Grenzen von LLM- und AI-Coding-Tools sind manuelle Arbeit und wiederholte Erklärungen vorerst unvermeidlich
- Für Projekte, die schnelle Entwicklung und die Nutzung aktueller Funktionen erfordern, ist die Produktivität der Kombination Android + Compose + Cursor überwältigend
- Solange Apple sein Ökosystem aus Frameworks und Tools nicht zügig aktualisiert, muss man bei der Einführung von Swift 6 Produktivitätseinbußen und Grenzen bei der LLM-Nutzung in Kauf nehmen
3 Kommentare
Im Großen und Ganzen stimmt das zwar, aber aus der Perspektive von jemandem, der lokale Modelle mit MLX kurz auf Apple-Silicon-Geräten ausprobiert hat, fällt es mir schwer, dem zu 100 % zuzustimmen.
Zur Info: Bei der Modellentwicklung gibt es auch die Belastung, auf mlx portieren zu müssen, und selbst wenn man mps aktiviert, fühlt es sich so an, als wären die Berechnungen nur geringfügig schneller als auf der CPU, daher ist es derzeit noch umständlich.
Ach … das tut weh, ein Volltreffer bis auf die Knochen …