Corrado
Daring FireballSwift 6 Productivity in the Sudden Age of LLM-Assisted Programming
https://daringfireball.net/linked/2025/06/07/swift-6-llms
https://daringfireball.net/linked/2025/06/07/swift-6-llms
Ilter Cengiz@daringfireball although I agree with the points related to Swift 6 and LLMs, even if one is using Swift 5, there is still a big gap of productivity when it comes to building apps for iOS and for Android (with Compose + Kotlin) Google is hugely helping their developers by making sure whatever next version of Android brings to be usable on devices and OS versions as old as 2019. This is the fact without LLMs even.
@daringfireball SwiftUI made it worse. Now we are stuck with a bug that is fixed on iOS 18, but we still support 16 for example. If this was on Android, all we had to do was to bump the Compose version we are using and ship an update. I’m experiencing this first hand myself as a decade plus iOS app developer and the fact that Apple is this much behind when it comes to developer experience is shameful to say the least.
Sören@ilter @daringfireball I would imagine
• Swift being AOT-only (vs. Kotlin being JIT), leading to a much slower edit, compile, debug cycle
• no Hot Reload support for UIKit nor for SwiftUI (which does at least offer previews), leading to more *frequent* edit, compile, debug cycles
play a bigger role here; use of LLMs is just a cherry on top (spicy autocomplete).
Oh, and Apple’s docs being notoriously poor.
Paradise Pete@daringfireball Claude Code already works pretty well with Swift 6 and Xcode projects (by being able to see and modify an entire project's codebase). I'm hopeful there will be more direct integration coming soon.
Dieter Komendera@daringfireball
@gruber Take a look at @steipete‘s post on implementing Swift 6 MacOS app with LLM assistance: https://steipete.me/posts/2025/vibe-meter-monitor-your-ai-costs
@gruber Take a look at @steipete‘s post on implementing Swift 6 MacOS app with LLM assistance: https://steipete.me/posts/2025/vibe-meter-monitor-your-ai-costs
mark@daringfireball
If this is true it does not bode well for the future.
If an improvement in technology is going to lead to a loss in productivity until there is a sufficient human body of work for AI to learn from, then that technology won't be used.
And we will end up stagnating. Especially if our skill level drops as we rely more and more on ai.
If this is true it does not bode well for the future.
If an improvement in technology is going to lead to a loss in productivity until there is a sufficient human body of work for AI to learn from, then that technology won't be used.
And we will end up stagnating. Especially if our skill level drops as we rely more and more on ai.
Steve Tibbett@daringfireball People have already pointed you to @steipete's blog, but the relevant bit, I think, is how he essentially distilled Apple's docs down into something that Claude could read, so that Claude would be working with current info. A pretty clever solution. https://steipete.me/posts/2025/migrating-700-tests-to-swift-testing
Steve BarnesGood thought. But Xcode made converting to ARC remarkably easy by comparison, whereas converting an app to Swift 6 can be a quest. I liken it to the fictional scenario that Swift debuted with no distinction between "let" and "var", then added it expecting everyone to adapt who'd coded for years without the notion in mind. It's clearly beneficial to the language and apps, but it's a major shift on the conceptual level for the programmer; I think even more than it is in code.