There are a number of tiers on offer right now, but this might change over time – keep an eye on the project for updates.

The launch tiers are:

• $5 a month: Your name is added to a @discardableResult contributor list. Might be used. Might not.

• $10 a month: Your name and email address are displayed in Xcode's crash dialog. You're welcome.

• $20 a month: You get to use C-style for loops again – admit it, you missed them.

• $30 a month: Receive one (1) tub of Craig Federighi’s personal hair gel. Warning: may result in sudden confidence, vertical hair lift, and involuntary keynotes.

• $50 a month: You gain access to a special version of LLDB where po works first time. (But only on Tuesdays.)

• $100 a month: Includes one automatic rewrite of a Swift expression too big for the compiler to type check. Xcode will automatically split your line into 47 let statements and add a single comment, "There. Happy now?"

• $250 a month: Your name is chosen as a Swift reserved word so you can strut around in code reviews like the royalty you are.

• $500 a month: Every time you force unwrap an optional, a monk from Apple’s compiler team lights a candle. Your app will probably still crash, but morally you’re in the clear.

• $750 a month: Xcode will let you disable WiFi debugging for a device, but only if you ask nicely.

• $1000 a month: The compiler will start issuing passive-aggressive warnings. "Oh, you're still using Combine? Brave."

• $2000 a month: Your Swift code is no longer subject to ABI stability. You are the ABI now.

• $5000 a month: Once per month, Tim ...

Once again, it's a full-day, online-only workshop event aimed at intermediate to advanced developers, and everyone who attends will have ample chance to learn new approaches, tackle coding challenges, and of course ask lots of questions.

This year we'll be focusing on three key areas of AI:

• Getting deep integration with AppIntents so the system, so your app's content can be accessed and even queried through Siri.
• Integrating generative AI into your app using Image Playgrounds and writing tools.
• Bonus APIs such as NaturalLanguage and Translation.

If we have any extra time, I might try to squeeze in training your own models using Create ML, but that can be guided by folks on the day.

The format is the same as last year: live-streamed videos for all attendees where I walk you through specific techniques, backed up by hands-on coding challenges where you need to apply what you've learned – it's the fastest way to get up to speed with building great apps with AI.

All sessions take place March 8th, from 9am to 4pm US Eastern time. They will be recorded, and you'll be able to download the videos afterwards.

Tickets cost $100 each, but Hacking with Swift+ subscribers get access free. If you aren't already a Hacking with Swift+ subscriber, you can sign up before the event to get your free ticket – find out more here.

I'm also offering two other ticket types:

1. A diversity sponsor ticket, which is for folks who already have a ticket and want me to give one ticket away to someone who would otherwise not be able to attend.
2. A ticket + diversity sponsor option, where you can buy a ticket for yourself and one for me to donate.

Get your ticket here!

• Pro Swift helps you develop a deeper knowledge of the Swift language, and is packed with videos demonstrating all the techniques.
• Pro SwiftUI explores advanced techniques in SwiftUI, including optimization, debugging, complex layouts and animations, and more.
• Swift Design Patterns and Testing Swift combine to help you develop senior developer skills.
• Hacking with macOS and Hacking with watchOS show you how to extend your SwiftUI skills to other Apple platforms.
• Plus there are lots more books to choose from, such as SwiftUI by Example, SwiftData by Example, and Swift Concurrency by Example.

All my bundles are also on sale, meaning that you can get the Swift Power Pack for $75, the Swift Platform Pack for $100, or the Swift Plus Pack for $75. These bundles normally have a discount over buying the books individually, but the Black Friday sale on top makes them incredible value for money.

But if you want to save the most, you're looking for the Hacking with Swift: Everything Pack. It contains every book I've written so far, which means it's an instant learning library no matter your current level.

Bought individually, the books in the Everything Pack would retail for $820. Bought as a bundle that price comes down to $500. And with the 50% Black Friday discount on top, it takes the total price to get all the books I've written so far down to just $250 – it's just unbeatable value for money.

