Stanford CS193p： iOS Development with SwiftUI ｜ L15： Multithreading — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CS193p: iOS Development with SwiftUI | 2025 | L15: Multithreading

Instructor Bio: This lecture is delivered by Paul Hegarty, Lecturer in Computer Science at Stanford University and the principal instructor of CS 193P since 2010. Paul Hegarty is a veteran software engineer and educator with deep roots in the Apple developer ecosystem. Earlier in his career he worked at NeXT Computer, where he contributed to the Objective-C language and the foundational tools that would eventually become Apple's modern development platform. He has taught iOS application development at Stanford for over fifteen years, guiding thousands of students through the transition from earlier UIKit frameworks to the modern SwiftUI declarative paradigm. He is widely recognized for his methodical teaching style, his emphasis on clean architectural patterns such as MVVM, and his ability to explain complex systems concepts through hands-on, live-coding demonstrations.

Course Description: This lecture covers multithreading and concurrency in Swift, essential for building responsive applications that perform work without freezing the user interface. It explains the @MainActor for UI updates, background dispatch queues for offloading heavy work, and Swift's modern async/await pattern for structured concurrency. The lecture also covers actors for safe shared mutable state, the Sendable protocol for thread-safe types, and demonstrates how to integrate multithreaded operations into a SwiftData-backed application while avoiding data races and maintaining UI responsiveness.

These notes cover Stanford CS193p Lesson 15 on multithreading. The lecture mixes hands‑on SwiftUI and Swift‑data demo fixes before diving deep into multithreading and Swift’s modern concurrency system. A lot of practical code tweaks get shown first, then the conceptual heavy‑lifting around multithreading begins. I tried to capture both the working examples and spots that felt confusing while listening.
 

Demo refinements before multithreading discussion

The lecturer opens with code tweaks to their existing Codebreaker app, unrelated to multithreading at first glance, but these examples reinforce SwiftUI animation, Swift Data predicates, and model‑database interactions.

First up was adding animation to search results. Previously sorting list items had smooth built‑in animations, but text‑driven search did not animate view changes. They solved this by attaching an implicit animation tied to the search text value. Every time the search field content changed, the resulting list updates would animate. This illustrated how implicit animations respond when their watched value mutates, even for search‑driven filtering workflows.

Next they added a new sorting filter option to only display completed games. They added a new enum case for completed within the sorting options. Right away Xcode threw compiler errors because switch statements over enums must cover every case. This is a helpful built‑in safety feature of Swift enums; adding a new case forces you to revisit every place that switches over that enum.

This is where the first tricky bug appeared. They tried to filter Swift Data results inside a predicate checking if a game was finished using a computed property isOver. The app crashed immediately. The lecturer explained why: predicates compile down to SQL queries that run inside the database layer. The database cannot evaluate Swift‑side computed properties. Only actual stored model fields persist inside the database and can be used for filtering queries.

Two potential fixes got discussed. The first approach converted isOver from a computed property into a stored Boolean model field. This meant manually updating this Boolean everywhere game state changed: on game startup, when users submit guesses that solve the puzzle, and when restarting games. The downside is extra bookkeeping work. You now have to remember to set this value correctly across multiple code locations, and you risk state getting out‑of‑sync if you forget one spot. The upside is game completion logic stays encapsulated within the model instead of living inside a UI‑layer predicate.

The second workaround kept isOver as a computed property. Instead they wrote a complex predicate that traversed related database tables directly. It checked whether any stored guess attempt matched the target solution code. This crashed at first too, because they referenced a computed wrapper property instead of the actual underlying stored database variable with an underscore prefix. After switching to the backing storage variable, the predicate worked. It performed cross‑table joins entirely within the database.

When they polled the class audience, most students preferred the first solution with the stored Boolean. The lecturer agreed with this preference. Even with manual state updates, keeping business logic inside the model felt cleaner than building huge, fragile query expressions in view‑layer code. Still, the second example was useful to show how powerful Swift Data predicates can be for joining multiple tables.

