4 min read

Issue #66

Hi there, welcome to the 66th issue of iOS Code Review! Today we'll dive into what's new in Swift 5.10 which was just released as part of Xcode 15.3, the Observation framework, and an accessibility topic. Enjoy 🙌

Are you motivated by the craft of writing Swift? Want to improve your productivity and the quality of your results? Want to hang out with other awesome developers with the same mindset?

Swift Craft is a brand new conference for passionate developers working on Apple platforms. Set in a UK seaside town with stunning views across the English Channel, with an incredible line up of some of the community' top speakers, delivering dozens of sessions on the latest Swift features and writing even better code - this is the inaugral event you won't want to miss!

Find out more and check out the full schedule

What's new in Swift 5.10

Swift 5.10 achieves an even further level of concurrency checking - preventing the app from data races and undefined behaviour.

An increasingly important source of undefined behavior is concurrent code that inadvertently accesses memory from one thread at the same time that another thread is writing to the same memory. This kind of unsafety is called a data race, and data races make concurrent programs exceptionally difficult to write correctly. Swift solves this problem through data isolation provided by actors and tasks, which guarantees mutually exclusive access to shared mutable state. Data isolation enforcement has been under active development since 2020 when the Swift concurrency roadmap was posted.
In Swift 5.10, full data isolation is enforced at compile time in all areas of the language when the complete concurrency checking option is enabled.
The Swift 6.0 compiler will offer a new, opt-in Swift 6 language mode that will enforce full data isolation by default, and we will embark upon the transition to eliminate data races across all software written in Swift.

Read about the new checks and errors in Swift 5.10, which complete years of iterative development and prepares us for Swift 6:

Swift 5.10 Released
Swift was designed to be safe by default, preventing entire categories of programming mistakes at compile time. Sources of undefined behavior in C-based languages, such as using variables before they’re initialized or a use-after-free, are defined away in Swift.

Have you tried Observation framework?

I've stumbled on three articles that are perfectly timed to my interest in understanding the Observation framework. Observation framework is iOS 17+ only, but iOS 18 is just around the corner, so it's a good time to learn more about Observation. Here they are!

The official, step by step guide on migrating your models, with sample code:

Migrating from the Observable Object protocol to the Observable macro | Apple Developer Documentation
Update your existing app to leverage the benefits of Observation in Swift.

If the official documentation is not your style, Donny Wals has written an article on comparing the old and the new approach:

Comparing @Observable to ObservableObjects – Donny Wals
Find out how you can leverage the new @Observable macro in your apps. You’ll lean how it compares to ObservableObject and whether it makes sense to switch

Unit testing Observable models

When your view models are @Observable and use the new Observation framework, the Combine-based unit tests won't work anymore. Jacob shows how he uses withObservationTracking in his code to test the new models:

Unit Test the Observation Framework
Make your iOS 17 view models rock-solid

Accessibility Representation modifier

Here's the key parts from the article, couldn't say it better than the author himself:

In app development, it's not uncommon for two distinct views to have the same appearance and functionalities, despite being implemented differently. ... For example, an Image view with an onTapGesture modifier may appear and function like a Button component, but the VoiceOver experience can be completely different.
The accessibilityRepresentation(representation:) modifier in SwiftUI is designed to transform how an app's elements are perceived by assistive technologies, such as VoiceOver. ... This modifier allows developers to provide alternative representations of their components that are more accessible for users using assistive technologies, ensuring that the app's functionality is accessible to everyone.

Check out code examples in the full article:

Making a view accessible using the Accessibility Representation modifier
Learn how to ensure the accessibility of your custom views by replacing their accessible representation.


Alright, that's it for today! Let's spread the good code vibes ✨🧘🌈☀️
I'm curious if you found any of the tips particularly interesting - let me know by replying to this email.

Thank you to Swift Craft conference for sponsoring this issue ❤️