I’ve heard many people echoing Alex Grebenyuk’s thoughts about Swift 6 language mode recently. It’s a long post, but it’s worth reading. Give it a read and come back.

What Apple is doing with Swift 6 language mode is bold, and if it works, there’s a clear and significant upside. Swift apps will benefit from fewer crashes and unexpected behaviour. But, as Alex and the others who messaged me point out, using the new language features correctly puts a significant burden on developers, and this is especially true for those maintaining larger apps.

One of the problems with designing a language intended to scale from embedded systems, through every modern computing platform, to the largest back-end systems chock-full of concurrent code is that not all those use cases need all the language’s features. Swift’s answer to that has always been progressive disclosure, and it works well. You could go through a great many Swift tutorials and even publish an app to the store without needing any concurrency. You will need it at some point, though, and unless you’re experienced with understanding data races, you’ll likely hit a fairly steep slope with the warnings/errors produced by Xcode. The grumbling I hear isn’t coming from novice developers, either. For example, from Alex’s post:

There’s also been a notion that the new warnings are easy to fix. I’m sure some of them are, but that wasn’t the case in my experience. In my frameworks and apps, I had to carefully think about almost every individual instance and then often update tests, etc, which was extremely time-consuming even in smaller well-maintained codebases. Migration seems easier once you’ve done it, but at this point, it’s too late. I wouldn’t underplay how complex it is, especially anything related to closures and delegates.

It’s important to note that no one is forcing anyone into adopting Swift 6 language mode, where the concurrency warnings turn into errors. You can continue with Swift 5 language mode. But what happens if significant numbers of people choose that path permanently? I’m confident Apple has thought about this possibility and has a plan, but it has the potential to be a messy situation.

Don’t get me wrong, I’m not calling this a failure by any stretch of the imagination. We’re only 5 weeks into Swift 6's beta. There’s plenty of time before anyone needs to worry about people who might choose never to switch. I hope it’s also clear that I hope the bold move succeeds. There are also possibilities for Apple to do more work to ease the transition, and not only in the few weeks we have left until a 6.0 release, but onwards into 6.x releases. As many people often like to joke when Apple releases something new, this is the very worst version of data race safety checks that the Swift compiler will ever have! 😂

I have no conclusion to make here. Like I say, it’s way too early to call it either way, but it’s definitely worth listening to developers who are raising warning flags and writing blog posts like Alex’s.

Dave Verwer  

Join the FREE iOS Architect Crash Course

If you're a mid/senior iOS developer looking to improve both your skills and salary level, join this free online crash course. It’s available only for a limited time, so get it now.

essentialdeveloper.com  

Apps For Apple Vision Pro

Thanks for all the apps and TestFlight links you all sent me after my comment last week. I had a great time trying lots of them out. But, one link that came through loud and clear in all the emails I got was this site. It's by brothers Perjan and Krist Duro. What a great site, and I’m linking to it here in case you have a visionOS app that’s not listed, get it on there!

appsforapplevision.com  

Xcode-Kotlin 2.0

This is a very cool article from Tadeas Kriz on a new release of xcode-kotlin, the LLDB plugin for Kotlin Native. Surprisingly, this allows full visual debugging support in Kotlin Multiplatform (KMP) native code, including (by the look of it) support for mixing languages in one debug session. If you use KMP, you’ll want to check this out. 👍

touchlab.co  

Xcode 16’s Entry macro

I love that SwiftUI’s new @Entry macro doesn’t need the latest platform SDKs to run, only Xcode 16. That’s good news for anyone wanting to utilise the SwiftUI environment. What exactly does it do? Donny Wals is here to show you.

donnywals.com  

Using SwiftUI in Command Line Tools

You may be feeling the same way I felt when I first read Natan Rolnik’s latest post title; confused. How would using SwiftUI from a command line tool make any sense? Luckily, I clicked through to read the post to find out how, and it’s by using the ImageRenderer. Now that is useful.

swifttoolkit.dev  

Make SF Symbols Wiggle

I didn’t think I’d ever need to say the words “by-layer wiggle” and yet here I am talking about Rudrank Riyam’s latest blog post writing those exact words! He takes us through what wiggle options we have and then shows us how he’s using it in his LyricsLink app.

rudrank.com  

Some vs Any

Let’s finish this week’s Code section with this piece by Mohammad Faani, which has the clearest explanation of the difference between Swift’s some and any keywords I’ve seen. 👍

mfaani.com  

AltStore: Q&A with Riley Testut

You may have heard some of what Riley Testut says in this interview with Peter Meinertzhagen. Much of it is in blog posts and articles on other sites, but this snippet caught my eye:

Riley: The notarization process often takes longer than App Review. For instance, submitting Delta for notarization might take a whole day, whereas App Review could be just a couple of hours. We have several apps waiting for notarization for weeks now.

I know it’s early days, and processes inside Apple will still be being tweaked but I’m surprised to hear this. The process should be relatively straightforward.

For full disclosure, Peter works for RevenueCat who regularly sponsors this newsletter. This interview is from their blog.

revenuecat.com  

Software Engineer, iOS @ amo – Amo values speed, creativity, and high performance. Focused on meaningful social apps, they prioritize creation over consumption and simple, fun experiences. The diverse, skilled team uses a modular monorepo tech stack with Rust, Bazel, and RxSwift, leveraging efficient data processing on GCP. – On-site (France)

Product Engineer (iOS, Full-Stack) @ Emerge Tools – Have a huge impact working with our small, technically elite team (just 8), build tools used some of the biggest & best mobile teams in the world (DoorDash, Square, Spotify, Duolingo, Tinder, Bumble) – Remote (within US timezones)

Senior iOS Developer @ Komoot – Your work will contribute to helping millions of people enjoy lovely outdoor experiences and you can work from wherever you want, be it a beach, the mountains, your house, or anywhere else that lies in any time zone between UTC-1 and UTC+3. – Remote (within European timezones)

I didn’t think I’d watch a 20-minute video on building a keyboard, today, but I did! ⌨️