Reid Main

This year I made a conscious effort write about every WWDC 2024 session I watched so I could highlight which were the most informative. My apologies for focusing on Swift and iOS but that is what I've spent my entire career on so naturally I graduated towards learning more about the future of those platforms. I do hope I am able to carve out some time this year to learn more about macOS and visionOS.

In the past I've also written articles linking to tweets from various developers highlighting useful information that's come out of WWDC. Unfortunately, Elmo's takeover of Twitter lead to a mass exodus of those developers (myself included). Even with the emergence of new platforms such as Threads, Mastodon, and Bluesky I haven't been able to find the same conversations that were happening on Twitter.

Must Watch

These are the sessions that I believe everyone should watch because there probably will be no escaping the technologies discussed in them. Swift 6 and machine learning appear to dominate Apple's immediate future so even if you aren't planning on leveraging them you still should aware of what they can do.

Xcode 16

If there is one thing from WWDC 2024 that you cannot escape it is Xcode 16. So please set aside 22 minutes to watch What's new in Xcode 16 to be aware of the improvements that are coming and avoid doing your best Dr. Nick impression.

There is also the Xcode essentials session if you're looking more a more general overview.

Swift Testing

If I had to pick a single framework that I was most excited about it would easily be Swift Testing. There are two sessions covering it (Meet Swift Testing and Go further with Swift Testing) and they do a fantastic job on highlighting the benefits of the framework when compared to XCTest.

I have already ported the unit tests for some of my side projects from XCTest to Swift Testing and the results truly are night and day. Separating the name / description of the test from the function name, and the addition of arguments, make tests much easier to read and write. I even found myself adding more tests because when I migrated to using arguments I realized that I had missed some edge cases.

Currently Swift Testing does not support UI tests but based on what I have seen I have no doubt that it will by added in the near future.

Swift 6 Migration

Dread it. Run from it. Swift 6 arrives all the same.

There is no sugar coating this. The migration to Swift 6 will not be painless. Apple is well aware of this fact, so much so that they've actually created a Swift 6 Migration Guide to try to ease the pain.

They also have a WWDC session, Migrate your app to Swift 6, that looks to assuage developers fears and provide tips and tricks on how migrate to Swift 6 incrementally. However, below is a screen grab from this session.

I think "Here be dragons" would have been more apropos.

Consume noncopyable types in Swift

Consume noncopyable types in Swift was my most eye opening session from this WWDC. I was not personally aware of the consume keyword (even though it was added in Swift 5.9) but the idea of ~Copyable types and the effects of that blew my mind.

I'm really looking forward to using this concept to build a network interceptor pattern in Swift.

SwiftUI

Every WWDC is chock full of SwiftUI sessions so I'm going to save us all some time and just clump them together.

Create custom visual effects with SwiftUI was very informative and did a great job at highlighting the powers of view modifiers. It also demonstrated how we should think about writing custom animations and transitions in a declarative UI versus an imperative one. A good follow-up session is Enhance your UI animations and transitions which drills deeper into new and customizable transitions in SwiftUI.

Any decently complex app is eventually going to create their own container views which makes Demystify SwiftUI containers an absolutely critical session to watch.

Every developer should be considering the accessibility of their apps. Catch up on accessibility in SwiftUI provides an excellent overview of the little steps you can take to quickly and easily improve accessibility for your users.

Machine Learning and Apple Intelligence

To be very clear, I am not one of those zealots who believes that "Artificial Intelligence" is going to revolutionize the world and kill the majority of jobs (including mine). But machine learning is a very interesting and powerful tool that I need to become familiar with. Apple also appears to believe this as there are a number of sessions on machine learning this year. Below are a list of the ones I watched:

1. Explore machine learning on Apple platforms
2. Train your machine learning and AI models on Apple GPUs
3. Bring your machine learning and AI models to Apple Silicon
4. Deploy machine learning and AI models on-device with Core ML

I will admit that even after watching these sessions I am still very lost when it comes to machine learning but I now have a much better idea of the toolchain. I suspect that the only way I going to actually understand machine learning is by coming up with a concrete problem and attempting to solve it using Core ML.

App Intents

If you have no interest in supporting Apple Intelligence then you can probably skip this section or consider it part of the "Honourable Mentions". But after watching a number of sessions on App Intents it seems obvious that this is how Apple intends for developers to expose functionality of their apps to Apple Intelligence. In the Design App Intents for system experiences session an Apple designer states:

Let's start with which app intents to make. Previously, app intents were meant to be the most habitual tasks in your app that could be useful outside of your app. This meant an app was expected to only have a few app intents. In iOS 18, we're changing this guidance to go beyond common functionality. Now, anything your app does should be an app intent.

And after watching What's new in App Intents, Bring your app's core features to users with App Intents, and Bring your app to Siri, it truly does look like Apple views every feature as a potential App Intent.

Personally, I have never used the Shortcuts app so I have never used an App Intent which makes it hard to understand the benefits of them. But Home Screen widgets and Control Center controls are underpinned by App Intents so developers are being gently pushed towards them which means Siri and Apple Intelligence should just be a stones throw away. However, as of the time of this writing, Apple Intelligence still has not been made available in any of the iOS 18 betas so we cannot truly understand how our App Intents are going to leveraged by the OS.

Honourable Mentions

Embedded Swift

Go small with Embedded Swift was a really interesting session because I did not realize how "easy" it was to write Swift code for microcontrollers. Don't get me wrong, there is obviously still a lot of work to be done before this can be considered production ready. But it does appear that Apple is allocating some decent resources to it. Their Swift Matter tutorials are more thorough then some of their SwiftUI documentation!

If you're looking to buy the hardware from the session it appears to be a basic breadboard, MEGO power supply, and ESP32-C6-DevKitC-1-N8 Development Board.