Another small but interesting bug they fixed involved tracking elapsed game time. The app tracked how long users spent playing each game, but this elapsed value only saved to the database when views disappeared or app scene phases shifted. If users kept a game view open continuously, the auto‑save mechanism never wrote the most recent elapsed time value to disk.

Their fix tapped into notification center publishers. They subscribed to the ModelContext willSave notification, which fires right before Swift Data writes changes to storage. Using the onReceive view‑modifier they ran a method to refresh elapsed time every time a database save was about to happen. The update method reused existing timer logic: pause then immediately restart the timer, which internally persisted the latest elapsed value. This lived inside a dedicated view‑modifier file they created for elapsed‑time tracking logic.

One point that was hard to follow here is how notification center publisher lifetimes work inside view modifiers. The lecturer skimmed over memory‑management risks, just demonstrating the functional result. They noted this pattern is somewhat niche and newer SwiftUI APIs have reduced how often developers need to work directly with notification center.
 

Core multithreading & Swift concurrency fundamentals

After wrapping up all the demo code repairs, the lecture shifts focus fully to multithreading. The most important practical ground rule they emphasized: never block your user interface. Even brief UI freezes create terrible user experiences. Any slow operation, like network downloads or heavy CPU computation, cannot run on the main UI thread. Multithreading lets you run slow work in the background while the UI stays responsive.

Multiple execution threads can run code concurrently. On multi‑core hardware they truly run in parallel; on single‑core hardware the operating system time‑slices execution to simulate parallel work. As application developers you mostly don’t need to care about that hardware distinction. You just model that multiple pieces of your program can progress simultaneously.
Multithreading’s big danger is data races. If two threads read and modify the same shared mutable data at overlapping times, data can get corrupted, leading to random crashes or broken state. Traditional manual thread management is error‑prone. Swift’s modern concurrency model removes the need for developers to manually spawn raw threads. The runtime handles thread creation and scheduling, but we still need to mark which pieces of work can safely run concurrently.

Three big conceptual building blocks frame Swift concurrency: actors and isolation, suspension/await, and the difference between synchronous versus asynchronous execution contexts.
Actors act as synchronization boundaries. They are reference types similar to classes, but they cannot use inheritance. An actor enforces serial execution: only one piece of its code can run at any given time. Any function or property access inside an actor waits for its turn. This eliminates most data‑race risks for state held inside the actor.

A key rule for actor code: functions run to full completion OR pause explicitly at suspension points. They cannot get arbitrarily interrupted mid‑execution anywhere. Suspension points are marked by await. Functions capable of suspending must be annotated async. If a function lacks the async keyword it cannot suspend, it must run all the way through without pausing.
When you call an async function you must write await. This signals to both compiler and human readers that execution might suspend at this location. When suspended the actor can run other work while waiting for something slow like a network call. Once the awaited operation finishes execution resumes from right after the await statement.

One critical warning the lecturer stressed: after resuming from an await, shared state might have changed. Other work on the actor could have mutated data while you were suspended. Old saved indices or references can become invalid. You need to re‑validate state after coming back from an await.

You can only use await inside an asynchronous context. Two ways to get an async context: mark your function with async, or wrap code inside a Task closure. Tasks start off background concurrent work from normal synchronous code. Several SwiftUI view modifiers like .task and .refreshable automatically create async contexts for their closure arguments. The .task view modifier is especially handy: it starts when the view appears and automatically cancels itself when the view disappears.
 

Sendable types

Cross‑actor function arguments need to conform to the Sendable marker protocol. Sendable has no required methods. It is a compile‑time guarantee that this value can safely pass across actor boundaries without creating data races.

Value types (structs) composed entirely of other Sendable types are automatically Sendable. Actors themselves are always Sendable. Most regular classes are not Sendable because they are freely mutable. Closures can be marked @Sendable to enforce they only capture Sendable values. If you pass non‑Sendable values across actor boundaries you risk concurrent mutation bugs.
 