The sale starts November 11th, and runs until December 2nd. Whether you want to complete your collection, learn something new, or perhaps just treat a friend to a Christmas gift, this is your chance!

Whether you’re just starting out, looking to land your first job, or aiming to become a lead developer, this program offers everything you need to level up – from mastering Swift’s latest features to conquering interview questions and building robust portfolios.

So, if you're ready for a guided journey that will elevate your skills and accelerate your career, read on…

Your complete pathway

The Swift Career Accelerator aims to give you a complete pathway to take your career forward, no matter what your level is right now.

It does this by bringing together for the first time the world's largest collection of Swift development resources in one place, then carefully organizes it across five career stages so that everyone at every level has something to take them forward…

Level 1: Kickstart your career and land your first job

If you’re just starting out, Level 1 is designed to help you build the foundation for a successful career in Swift development. Along with my popular 100 Days of SwiftUI and Ultimate Portfolio App courses, you’ll gain exclusive access to my brand-new Take Home Test course. You’ll master essential skills like Git source control and dive into critical data structures like queues, stacks, and trees.

But that’s just the beginning. You’ll also get a wealth of new interview questions with expert answers, step-by-step guidance on crafting a standout resume, and practical tips for launching your first apps on the App Store. Everything you need to land that first job and start building your future is right here.

Level 2: Strengthen your skills and advance as a developer

Once you've found your first job, it's time to build on that foundation and take your skills to the next level. Here you'll move on to more detailed topics such as **gen...

A few weeks ago I received an email, which I'm sharing below with permission.

"I keep making mistakes, and have to go back and fix them again and again and again, and frequently make more mistakes while trying to fix the first mistakes. You never seem to screw up in any of your streams. How many more years until I get to that point?"

I've mildly edited it to be a bit less sweary, but I think you get the point! It took me until yesterday to reply (sorry, I recently moved house!), but I'm going to share my reply with you all below in case it helps you too.

First, congratulations on making mistakes! I know that sounds odd, but often we get so focused on not making mistakes that we forget mistakes are part of everyone's journey – trying things out, getting them wrong, and learning lessons from that experience is a fantastic way to learn, and it's even true that sometimes the only way to figure out what's right is to see what's wrong first.

One of my favorite Steve Jobs videos is him responding to a rather aggressive crowd question about some of his choices on returning to Apple. Towards the end, he says "some mistakes will be made along the way, and that's good, because at least some decisions will be made along the way." So, as hard as it might be, be happy that you're making mistakes, because it shows you're pushing yourself outside your comfort zone and learning something new.

Second, you have no idea how many mistakes I've made over the years. Lots of small ones, sure, but dozens – hundreds? – of really serious errors, some of which I'm going to regre...

But there's also one major architectural change you need to be aware of, so let's start with that…

View is now on the main actor

For a long time, the View protocol looked a bit like this:

protocol View {
    @MainActor var body: some View
}

That meant code in your view's body ran on the main actor, but code elsewhere in your view did not.

This allowed our views to do work across tasks naturally, but caused problems when using @Observable classes that ran on the main actor. For example, code like this simply wouldn't compile:

@Observable @MainActor
class ViewModel {
    var name = "Anonymous"
}

struct ContentView: View {
    @State private var viewModel = ViewModel()

    var body: some View {
        Text("Hello, \(viewModel.name)!")
    }
}

That would throw up "Call to main actor-isolated initializer 'init()' in a synchronous nonisolated context", which is a rather complex way of saying "your class says it must be on the main actor, but you're creating it away from the main actor."

When you rebuild your code with Xcode 16 that error goes away completely, and with no work from us – it's just gone. However, it's important to know why. You see, the View protocol now looks more like this:

@MainActor protocol View {
    var body: some View
}

The difference is small, but makes a huge difference: the @MainActor attribute moved from body up to the protocol itself, which means the body property along with all other properties and methods we make are run on the main actor.

You can see the impact with this sample code:

struct Co...