A Swift Tour: Explore Swift's features and design

If you know someone who is an experienced programmer but has not written a single line of Swift then please direct them to A Swift Tour: Explore Swift's features and design.

Personally I didn't find it that useful as I've been using Swift for nearly a decade now (holy fuck) but so many things have changed since Swift 1.0 that having an up-to-date WWDC session is perfect after the release of Swift 6.

SwiftUI

SwiftUI essentials is a useful session if you're completely in the dark on SwiftUI. But to anyone whose already written even a basic SwiftUI app you're going to benefit more from other sessions or just diving into sample code.

If you are a macOS or visionOS developer then Work with windows in SwiftUI will probably be of interest to you.

Explore the Swift on Server ecosystem

Recently I have been dabbling with an app idea that would require a basic REST API. In the past I have used Ruby and Sinatra to prototype these sort of things but have never felt conformable shipping them to production. Go and Rust seem to be the obvious choices for building production-ready backend services but after watching Explore the Swift on Server ecosystem I kinda wanna try Swift.

My trepidations stem from Swift on Server's abysmal marketing buzz. It is easy to find examples of Go or Rust being used at scale and for very complex projects, 1Password being a prime example. But if you google for "Swift on Server" you're more likely to find results asking if Swift on Server is ready for production or why should I bother using it. To be very clear, this doesn't make me believe that Swift on Server is not ready for the big leagues. I do believe that Apple is using Swift internally for massive projects that are powering billions of requests and terabytes of data. My hesitation has more to do with not being sure if I will be able to find answers to problems I encounter because Swift is simply not being used and discussed as much as Go or Rust.

All of that being said, there are Apple's Swift on Server guides and official Swift Server forums which seem to be quite lively and up-to-date. So rather than act like I am building the next billion dollar company and my backend services need to be scaleable from Day 1, I should just man up and give Swift on Server a try.

Meet the Translation API

I suspect that very few developers will actually leverage what is talked about in the Meet the Translation API session. But it is just really interesting to see how this is now possible on device and available to all of us. In the past this is the sort of technology that companies would license for tens of thousands of dollars and now it is just shipped with the OS.

SwiftData

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

It is impossible to overstate my hatred for CoreData. Over my career I have witnessed (and sometimes overseen) the removal of CoreData at nearly every job I've had. The "magic" that it provides is immediately undercut by the absolutely asinine blackbox implementation which you will always find yourself fighting more than enjoying. Writing your own persistence layer will invariably pay dividends in the long term because any issues you encounter or features you need can be easily built. Whereas with CoreData you'll need to sacrifice something to the Apple gods and pray that an OS update doesn't cause you horrible issues.

After watching What's new in SwiftData and Create a custom data store with SwiftData I cannot help but feel it is a different side of the same coin. Yes the various Swift macros that allow you to define models in code instead of a managing a gargantuan .xcdatamodeld file are a step in the right direction. But effectively the same blackbox implementation exists and if I was going to create my own custom data store, what major benefits am I getting by tying myself to this CoreData-ish API versus designing my own?

I never understood iOS developers fear of interacting with SQLite directly. Look at popular frameworks such as GRDB or SQLite.swift and you'll see that this is not rocket science.

Explore Swift performance

I think this session is misnamed. It should have been "Explore Swift Memory Management" not "Explore Swift performance". It is a very technical session but really doesn't directly deal with or tell you how to measure / improve Swift performance. It focuses solely on how Swift allocates and manages memory which can obviously have a major effect on Swift's performance.

I would bet that it is going to go over the heads of a large portion of the developers who watch it. But at the same time, once you start working on non-trivia problems or more complex code, the teachings in this session are invaluable. Memory management is one of those things that seeps into your bones and fundamentally changes how you program at a subconscious level. The last sentence of this session is "I hope the information in this talk helps you to develop an intuition for the performance of your Swift code" which I could not agree more with.

Even if you're like me and have been dealing with memory management since the pre-ARC / Objective-C days, there are still lots of interesting bits of information in this session. Particularly the section on "Async Functions" and how Swift Task objects allocate memory.

Going off on a little tangent, something that I would love make more widely known to Swift developers is using final class instead of struct. You're told to use struct and take advantage of value semantics but a lot of the time final class can be more appropriate for objects you know will live a long time but aren't being modified. Passing a reference to a final class can reduce memory usage and speed up function resolution.

Bring expression to your app with Genmoji

The biggest takeaway from Bring expression to your app with Genmoji is that Genmoji are not unicode characters. So if you are integrating them into your app there are various gotchas you need to be aware of to make sure you're giving your users the best experience.

Probably Skip

Not every WWDC session can be a banger and there are definitely some you can save time on by either just reading the transcript or skipping entirely.

What's new in Swift / What's new in SwiftUI

What's new in Swift and What's new in SwiftUI are effectively blog posts that are being read to you. I'd recommend you save some time by reading the transcripts and watch whichever linked sessions interest you.

Meet TabletopKit for visionOS

I'll be brutally honest, after watching Meet TabletopKit for visionOS I have absolutely no idea why TabletopKit exists. It gives me vibes of SpriteKit. Everything is way too simple and restrictive to be useful for anything beyond basic prototypes. The sample code for this session can't even be properly tested unless you have TWO Apple Vision Pro headsets! And remember, when this session was released the Apple Vision Pro was still only available in America. The kicker is that when I ran the sample code in Xcode I couldn't do anything. As far as I could tell none of the rules of the game were active and all I could do was move dice and cards around the table.

I cannot imagine any developer seeing this session, running the sample code, and thinking that it is a good idea to tie themselves to the TabletopKit framework instead of just rolling their own version.