A migration is easier to diagnose when language-mode changes and feature changes are separate. Preserve behavior first, then fix isolated compiler failures with small checkpoints.

Baseline tests → Toolchain change → Scoped fixes → Same acceptance suite
  1. 1Baseline tests
  2. 2Toolchain change
  3. 3Scoped fixes
  4. 4Same acceptance suite

Work through the example

Record the old and new build settings. Do not silence concurrency diagnostics by changing semantics without a test.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

Sendable Protocol

Sendable marks types that are safe to transfer across concurrency domains.

// Value types with Sendable fields are implicitly Sendable
struct UserDTO: Sendable {
    let id: String
    let name: String
    let email: String
}

// Classes must be final and have only immutable stored properties
final class Configuration: Sendable {
    let apiKey: String
    let baseURL: URL

    init(apiKey: String, baseURL: URL) {
        self.apiKey = apiKey
        self.baseURL = baseURL
    }
}

// @unchecked Sendable — when you manage thread safety manually
final class AtomicCounter: @unchecked Sendable {
    private let lock = NSLock()
    private var _value = 0

    var value: Int {
        lock.withLock { _value }
    }

    func increment() {
        lock.withLock { _value += 1 }
    }
}

// @Sendable closures
func performAsync(_ work: @Sendable @escaping () async -> Void) {
    Task {
        await work()
    }
}

// Common Sendable conformances
// - All value types with Sendable properties
// - Actors (always Sendable)
// - Enums with Sendable associated values
// - Tuples of Sendable types

Acceptance and failure review

Checkpoint What to inspect If it does not match
Baseline tests Confirm the input and environment Preserve the failure and return to this step
Toolchain change Inspect the intermediate artifact Preserve the failure and return to this step
Scoped fixes Run the focused check Preserve the failure and return to this step
Same acceptance suite Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

A complete old-project migration to iOS 27 has not been executed here.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Ask for the finding, not the fix: why review-first prompts produce better Swift