Swift 6
Holly Borla (Hacker News, Lobsters):
Swift 6 marks the start of the journey to make data-race safety dramatically easier. The usability of data-race safety remains an area of active development, and your feedback will help shape future improvements.
Swift 6 also comes with a new Synchronization library for low-level concurrency APIs, including atomic operations and a new mutex API.
[…]
Swift 6 introduces a number of productivity enhancements, including
count(where:)
to streamline counting the number of elements in a sequence that satisfy a predicate, pack iteration for writing naturalfor
-loops over the elements in a value parameter pack, access control for imports to keep implementation details from leaking into your public APIs,@attached(body)
macros for synthesizing and augmenting function implementations, expression macros as default arguments, and more.You can find a complete list of language proposals that were accepted through the Swift Evolution process and implemented in Swift 6 on the Swift Evolution dashboard.
[…]
Swift 6 unifies the implementation of Foundation across all platforms. The modern, portable Swift implementation provides consistency across platforms, it’s more robust, and it’s open source. macOS and iOS started using the Swift implementation of Foundation alongside Swift 5.9, and Swift 6 brings these improvements to Linux and Windows.
I started documenting my learnings about Swift 6 errors, the reasoning behind them, and how to fix them. The first one is:
Static property ‘shared’ is not concurrency-safe because non-’Sendable’ type may have shared mutable state
Swift 6 strict concurrency checking may be the quickest and easiest way for me to feel like a dunce. ☹️
Half of these warnings I’m just like “uhhhhhh… wat”.
I’m sure I’ll get there, but, gracious. 😓 Gotta stop kicking that can though…
Just wait until you have fixed all errors but the app is crashing at runtime randomly because of missing annotations in first-party frameworks.
My advice for updating to Swift 6:
Turn on the switch, fix the easy stuff, turn it off again, and wait until next year. Apple will spend the next year making it easier to adopt complete concurrency.
I’m leaning towards this plan too. Properly adopting concurrency in Swift 6 is way too convoluted. I can’t imagine Apple won’t get flooded with feedback from developers, pushing them to simplify it in a future version.
Swift 6 is solving a problem I didn’t encounter in 15 years of iOS development by providing me with lots of problems I didn’t ask for.
Previously:
- Xcode 16
- Calling async Code Synchronously in Swift
- Actor Reentrancy in Swift
- Swift 6 Announced
- Swift 5.10
- Swift Foundation Preview
Update (2024-10-24): objc.io:
We start a new macOS project to explore Swift 6’s concurrency features.
Is Swift 6 strict concurrency going to be our Python 3 moment?
19 Comments RSS · Twitter · Mastodon
Swift keeps “solving” problems I don’t have, while making the problems I DO have worse with every release.
I can’t recall the last time I had a concurrency bug in an iOS app by simply following the pattern of sticking to the main thread, offloading long work to a background queue and always calling back on the main queue.
The problems I encounter daily with Xcode and Swift are getting worse: compiler crashes, the debugger being useless or not working, bugs in the standard libraries, bugs in the language, horrible compilation speed.
Swift is downright one of the worst compiler toolchains ever: in 25 years I’ve never used such a buggy toolchain and that includes early versions of PHP and .net.
Apple’s engineers are too busy scratching their own itches unfortunately.
I think the Apple community too easily accepted Swift and it's been a sunk cost fallacy headache since.
What keeping people so attached to it? What keeps people away from Obj-C (for Apple-only projects), or away from other languages/dev toolchains (for cross-platform)?
If Apple bitterly kills ObjC support in Xcode just to push Swift, then Apple dev tools are a proven business risk, and I certainly won't rewrite in Swift.
I'm looking cross-platform for my next move. The idea of not being saddled with Swift, ditching Apple's tightening noose (App Review, certs, notarization, macOS lockdown), and having a larger customer base is more appealing than rewriting my code every year to be actor-safe (or whatever yearly churn is pushed).
It is such a relief to read here that I am not the only one. I feel EXACTLY like @A and @Hammer. Thanks for sharing.
Yea if the kill ObjC I’d move to Flutter before going to SwiftUI. Or perhaps something else. I want no parts of Swift and especially SwiftUI.
ObjC was better for apps than Swift. I don’t think it’s even close
I suppose this is the inevitable outcome of commercializing a programming language and turning it into a company product. They need to align with the yearly cycle of WWDC, and when you think about it, the current state of Swift makes sense 😔
That being said, Swift 6 mode isn't very convincing at all.
It was all smooth sailing for me.
I turned on strict concurrency checking very early on, and initially it felt overwhelming.
But it paid off to bite the bullet early, and I could seamlessly switch to Swift 6 in beta season.
And it’s a massive project, including a custom in-house game engine in Metal, close to million lines of code.
Extensive testing are so far is showing stable and robust code, and running.
For me at least, I can say the Swift team did a good job on this, and will for sure improve further at a fast pace, considering the problems many seem to face.
Thinking about it a bit more: I think there’s a huge disconnect in Swift between what the language is mostly used for (simple app development) and what the compiler engineers want it to be (a server/system language).
The swift compiler engineers work on the exciting part: the server/system things and complex problems, while most people building app just want a boring, simple and mostly stable language and toolchain. Swift hardly makes app development easier - in fact - it’s getting more complicated and buggy every year.
All the things they have been adding recently (concurrency, non copyable types, parameter packs, etc) are all solving issues I never encountered in app development for iOS, but they’re very relevant when you’re focussing on server/systems.
There’s probably a lot of bias also, because people on the (pretty toxic) Swift forums are all language enthusiasts, making it seem these are all very important problems to solve. If you dare to critique Swift by complaining about broken features (macros, compiler) on the forums, you basically get dunked on by a bunch of regulars and just leave.
As someone who would like to be able to develop iOS and macOS apps, I've been sitting on the sidelines trying to figure out when it is a good idea to learn Swift. ObjC might be better, but I've never learned it and it seems foolish to try to learn it right now with how Apple is treating it vs Swift.
I've looked at cross-platform options, Flutter, Kotlin, etc, but at least half of what I want is for any application I write to feel native and run well. It seems like this would be harder using any of the cross platform tools. Especially anything that leans on JS/React/WebTech.
@gildarts
Now is a good idea to learn Swift if you want to target iOS/MacOS.
Currently, this is Apple's trajectory, and they are building their modern ecosystem around Swift.
It's unwise to fight that, whether one hates Swift or not.
Why waste time on ObjC if you know you will not need it for whatever(legacy code or similar).
If you choose ObjC, you will be fighting Apple all the way.
@Leonidas Yes, there are already some important APIs that are Swift-only, and this will only increase over time. It’s impressive that hybrid codebases work as well as they do, but I think you want to avoid or limit that if possible.
@gildarts: Objective-C is a great language but Apple is killing it, and most of their people probably don't even realize what they're losing.
It's a bit like that quote "an elegant weapon for a more civilized age". However, Objective-C takes time to master, and appreciate its strengths. That was something the hordes of barbarians who converged on the Mac didn't want to spend their time doing, so Apple gave them Swift instead. And now Objective-C will probably stay a relic of a bygone era, unless something like GnuStep experiences a revival.
I've mostly held back from developing for the Mac since the introduction of "Swift", although I had a client who needed an iPhone project delivered, so I wrote some Swift. I could see some Haskellisms but I was far from impressed by it. I had to hack around its deficiencies in C (ironically mostly due to it making unnecessary copies of data slowing a real time project down...).
> If you choose ObjC, you will be fighting Apple all the way.
You’ll be fighting Apple no matter what. People said the same shit a few years ago about Autolayout. Adopt Autolayout…or else. Now if SwiftUI is the future then I guess autolayout is already dead aye? What did it have like a 10 year run? I don’t think Apple could abandon ObjC anytime soon even if they try their hardest …unless they want to be dicks and just keep it as private API and nuke a million apps by hitting a kill switch.
Mac Catalyst isn’t that old and it’s supposedly already on the chopping block. Don’t get on the Apple hamster wheel. They’ll tell you that this new hot garbage is the future, deprecate it in two years, and expect you to thank them for the privilege of getting fucked.
But I do agree that if I was just starting out I wouldn’t learn Objective-C. Pick something cross platform, preferably open source you can take with you to other platforms. The quality advantage of using the Apple “native” UI framework no longer exists so there is no reason to let them lock you in. Take a look at that ridiculous Photos app in iOS 18.
I’m actually encouraged by all the negative Feedback I read about Swift on Hacker News yesterday. More and more people seem to be realizing that this language and tool chain sucks.
Just to add about Autolayout it didn’t really have a ten year run. It takes a few years for an API to mature. You have to subtract rough patches in the early years. The APIs start getting mature you start getting in a groove and then they start Josh Schaffing your ass and deprecating you. Be careful jumping into the newness. If you like declarative UI frameworks there are cross platform third party ones I don’t know why you would want to use Apple’s.
I do want to give some credit to Apple though…I’ve been monitoring the dev forums lately and they have replying more to posts lately. Even questions about Objective-C.
I care about systems/networking code and in practice I'm not seeing much benefit to swift there either, except for the obvious semantic sugar for foundation types and concurrency, but you've got Go that has a much bigger library and is *impressively* and *aggressively* cross-platform (if you hate the language, just check out the cross-compiling toolchain!).
And yeah, even *C* APIs (UNIX native) are disappearing; you can't even access certain filesystem flags with them any more and Apple is in no hurry to provide the necessary portable interfaces. Really sad. Once the foundational tech all had portable API.
I did Classic Mac Finder (https://classicmacfinder.com) in Objective-C. I haven't actually made modifications to the code in about 6 years. The project still compiles and runs with zero hiccups on my M3 MBP. If I had used Swift (I actually tried that during my first attempt), it almost certainly would require so much work it'd basically be a rewrite. Obj-C is really nice and stable.
For mobile, Flutter/Dart creates a pretty nice end product, the Cupertino widgets do a good job. I can't see much reason to use Swift or SwiftUI except to practice platform purisms.
As an industry, we've got to get away from this idea of throwing all of this work and man hours away, especially for things like AppKit, Foundation and Obj-C.
"I did Classic Mac Finder (https://classicmacfinder.com) in Objective-C"
That app is fricken awesome, by the way.
Going off of what Ben said and speaking of old apps written in Objective C that still compile... I originally wrote xGestures back in 2004 for Mac OS X 10.3. The code has not changed much in a decade. The most major change it needed was removing old Carbon functions that were unavailable when compiling for 64 bit. It still compiles and runs fine today! It's a combination of Objective C and C++.
Now that I pause the think about it, it's actually kind of marvel how easy it's been to maintain given a) the codebase is a mess because I originally wrote it in college and b) how eager Apple is to deprecate stuff. But in part I have writing it in Objective C to thank for that.
Any opinions between Go and Rust? I'm fairly familiar with Go, but have been wanting to pick up Rust for expanding my base. Unsure how well either of them can integrate with macOS/iOS UI development.
@Bri: YMMV -- They broke some of the deeper Webkit APIs in 10.6 which killed one of my projects, and they never even changed the documentation to state that they broke those things. That was when they still cared about Objective-C.
The fact that the other APIs still work may not indicate that they are still maintaining Cocoa. Instead it may indicate that they are not changing its code anymore, so it still works like it used to. The problem is that that API may stop working if they break something underlying those APIs and don't fix it. This makes it difficult to recommend new app development using Objective-C. On the other hand, the need to "fix" new issues with Swift don't recommend it either.
@gildarts: I built something in Rust about a decade ago. I liked it, but it was a command line tool, not a GUI, and Rust may have changed in the mean time.