This is more common than you might think. In fact, several major programming languages have some kind of release that takes significantly longer than all others: Python 3 took years to arrive, PHP 6 took so long the team bailed out and jumped straight to PHP 7, and Perl 6 dragged on so much that it ended up evolving into a different language called Raku.

Swift last had major breaking changes back in Swift 3, but when enabled in full Swift's own v6 has the potential to make Swift 3 look like a walk in the park. This is partly because of new changes, but partly also because many features added in recent Swift versions have been hidden behind feature flags that will be enabled by default in Swift 6.

Let's take a look at what's changing…

• Tip: You can also download this as an Xcode playground if you want to try the code samples yourself.

Complete concurrency enabled by default

Swift 6 contains another barrage of updates around concurrency, and the team ought to be proud of the extraordinary advances they have made to make this release possible.

By far the biggest change is that complete concurrency checking is enabled by default. Unless you're very fortunate indeed, there's a very good chance your code will need some adjustment – it's no surprise the Swift team made it optional in earlier versions to give folks time to evaluate what's changing.

Swift 6 improves concurrency checking further, and the Swift team say it "removes many false-positive data-race warnings" that were present in 5.10. It also introduces several targeted changes that will do wonders to make concurrency easier to adopt – if you tried with 5.10 and found things just too gnarly to figure out, hopefully some of the changes in Swift 6 will help.

