Swift 6 Productivity in the Sudden Age of LLM-Assisted Programming

Kyle Hughes, in a brief thread on Mastodon last week:

At work I’m developing a new iOS app on a small team alongside a small Android team doing the same. We are getting lapped to an unfathomable degree because of how productive they are with Kotlin, Compose, and Cursor. They are able to support all the way back to Android 10 (2019) with the latest features; we are targeting iOS 16 (2022) and have to make huge sacrifices (e.g Observable, parameter packs in generics on types). Swift 6 makes a mockery of LLMs. It is almost untenable.

This wasn’t the case in the 2010s. The quality and speed of implementation of every iOS app I have ever worked on, in teams of every size, absolutely cooked Android. [...] There has never been a worse time in the history of computers to launch, and require, fundamental and sweeping changes to languages and frameworks.

The problem isn’t necessarily inherent to the design of the Swift language, but that throughout Swift’s evolution Apple has introduced sweeping changes with each major new version. (Secondarily, that compared to other languages, a lower percentage of Swift code that’s written is open source, and thus available to LLMs for use in training corpuses.) Swift was introduced at WWDC 2014 (that one again) and last year Apple introduced Swift 6. That’s a lot of major version changes for a programming language in one decade. There were pros and cons to Apple’s approach over the last decade. But now there’s a new, and major con: because Swift 6 only debuted last year, there’s no great corpus of Swift 6 code for LLMs to have trained on, and so they’re just not as good — from what I gather, not nearly as good — at generating Swift 6 code as they are at generating code in other languages, and for other programming frameworks like React.

The new features in Swift 6 are for the better, but, in a group chat, my friend Daniel Jalkut described them to me as, “I think Swift 6 changed very little, but the little it changed has huge sweeping implications. Akin to the switch from MRR to ARC.” That’s a reference to the change in Objective-C memory management from manual retain/release (MRR) to automatic reference counting (ARC) back in 2011. Once ARC came out, no one wanted to be writing new code using manual retain/release (which was both tedious and a common source of memory-leak bugs). But if LLMs had been around in 2011/2012, they’d only have been able to generate MRR Objective-C code because that’s what all the existing code they’d been trained on used.

I’m quite certain everyone at Apple who ought to be concerned about this is concerned about it. The question is, do they have solutions ready to be announced next week? This whole area — language, frameworks, and tooling in the LLM era — is top of mind for me heading into WWDC next week.

★ Saturday, 7 June 2025