Main Actor

The @MainActor is a built‑in global actor. Every SwiftUI view automatically runs on the main actor, so all your view body code, @State variables, and view‑modifier closures are main‑actor‑isolated. This keeps all UI work serialized and thread‑safe.

You should never run long‑running heavy computation on the main actor, because that will freeze the UI. But @MainActor is a quick, practical tool for small‑scale concurrency work. You can apply @MainActor to individual variables, functions, or an entire class. Anything annotated will execute on the main actor’s serial queue.

If you are inside non‑isolated background code and need to run work on main actor, you can create a task with @MainActor in on its closure, or use MainActor.run(). The lecturer preferred the task‑based syntax.

The lecturer walked through the Words.swift demo file that downloads word data over the network. It uses Task to create an async context so it can perform network operations. They demonstrated for‑await‑in for async sequences, which yields pieces of data incrementally, such as lines coming in over a network connection. Each iteration is a potential suspension point.

The original Words class was not concurrency‑safe. It held shared mutable state without actor protection. It happened to work in their demo because in practice they only wrote the dictionary once then read‑only afterwards. If multiple threads wrote to it, data races would occur.

When enabling Swift 6 strict concurrency checking, the compiler points out these unsafe spots. Adding @MainActor to the whole class makes all its properties and methods isolated to the main actor, fixing many concurrency warnings. But new issues pop up. For example @EnvironmentKey infrastructure does not support main‑actor‑isolated default values. The lecturer noted these are still rough edges in the Swift toolchain that Apple will likely resolve over time. Other minor warnings popped up for things like certain transition objects and key paths inside predicates, also known unresolved pain points.
 

Unanswered points & open rough edges in the lecture

This section covers things the lecturer flagged as unresolved or that left me with lingering questions.

Strict concurrency checking in Swift 6 produces compile errors for parts of common SwiftUI infrastructure. Environment keys cannot have @MainActor‑isolated default values, some view transitions and key‑path expressions do not conform to Sendable yet. The lecturer said these are known gaps, and we cannot fully fix them ourselves without rewriting framework internals. There was no complete workaround shown for the environment‑key limitation. They mentioned they might post supplementary material for this after class, but we do not see that in the lecture recording.

Also, while they explained actors prevent data races for state owned inside the actor, less time was spent on patterns for sharing state across multiple different actors. They touched on Sendable but did not go deep on real‑world error handling for failed network tasks, task cancellation patterns beyond .task view modifier automatic cancellation. The Words.swift example glossed over network failure handling entirely, focusing purely on the concurrency mechanics.

The notification‑center‑based ModelContext willSave trick worked for their demo, but they did not cover edge‑cases like multiple overlapping saves or tearing down subscriptions when a view goes away. I wondered what happens if the notification publisher keeps firing after the view has been destroyed, though they quickly noted this pattern is not commonly used in modern SwiftUI.
 

Practical advice for final student projects

Towards the lecture’s end, the lecturer shifted to advice for class final projects.

He urged students not to procrastinate. Three‑week projects benefit from steady incremental work. Coding problems often become clearer after stepping away and sleeping on them. If you cram everything to the final week you will struggle to absorb new APIs and debug tricky concurrency or networking issues.

Using AI or online tutorials is acceptable for the project. Just remember to give credit when you rely on outside code snippets. Use sample code you find as a learning opportunity to understand how async/await and tasks work under the hood.

He encouraged students to branch out beyond the APIs covered in lecture. Try maps, Swift Charts or other third‑party frameworks. Figuring out new documentation and sample code is an important learning exercise. Most student projects will not need custom actor types. In many cases @MainActor will be sufficient for small‑scale background work like downloading files. If you need heavy‑duty parallel CPU‑bound work you would define your own custom actor, but he expected very few students would go that far.