The main thread and run loop

One turn of the loop

You can picture the main thread doing this, forever:

1. Sleep until an input source or timer fires.
2. Call your code: a gesture handler, a body evaluation, a timer callback, a block queued with DispatchQueue.main.async, a main-actor task resuming.
3. Lay out and commit any UI changes, so the next frame can show them.

While step 2 runs, steps 1 and 3 can't. A slow handler doesn't just delay itself: it delays every touch and every frame after it. Apple's responsiveness guide puts a discrete delay above 100 ms in "hang" territory, and suggests keeping the main thread's work for a frame under about 5 ms, since a 120 Hz display gives you 8.3 ms in total.

Keep the UI on main, the rest off it

UI objects aren't thread-safe. Changing a view or a value SwiftUI observes from a background thread can corrupt state or crash, and Xcode's Main Thread Checker reports such calls while you debug. The pattern is: do heavy work elsewhere, then come back to the main thread to show the result.

1@MainActor2final class PhotoViewModel {3    var thumbnail: UIImage?4 5    func load(file: URL) async {6        let image = await Self.makeThumbnail(file)   // runs on the thread pool7        thumbnail = image                            // back on the main actor8    }9 10    // @concurrent (Swift 6.2) means "run on the thread pool, not on the caller's actor".11    // In Swift 6.0 and 6.1, write nonisolated instead: that already ran async code off the actor.12    @concurrent static func makeThumbnail(_ file: URL) async -> UIImage? {13        guard let data = try? Data(contentsOf: file) else { return nil }14        return UIImage(data: data)?.preparingThumbnail(of: CGSize(width: 200, height: 200))15    }16}

With Swift concurrency, "the main thread" is spelled @MainActor, and the compiler checks it for you; with Grand Central Dispatch it is DispatchQueue.main. The idea is the same. One caution from Apple's guide: hopping back to the main thread costs something too, so don't schedule work there that doesn't need to be there, not even asynchronously.

Run loop modes

A run loop runs in a mode that decides which sources it listens to. While a scroll view is tracking a finger, the main run loop switches to a tracking mode, and a Timer scheduled in the default mode stops firing until the scroll ends. Adding the timer to the common modes keeps it running:

1let timer = Timer(timeInterval: 1, repeats: true) { _ in updateClock() }2RunLoop.main.add(timer, forMode: .common)

You rarely manage run loops yourself (secondary threads only have one if you run it), but knowing the main thread is a loop explains most "why didn't my UI update" and "why did it freeze" questions.