Easily the biggest is [SE-0414](https:/...

All Hacking with Swift books come with:

• A lifetime free Swift update policy, meaning that you get updates for the books you purchase at no cost, protecting your investment.
• A 30-day No Questions Asked refund policy. Not learning fast enough? Did life take a different turn? Bought the wrong thing? No problem!
• Free bonus content over and above what you paid for, and the more you collect the more you unlock!

So, whether you're looking to learn something new, take the next step in your career, or just complete your collection, now is the time.

Let's take a look at what's changing…

• Tip: You can also download this as an Xcode playground if you want to try the code samples yourself.

Data races are now clearly diagnosed

Swift concurrency was introduced back in Swift 5.5, but had a bit of a rocky adoption both in Apple's own frameworks and our own projects. However, with Swift 5.10 the team made a rather dramatic statement: "Swift 5.10 closes all known static data-race safety holes in complete strict concurrency checking."

Concurrency checking is what allows the compiler to verify our use of concurrent code is safe – that we aren't accidentally sharing mutable state in a way that can cause race conditions. Of course, the key word here is "known": everything they know about has been resolved.

Apple's work here is not only hugely innovative, but hugely complex: similar to how type inference requires the Swift compiler to be able to reason about how various parts of our code are used, in concurrency the compiler is effectively running a series of algorithms that attempt to determine conclusively that our code is concurrency-safe.

To give you a concrete example, this code generated a warning in Swift 5.9:

import SwiftUI

struct ContentView: View {
    var body: some View {
        Button("Tap Me", action: doWork)
    }

    func doWork() {
        print("Hello")
    }
}

That would throw up the rather unhelpful warning, "Converting function value of type '@MainActor () -> ()' to '() -> Void' loses global actor MainActor".

The problem here is that SwiftUI's Button view doesn't use @MainActor for its action, so Swift was throwing up a warning that we were calling a main acto...

Let's get to it…

Starting from scratch

For over 30 years, HTML has been a great language for describing the structure of web pages.

For example, we can write HTML like this:

<h1>Wise words</h1>
<p>"If you don't take risks, you can't create a future" - <em>Monkey D. Luffy</em> in <a href="https://en-wp.org/wiki/One_Piece">One Piece</a></p>

That has a heading, a paragraph of text with some emphasis, and a link to another page. But, what happens if we forget the closing </em> tag? Without it, web browsers will assume everything that follows should also be emphasized.

That's not what I intended, but it's easy to do because HTML is just a bunch of text.

But even if you write perfect HTML, there are other, bigger problems:

1. How can you make sure your pages look the same on all browsers?
2. How can you make your page adapt to different screen sizes, such as iPhone and iPad?
3. How can you use more advanced UI elements such as dropdown menus, carousels, and accordions?
4. Most importantly, how can you be sure your site is accessible to everyone?

Ultimately, all these boil down to one huge problem: most people don't have enough time to become experts in Swift and also experts in HTML.

And so I want to suggest that the answer is to not use HTML, or at least not directly. Instead, I would you like to propose that we use Swift to build our websites.

Introducing result builders

Back in 2019 when Apple announced SwiftUI there the usual What's New in Swift presentation. During that talk they showed the following HTML:

<html>
    <head>
        <title>Jess...

Doing this took quite a few steps, so I wanted to walk you through the whole process: coming up with an idea, building a prototype, visiting Apple's Vision Pro labs, fixing problems, and more. Hopefully this is useful to anyone else who is thinking about shipping for visionOS!

• If you have an Apple Vision Pro, you can download the app here
• There's a press kit with screenshot, text, and an app preview video here

About the app

The app I built is called Spatial Symphony, and it's a synthesizer controlled by hand movements.

It was born out of a very simple idea to create a theremin for Apple Vision Pro – an instrument that in real life is created by moving your hands in the air, and so seemed perfectly suited to the new hand-tracking APIs that ship with visionOS.

The idea quickly expanded into a general-purpose synth, with controls for waveform, reverb, distortion, chorus, scale snapping, and more, and I ended up shipping 20 synth presets plus a full editor UI.

You can see the app running here:

What powers it all?

Beyond Swift and SwiftUI, Spatial Symphony was made possible by three frameworks.

The first framework is AudioKit, which drives all the synth work, providing all the effects and customizations. This was a massive revelation to me: there are countless thousands of people out there with a hundred times more knowledge about audio engineering than I have, but honestly AudioKit somehow manages to make me look like a pro.

The project – completely open-source, available under the MIT license – provides a wealth of audio power for us mere mortals to lean on, ...

Once again, it's a full-day, online-only workshop event aimed at intermediate to advanced developers, and everyone who attends will have ample chance to learn new approaches, tackle coding challenges, and of course ask lots of questions.

This year we'll be focusing on three key areas of visionOS APIs:

• 2D apps built using SwiftUI. This will start small, looking at the least it takes to get your app onto visionOS, but then we'll expand to look at platform-specific adjustments so your apps feel fully at home.
• 3D apps built using RealityKit and ARKit. Once you're comfortable working in 2D, we'll start to explore 3D content as well – bringing it into existing apps effectively, but also building projects that focus specifically on a great 3D experience.
• Designing assets with Reality Composer Pro. Apple's new tool for creating content is fantastically powerful, so we'll look at how it can fit into your app development workflow.

The format is the same as last year: live-streamed videos for all attendees where I walk you through specific techniques, backed up by hands-on coding challenges where you need to apply what you've learned – it's the fastest way to get up to speed with building great apps for visionOS.

All sessions take place January 27th, from 9am to 4pm US Eastern time. They will be recorded, and you'll be able to download the videos afterwards.

Tickets cost $100 each, but Hacking with Swift+ subscribers get access free. If you aren't already a Hacking with Swift+ subscriber, you can sign up before the event to get your free ticket – find out more here.

I'm also offering two other ticket types:

1. A diversity sponsor ticket, which is for folks who already have a ticket and want me to give one ticket away to someone who would otherwise not be able to attend.
2. ...

Note: This project requires some Swift and SwiftUI knowledge, but I'll do my best to explain all the SwiftData things along the way. We'll be targeting iOS 17, so you need Xcode 15 or later.

• Download the finished source code for this project here.

Bringing SwiftData into the project

Start by making a new iOS project called FaceFacts, making sure to choose SwiftUI for the interface. Although we'll be using SwiftData here, please leave the Storage option as None so that Xcode doesn't bring in lots of extra code we don't need.

There are three small steps required to bring SwiftData into an app:

1. Defining the data you want to work with.
2. Creating some storage for that data.
3. Reading the data wherever you need it.

The first thing we'll do is design our data. This will be simple at first, but we'll add more over time. For now we'll store just three pieces of information: their name, their email address, and a free text field where you can add any extra information you want.

So, start by creating a new Swift file called Person.swift, which we'll use to store the SwiftData class describing a single person in our app. This means adding an import for SwiftData, then adding this class:

class Person {
    var name: String
    var emailAddress: String
    var details: String
}

You'll need to create an initializer for that because it's a class, but typing "in" inside the class should prompt Xcode to create one automatically for you:

class Person {
    var name: String
    var emailAddress: String
    var details: String...

I want to help folks get started with Metal, so I've produced two free resources that will help everyone:

• Inferno is an open-source library of Metal shaders written for SwiftUI, giving you a range of powerful special effects in just a few lines of code.
• I released a new YouTube video where I walk through how to create Metal shaders for SwiftUI from scratch. It lasts over an hour, so there's lots of detail there.

Inferno is a project that makes Metal shaders easy for everyone to use, but I've also gone a step further and added comprehensive documentation explaining exactly how each shader works so that others can learn too.

I've also produced a walkthrough video for Inferno so you can get an overview of the project before downloading it.

But there's more: over on Hacking with Swift+ I'm working on a large tutorial series teaching exactly how to build your own shaders, piece by piece, going into lots of detail on the Metal shading language. Part 1 of that series is already available – check it out!

This is all powered by new APIs introduced in iOS 17 and other coordinated releases – we get complete control over how our views are rendered, and now with only a handful of lines of Metal shading language we can produce some really remarkable results.

As part of that, I teach five key concepts that – so I believed – helped make sure most apps provided a great accessibility experience out of the box:

1. Using native controls rather than making your own, including using VStack and HStack in SwiftUI to provide a clear structure for assistive tools to follow.
2. Adding short descriptions of views using accessibilityLabel(), keeping longer descriptions for accessibilityHint() for users who have that enabled.
3. Grouping views together using accessibilityElement() so VoiceOver treats them as atomic units.
4. Marking images as decorative when they shouldn’t be read by VoiceOver.
5. Using Dynamic Type everywhere, to make sure our interfaces scale smoothly no matter what someone’s settings are.

Those five do help provide a great experience for many people, but while at WWDC23 one of the teams at Apple very gently pointed out that I was missing a key component – and in doing so creating a pretty awful accessibility experience for many people.

So, here’s the sixth item I’m putting on the list of things I’ll be teaching everywhere: using accessibilityInputLabels() to provide custom activation commands for Voice Control.

This modifier accepts an array of localizable strings that can be used by the user to activate a control. You can provide as many as you want, and the system will listen for all of them – it gives the user a little leeway, and hopefully means they never need to use “Show Names” to figure out how to activate something.

You can see the problem, and also how accessibilityInputLabels() solves it, in this code:

NavigationStack {
    List {
        NavigationLink {
            Text("Details about toda...

Some of these are things I’ve asked for personally, including the ability to add Metal shaders, making Color work better with Codable, adding a completion closure for animations, allowing us to animate gradients, and being able to selectively round corners of a rectangle – I’ve closed at least a dozen feedbacks just from beta 1!

Scroll view improvements

• How to make a ScrollView snap with paging or between child views
• How to disable ScrollView clipping so contents overflow
• How to make a ScrollView start at the bottom
• How to indent the content or scroll indicators in a ScrollView
• How to make views scroll with a custom transition
• How to flash the scroll bar indicators of a ScrollView or List
• How to enable vertical page scrolling

Drawing and animation improvements

• How to add Metal shaders to SwiftUI views using layer effects
• How to dynamically adjust the appearance of a view based on its size and location
• How to animate SF Symbols
• [How to run a completion callback when an animation finishes]...

As a reminder, Hacking with Swift Live is a charity-focused event where all ticket and sponsor revenue goes to help folks experiencing homelessness. So, you get to learn Swift, make new friends, and also help people in need!

Get your Hacking with Swift Live ticket here

• Looking for more information about the event? Find everything you need to know here.

Schedule

Hacking with Swift Live takes place June 26th-27th, from 9am to 4pm US Eastern time. I’ll walk you through new features, then give you chance to ask questions, and try challenges yourself – everyone will have lots of time to experiment with the code and really get to grips with it!

On day one we’ll be exploring the key changes to Swift this year, focusing specifically on the things that are likely to help make code easier to write or maintain. We’ll then dive straight into the many and varied SwiftUI improvements this year, building a real project that ties them all together as you learn.

On day two we change tack and move over exclusively to SwiftData. This is a huge new framework that unlocks almost all of Core Data’s power with almost none of Core Data’s complexity – it will completely change the way we write apps. We’ll be looking at this topic from a number of perspectives, including:

• The basics of getting started
• Advanced uses, including data migrations and shared storage
• Upgrading existing Core Data apps
• Architectural issues, including using MVVM

If we still have time left over we’ll also explore a little of what visionOS development looks like,...

In this article I’ll walk you through the most important changes in this release, providing code examples and explanations so you can try it all yourself. You’ll need the latest Swift 5.9 toolchain installed in Xcode 14, or the Xcode 15 beta.

• Tip: You can also download this as an Xcode playground if you want to try the code samples yourself.

if and switch expressions

SE-0380 adds the ability for us to use if and switch as expressions in several situations. This produces syntax that will be a little surprising at first, but overall it does help reduce a little extra syntax in the language.

As a simple example, we could set a variable to either “Pass” or “Fail” depending on a condition like this:

let score = 800
let simpleResult = if score > 500 { "Pass" } else { "Fail" }
print(simpleResult)

Or we could use a switch expression to get a wider range of values like this:

let complexResult = switch score {
    case 0...300: "Fail"
    case 301...500: "Pass"
    case 501...800: "Merit"
    default: "Distinction"
}

print(complexResult)

You don’t need to assign the result somewhere in order to use this new expression syntax, and in fact it combines beautifully with SE-0255 from Swift 5.1 that allows us to omit the return keyword in single expression functions that return a value.

So, because both if and switch can now both be used as expressions, we can write a function like this one without using return in all four poss...

It’s called Swift Against Humanity, and the rules are both dazzlingly simple and also surprisingly similar to some other games you might have previously heard of: one player places a black card on the table that contains a question or part of a sentence, and all other players play one white card they think best completes it. The first player then shuffles the white cards, reads them out, then picks a winner – it’s literally minutes of fun.

Pre-orders for Swift Against Humanity start tomorrow, with the first deliveries going out in the next week or so. Plus, we’re pleased to announce three incredible editions:

• Swift Against Humanity Standard Edition: for the language purists out there.
• Swift Against Humanity Enterprise Edition: for all you folks busy building with Swift Enterprise Edition.
• Humanity Swift Concurrency Against Edition: for all developers who just love adding concurrency in places it really doesn’t belong.

Swift Against Humanity was developed in conjunction with legendary game designer [Daniel Leivers](https://twitter.com/s...

In this article I’m going to walk you through the most important changes this time around, providing code examples and explanations so you can try it all yourself. You’ll need Xcode 14.3 or later to use this, although some changes require a specific compiler flag before Swift 6 finally happens.

• Tip: You can also download this as an Xcode playground if you want to try the code samples yourself.

Lift all limitations on variables in result builders

SE-0373 relaxes some of the restrictions on variables when used inside result builders, allowing us to write code that would previously have been disallowed by the compiler.

For example, in Swift 5.8 we can use lazy variables directly inside result builders, like so:

struct ContentView: View {
    var body: some View {
        VStack {
            lazy var user = fetchUsername()
            Text("Hello, \(user).")
        }
        .padding()
    }

    func fetchUsername() -> String {
        "@twostraws"
    }
}

That shows the concept, but doesn’t provide any benefit because the lazy variable is always used – there’s no difference between using lazy var and let in that code. To see where it’s actually useful takes a longer code example, like this one:

// The user is an active subscriber, not an active subscriber, or we don't know their status yet.
enum UserState {
 ...