My experience migrating to Swift 6 and some thoughts about Swift in general https://kean.blog/post/swift-6
@a_grebenyuk the errors/warnings *are* the Swift 6 mode, no? The whole point is to make a hard line at compile time (or else none of it works) but the transition is completely optional
@a_grebenyuk @rodionovd You skipped an important step. If you don’t change your language mode to 6 then you get warnings instead of errors when you turn on targeted or complete concurrency in mode 5. I’m pretty sure that’s exactly why language mode remains at 5 until you manually change it, even for new projects. The migration guide recommends going through those warnings before switching over to version 6. Hard to take away anything from the rest when the premise is misguided.
@sjs @rodionovd that's a good point. I rephrased it to "If you want to migrate a large codebase to support Swift 6 mode, you need to fix thousands of compiler warnings that become errors once you enable this mode".
@a_grebenyuk Don’t get me wrong either, it is a giant and daunting task to migrate a large, existing codebase. It’s not a bad reason to start modularizing more so that pieces can be upgraded separately. That’s adding even more work though so could be a hard sell.
It’s not great to live with a thousand warnings while working away in Swift 5, masking new warnings that you would want to address. I’ve already been dealing with that because of AVAsset warnings after dropping iOS 15 (everything has to be loaded async now, old sync methods are deprecated).
@sjs Yeah, I generally agree that it is a compelling feature, and I've been slowly migrating to the new concurrency APIs and modularization myself. However, realistically, I'm afraid it's going to be years of work because it's impossible to prioritize reworking something that isn't broken, often for no benefits. I don't want to be left behind unable to migrate to Swift 6 because of the concurrency warnings or errors I don't necessarily even care about.
@a_grebenyuk That’s a fair concern though I think there are enough escape hatches to help you through that transition without being left behind. e.g. @MainActor for views and view-adjacent classes, @unchecked Sendable for classes that already serialize w/ dispatch queues or locks, and unsafe(nonisolated) for globals and static members.
@sjs, it becomes easier once you've done it once, but at this point, it's too late. I wouldn't underplay how complicated it is when approaching it for the first time, especially anything that has to do with closures and delegates.
@sjs @a_grebenyuk You can disable all concurrency checking related related warnings in Swift 5 mode.
@sjs @a_grebenyuk @rodionovd I think we have to be careful to remain both patient and kind when reading people’s thoughts here. This can be a very difficult and frustrating process!
@mattiem @sjs @rodionovd that's very kind of you Matt, but I can take it 
@a_grebenyuk @sjs @rodionovd I think we can find ways to communicate about stuff like this without anyone needing to take anything!
@mattiem @sjs @rodionovd I wrote the "Swift is Cooked" headline, which I now reluctantly changed. The only way you get anyone to read a post is with an obnoxious headline, which I've done a couple of times with great success, but I tend to avoid 
@mattiem @sjs @rodionovd but I think it's a well-balanced take if you ignore the original headline. And, yes, I know about the tools for the incremental migration, but I don't think it changes the premise.
@a_grebenyuk @mattiem @rodionovd That’s a big reason why my post may sound a bit harsh. I don’t like that inflammatory style. The meme was pure jest though, riffing off your meme in the article. I think we can disagree and have some fun at the same time.
@sjs @mattiem @rodionovd agree, it’s all good fun
@a_grebenyuk @sjs @rodionovd I’m very sensitive to how we talk to each other. Perhaps too much sometimes. Thumbs up all around!
@mattiem @a_grebenyuk @rodionovd Honestly I appreciate that. Kindness and understanding never hurt.
@sjs @mattiem @a_grebenyuk @rodionovd Totally agree. We need more of this kind of sensitivity, IMO. Also worth remembering that someone will be more likely to hear your criticism/feedback when you give it gently. In this case, I think it's anyone making decisions about future Swift changes who needs to hear it. The rest of us are incidental consumers, IMO.
@sjs @mattiem @a_grebenyuk @rodionovd Not that I'm saying I completely agree with the post. But I do generally agree with the sentiment. I'm worried we've got a situation where we'll have code for a long time that is either written for Swift 5 or for Swift 6.
@grid @sjs @a_grebenyuk @rodionovd I don’t think you have to be worried. I’m pretty sure there are code bases that will never be able to transition to 6.
@mattiem @sjs @a_grebenyuk @rodionovd No, that is exactly the reason to be worried. I don’t really know if the swift community is large enough to bifurcate at this point.
@grid @sjs @a_grebenyuk @rodionovd Oh well that you do not have to worry about! Swift 5 and 6 modes are 100% compatible.
@grid @mattiem @sjs @rodionovd I hear this a lot – "sounds like the project may need to stay on Swift 5", which I'm not sure how folks think is an acceptable answer, especially because of a niche feature.
There is no lack of evidence of the downsides of the design, so I doubt the post will have any effect.
> The rest of us are incidental consumers, IMO.
Yeah, just a user here. Although, as an engineer, I feel resourceful enough to make anything work. There is enough ways to ignore "errors"
@a_grebenyuk as someone who has near on 800 errors in several projects, I feel your pain. However, I have seen an improvement in Xcode 16 with some of the changes there to better recognise exclusive access to global variables amongst other improvements. My personal take is that this is a necessary and positive step for the language even though it has short term pain for complex multi-threaded projects today.
@murfin I generally agree, and it would've been an easier sell if it didn't require as much manual work. I think it's going to result in a major productivity loss in the short term because nobody likes being left behind, and they'll force themselves to plow through this even if there are no immediate benefits and it would've been better to apporach it incrementally.
@a_grebenyuk it is certainly quite labour intensive. My approach so far has been to enable strict checking, make some fixes and then disable again. I’m treating it in a similar way to migrating to the Observable macro.
@a_grebenyuk I agree with your points - I haven't worked much with Swift/Xcode lately, but based on everything I read from other folks here, I'm worried about where this is all going… it feels like all the changes from the last ~2 years are kind of forced, and like you say, not something that reduces the amount of work, but that adds a lot of extra work. I hope they make it something that's explicitly optional forever, and not just that we have a few years to adjust to.
@mackuba thank you, that's exactly my thoughts. I will have no problem with it as long as it's not forced upon you if you want to use Swift 6 and have an easy path to use future versions of the language. I also think it's still a bit early to adopt in its current state because it requires too much manual work, but I don't want to be left behind using Swift 5 for an extended period of time.
@a_grebenyuk I'd be fine with it if they just rename it from "Swift 6 mode" to "Concurrency checking: warnings / errors / ignore" (or something more fine-grained). Because right now it seems clear to me that some Xcode 19 or 21 will show an error that says "this version of Xcode doesn't support legacy Swift version, use older version of Xcode to migrate"…
@a_grebenyuk Have I lost my mind or was there a few lines in there about SwiftUI and SwiftData earlier?
@roanutil I thought it was taking away from the main point, so I removed it. It should be in Git history https://github.com/kean/articles/commits/main/.
@a_grebenyuk Understandable. The bit about SwiftUI API is something I strongly agree with. I like SwiftUI but no build error when using a modifier on a type that doesn’t support it is nuts. All the type information is there, I wish it could be used better at build time.
@roanutil I agree and I prefer the way it's done in UIKit
@a_grebenyuk I’ve been dismissive of a lot of Swift 6 criticism, but I think your framing nails it.
“This could fail at runtime so it needs to be an error” does seem inconsistent when compared to other language features.
Force unwrapping an optional can fail at runtime and that’s not even a warning!
Great blog post.
@hal Hal, you are reading my mind. I had the _exact_ same thought about force unwrapping just moments ago. I think this inconsistency is at the root of how it gets perceived. It needs to hit the right balance – just not quite there yet. I didn't want to write this post :/
@a_grebenyuk When you list new features you're not happy with, I can't help but notice it matches what I've recently come to conclude: Pretty much all of the new parts of Swift that I find unpleasant come from SwiftUI, such as property wrappers, result builders, and Observable. Things that do not, such as async/await, feel much better designed and fit into the language much better.
@WAHa_06x36 I'm fairly neutral on these things. But I'm strongly in the "worse is better" camp – simplicity over completeness and even correctness. Async/Await is my favorite recent addition to the language.
@a_grebenyuk My problem here is that a lot of these features just don't feel like they fit into the language. Property wrappers especially wreak absolute havoc on how you expect things to work, and seem to be in a constant fight with the type system, rather than complementing it. They are just really awkward to use for anything other than their intended use, which is simply SwiftUI.
@WAHa_06x36 I tend to agree. I don't use these features anywhere outside of SwiftUI. I think of property wrappers as a "magic annotation for SwiftUI" rather than a language feature, and it makes it feel alright.