Woo iOS Swift 6 Migration

WooCommerce iOS Swift 6 migration

Make small changes in the requested scope. Verify each change. For diagnosis or review requests, read the code without changing it. Change the Swift language mode or target scope only when requested.

Check the build settings and measure warnings

Read the repository instructions and the documentation for the affected module. Check these settings before you analyze warnings:

• Xcode and Swift versions.
• Swift language mode.
• Strict-concurrency level.
• Default actor isolation.
• Enabled upcoming features.

Identify the affected targets and dependencies.

The strict-concurrency level has three sources. In order of precedence, they are the xcodebuild command line, the target build settings, and the project build settings. Swift package targets ignore the Xcode build settings. They use only the command-line value or swiftSettings in Modules/Package.swift. Pass SWIFT_STRICT_CONCURRENCY=complete on the command line, or package targets are not measured. The command-line value also overrides target-level fences. The WordPressAuthenticator target keeps a trailing -strict-concurrency=minimal in OTHER_SWIFT_FLAGS for this reason. Do not change WordPressAuthenticator. It is fenced on purpose, and Swift 6.3.3 crashes while formatting one of its diagnostics under complete checking.

Do not set SWIFT_DEFAULT_ACTOR_ISOLATION = MainActor on a whole target. On the pinned toolchain, it caused compiler crashes, an optimizer crash in Release-Alpha archives (swiftlang/swift#88173), and XCTest crashes in swift_task_deinitOnExecutorMainActorBackDeploy. Its warning counts are not comparable with normal measurements. Use explicit @MainActor, nonisolated, and Sendable declarations instead.

Use the repository build, test, and simulator workflows. To measure workspace warnings, use the existing script with a new DerivedData directory:

Scripts/StrictConcurrency/count-warnings.sh /tmp/<task>-before.json

Read the script before you change its build settings. For a smaller scope, select the affected scheme and an available simulator. Use build-for-testing with SWIFT_STRICT_CONCURRENCY=complete. Use a separate DerivedData directory for each build configuration. Check disk space before large builds.

Save the build log. Record warnings by target, file path relative to the repository, and diagnostic text. Use the same build scope and settings before and after the change. Remove repeated compiler output with the same method in both logs. Compare warnings without line and column numbers. Keep the file path and number of occurrences.

Use a clean build for each measurement. If you use an incremental build, confirm that every measured file compiled. An incremental log can omit unchanged files. Use a partial build result only if every file in the measured scope compiled. Do not use a partial build to measure the workspace or update its baseline.

The CI toolchain in .xcode-version is authoritative. A different local Xcode produces a different warning set. For example, local Xcode 26.2 measured 10,992 warnings where CI's Xcode 26.6 measured 11,158. Some Xcode versions cannot compile trunk at all. Label local counts as local.

Record the base commit, head commit, and toolchain used for measurement. For stacked PRs, identify changes from the parent PR separately. The baseline guard is advisory. It can report warnings already on trunk. Its parser counts all Swift warnings in the repository. Check the base result and original diagnostics before you attribute new warnings to the change. Label estimates separately from measured counts. Check incomplete or repeated log lines before you change the baseline. See the guard discussion and inherited regressions.

Select and apply isolation

Start at the warning. Check the owner, protocol, conformers, direct callers, and dependencies. Before you edit code, identify which actor owns each value or operation:

Apply isolation to the required declarations and callers. Stop where the existing code has isolation that the compiler checks. Keep construction order, service lifetime, cancellation, retry, cached state, and UI presentation unchanged. Build after each isolation change. Check for new warnings in callers.

Isolation violations are errors, not warnings, at every strictness level. A synchronous call from nonisolated code to a @MainActor member of the same module fails under minimal and Swift 5 too. Only Sendable diagnostics are warnings at that level. Change every nonisolated caller in the same commit, including tests. Emit-module stops at the first error, so each hop of callers costs one build. Change the obvious callers together before you build. See the product image handler.

When a slice must change a shared contract, such as a widely used protocol or a closure type, change it in place. Do not add a parallel API to keep the baseline guard flat. Swift cannot overload on @Sendable alone. Do not deprecate the old API either, because the guard counts deprecation warnings too. Raise the affected baseline entries in the same PR and explain why. Later slices lower them.

Some diagnostics show an architectural boundary, not a missing annotation. An example is "non-Sendable parameter type cannot be sent from caller of protocol requirement into main actor-isolated implementation". It needs a decision about the isolation contract of that boundary. Stop and report the decision to the user. Do not treat it as a mechanical fix.

Read the reference that applies to the change:

• Recurring patterns: timers, environment and preference defaults, deinitialization, isolated conformances, initializers, default arguments, framework callbacks, test isolation, and test fixtures.
• Session service boundaries: POS eligibility, session construction, publishers, protocol witnesses, legacy async remotes, and Action completions.
• Runtime boundaries: language-mode switches, mixed Swift 5/6 callbacks, compiler crashes, supported OS runtimes, shared target sources, and callback-to-async changes.

For general Swift concurrency guidance, use the swift-concurrency skill if available. Otherwise, read the public Swift Concurrency skill. Read only the reference needed for the diagnostic. Resolve its relative links from the upstream skill directory. Check guidance against the active toolchain. Keep this repository's scope and verification rules.

If complete isolation needs a larger migration, use a limited adapter when possible. The compiler must check its isolation, and it must keep the same behavior. Describe the remaining work and when to remove the adapter. Expand ServiceLocator or StoresManager only when the required ownership change justifies it.