Getting Rork Max's Swift Through Swift 6's Strict Concurrency Checking

Sorting the non-Sendable types into three buckets

Of the 134 warnings at the end of week one, 96 were some flavor of "type does not conform to Sendable." Treating them uniformly would have been a mistake. I split them three ways.

Bucket A was mechanical. Generated code reaches for class readily, but most of those types were never mutated after init. Turning final class into struct and var into let gets Sendable for free.

Bucket B needed a design decision. The thumbnail memory cache started here:

actor ThumbnailCache {
    private var storage: [Wallpaper.ID: CGImage] = [:]
    private let limit: Int
 
    init(limit: Int = 240) { self.limit = limit }
 
    func image(for id: Wallpaper.ID) -> CGImage? { storage[id] }
 
    func insert(_ image: CGImage, for id: Wallpaper.ID) {
        if storage.count >= limit { storage.removeAll(keepingCapacity: true) }
        storage[id] = image
    }
}

Making it an actor turns every call site into an await. Calling await cache.image(for:) while rendering a scrolling cell means the image arrives one frame late. That path needed a synchronous fast read.

So I moved the reads onto NSCache, which is already thread-safe, and declared Sendable by hand.

final class ThumbnailCache: Sendable {
    private let cache = NSCache<NSString, CGImage>()   // thread-safe
 
    nonisolated func image(for id: Wallpaper.ID) -> CGImage? {
        cache.object(forKey: id.rawValue as NSString)
    }
 
    nonisolated func insert(_ image: CGImage, for id: Wallpaper.ID) {
        cache.setObject(image, forKey: id.rawValue as NSString)
    }
}

actor is not a universal escape hatch. Where a synchronous read is part of the performance contract, delegating to a thread-safe type and claiming Sendable yourself is the more honest answer.

Three conditions for allowing nonisolated(unsafe)

The 12 warnings in bucket C came from types I don't own — an MLModel handle, a PDFKit drawing context.

nonisolated(unsafe) silences the checker. The safety argument moves from the compiler to you. Sprinkled freely, it dissolves the entire reason for migrating.

I allow it only when all three of these hold.

First, access to the value is confined to a single isolation domain — in practice, reachable only from inside a @MainActor type or a dedicated actor.

Second, that confinement is verifiable from the code. Mark it private so it can only be reached through published methods.

Third, a one-line comment records why it is safe. "Framework limitation" is not enough. Write down who owns it and who cannot touch it.

@MainActor
final class DepthRenderer {
    // nonisolated(unsafe): MLModel is not Sendable, but this instance never
    // escapes DepthRenderer (@MainActor) and is read-only after init.
    // model.prediction(from:) serializes internally.
    nonisolated(unsafe) private let model: MLModel
 
    init(model: MLModel) { self.model = model }
}

To keep those 12 from quietly becoming 30, CI counts them.

#!/usr/bin/env bash
# scripts/check-unsafe-isolation.sh
set -euo pipefail
BASELINE=12
COUNT=$(grep -rn "nonisolated(unsafe)" Sources/ --include='*.swift' | wc -l | tr -d ' ')
 
if [ "$COUNT" -gt "$BASELINE" ]; then
  echo "❌ nonisolated(unsafe) increased: ${COUNT} > ${BASELINE}"
  grep -rn "nonisolated(unsafe)" Sources/ --include='*.swift'
  exit 1
fi
echo "✅ nonisolated(unsafe): ${COUNT} (baseline ${BASELINE})"

A baseline rather than zero, because a rule nobody can satisfy is a rule somebody deletes. Freeze the current number, never grow it, lower the baseline when the count drops. Mine went from 12 to 9 over the past month.

Measured results — what improved, what got worse

A migration ships no features. Without numbers, three weeks becomes hard to justify even to yourself. Measurements below are on a physical iPhone 15 Pro, release configuration, median of 20 runs.

Build time grew, plainly — 24%. That is the cost of the checking, and there is nothing to do but accept it.

The 0.18s improvement in first grid paint was a side effect. Straightening out the isolation boundaries moved decoding off the main thread. Strict concurrency checking doubles, in practice, as a static detector for "what is blocking your main thread."

The seven crashes had been sitting in Crashlytics as EXC_BAD_ACCESS. Two causes: concurrent writes into the image cache dictionary, and a @Published update fired from a notification handler. The compiler pointed at both during the migration. I had been carrying them for roughly six months as "crashes I cannot reproduce," watching them tick up in the dashboards of two shipped apps.

Of everything the migration gave back, that is the part that lifted the most weight.

How generated code and Swift 6 get along

Code from a tool like Rork Max is idiomatic Swift 5. That is what the training data looks like, and it isn't a criticism.

The friction on the way to Swift 6, though, has a distinct shape. Three patterns kept recurring.

Overuse of class. Even stateless types arrive as final class. During migration, ask mechanically whether the type is ever mutated after init, and demote the ones that aren't. That covered most of the 71 in bucket A.

Static mutable singletons. static var shared always warns under complete. The choice is static let, @MainActor static let, or an actor. Six of my eight became static let.

Task { } blocks mutating View state directly. These disappear on their own once @MainActor lives on the store.

Which means: patch those three the day the code is generated, and the migration bill drops sharply later. When I start a new app now, I split the SPM targets on day one and begin CoreModels on v6 immediately. Far cheaper than meeting 217 warnings a year in.

Where to start

Migrating to Swift 6 looks like satisfying a compiler. It is really the work of writing down, everywhere, who owns which piece of state. Generated code does not contain that answer. Supplying it is the job of whoever operates the app.

If you want a first step in your own project, carve out one small leaf module and set only that target to .swiftLanguageMode(.v6). One target's worth of red can go green in an afternoon, and the feel of it will make the rest of your estimate far more honest.

I'm still carrying nine nonisolated(unsafe) annotations of my own, so I'm very much still learning here. If this saves you a few of the wrong turns I took, I'd be glad.