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
2 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).
