DEV Community: Mike Salari

Your SwiftUI app works. Production is where it starts lying to you.

Mike Salari — Tue, 27 Oct 2026 14:00:00 +0000

A SwiftUI screen can be completely correct in development and still have the wrong production model.

The request returned. The list rendered. The state changed when it was supposed to change. Everything worked, on the simulator, with fixture data, with one person tapping in a predictable order. Then real timing arrived, then real data, then real users, and the screen began reporting things that were no longer true.

None of the failures below start with a missing SwiftUI modifier. They are not the kind of bug a component reference can catch, because the UI already works when they appear. They show up when the system underneath the view has to answer questions the happy path never asked: which result still owns the screen, where the expensive work actually happens, and who owns this state and for how long.

Three cases. Each is small enough to reproduce in an afternoon and common enough that you have probably shipped at least one of them.

1. The latest request is not necessarily the latest result

Take a search field backed by an async API. Every keystroke calls search, every call starts a task, and every task writes its results when it finishes.

@MainActor
@Observable
final class SearchModel {
    var results: [SearchResult] = []

    private let api: SearchAPI

    init(api: SearchAPI) {
        self.api = api
    }

    func search(_ query: String) {
        Task {
            do {
                self.results = try await api.search(query)
            } catch {
                // Real failure policy goes here.
            }
        }
    }
}

The user types swift, then a moment later swiftui. Two requests are in flight. The second one hits a warm cache, or gets a faster connection, or simply has less to return, and it completes first. The screen shows results for swiftui. Then the older request for swift completes and overwrites them. The user is now looking at results for a query they are no longer asking.

Nothing in this sequence failed. Both requests succeeded. Both writes to results happened on the main actor, one at a time, so there is no data race for the compiler or the sanitizer to catch. Every mutation was legal. The UI is still wrong.

It is tempting to file this under concurrency and reach for cancellation. Cancellation helps, but it is cooperative: a request that has already returned cannot be un-returned, and a task that checks for cancellation late will still publish. async/await orders the steps inside one task. It says nothing about which of several completed tasks still has the right to publish state. That is a question about intent, and only the model can answer it, because only the model knows what the user asked for most recently.

The smallest correction that proves this diagnosis is to give each request an identity and let only the newest one write.

@MainActor
@Observable
final class SearchModel {
    var results: [SearchResult] = []

    private let api: SearchAPI
    private var generation = 0

    init(api: SearchAPI) {
        self.api = api
    }

    func search(_ query: String) {
        generation += 1
        let requestGeneration = generation

        Task {
            do {
                let results = try await api.search(query)

                guard requestGeneration == generation else {
                    return
                }

                self.results = results
            } catch {
                // Real failure policy goes here.
            }
        }
    }
}

generation is incremented synchronously, on the main actor, before the task starts, so the comparison after the await is against whatever value the newest call left behind. A stale result is not an error. It is a result that has lost the right to be shown, and it is dropped. If the API supports it, cancelling the previous task on top of this saves work, but the guard is what makes the screen correct. Cancellation is an optimisation of it, not a substitute for it.

Request lifetime and user intent are not the same thing. A request lives until it returns. The user's intent lives until the next keystroke. The state has to follow the intent.

2. "It is lazy" is not "it is fast"

The second failure arrives with scale, and it usually arrives with a sentence: it is fine, the list is lazy.

ScrollView {
    LazyVStack {
        ForEach(items) { item in
            ItemRow(item: item)
        }
    }
}

This is correct, and for a few hundred items it is the whole story. LazyVStack constructs its children on demand, so rows far below the fold cost nothing until they scroll in. Then the feature grows. items becomes a feed of 10,000 rows with a search field above it, and every keystroke freezes the screen for long enough that the keyboard visibly stalls. The instinct is to blame SwiftUI, or to blame the list, and to start swapping containers.

The container is not where the time goes. The lazy container answers exactly one question: which rows need to exist right now. It has no opinion about what items is or how it was produced. In the typical version of this screen, a keystroke normalises the query, filters all 10,000 items against it, sorts the survivors, groups them into sections and builds a fresh array. Because the array is new, SwiftUI then has to work out which rows changed, and if the ids are unstable the answer is all of them. Rows that survived are reconstructed, each row looks up an image, some of those images are decoded and resized on demand, and layout runs for whatever is visible. All of that happens before laziness is even consulted, and most of it happens on the main actor.

The lazy container solved the one problem it solves. It did not make the pipeline lazy.

It helps to see the whole route, because the freeze can live in any stage of it.

Data to pixels

User input

keystroke, scroll, refresh
2.

Normalization

trim, lowercase, diacritics
3.

Filtering

every row, every keystroke
4.

Sorting / grouping
5.

Snapshot

the array the view sees
6.

Image lookup

cache hit or miss
7.

Decode / resize

full-size image on the main thread
8.

Row construction
9.

Layout
10.

Pixels

A large SwiftUI list is not merely a view hierarchy. It is a data-to-pixels pipeline.

Once it is drawn this way, the question changes. Not "is SwiftUI slow", but "which stage is slow, and why is it running on this keystroke at all". Every stage has its own fix and its own evidence. Filtering and sorting can move off the main actor and sit behind a request generation, the same mechanism as the first case, so that a keystroke never publishes a snapshot the user has already typed past. Snapshots can keep stable identity, so a new array does not read as 10,000 replacements. Image decoding can leave the row and be cached at display size. Invalidation can be narrowed, so a change in one row does not rebuild the section around it. None of these is the answer until measurement says which stage is the bottleneck.

That evidence comes from tools, not from intuition. A Time Profiler trace recorded while typing shows where the main actor spends each keystroke. Instruments' SwiftUI template shows whether view bodies are being evaluated broadly or narrowly, and a counter in a body will tell you the same thing more crudely. Allocation and memory traces show whether images are being decoded at scroll time and at what size. Row identity is worth checking by hand: if the model's id changes when the content does not, every diff is a replacement. There are deliberately no timings in this article. They depend on the device, the dataset and the row, and the point of the exercise is to produce your own.

The lesson is a discipline rather than a technique: do not diagnose "SwiftUI is slow" before you have found the slowest stage. The framework is rarely that stage. The pipeline built in front of it usually is.

3. Your state model worked until everybody needed it

The third failure is the slowest to appear and the hardest to name, because nothing crashes and nothing measurably stalls. It is what happens to a state model that was designed for one screen and then adopted by the whole app.

@Observable
final class AppModel {
    var user: User?
    var feed: [Post] = []
    var notifications: [Notification] = []
    var searchResults: [SearchResult] = []
    var settings = Settings()
}

This is a reasonable starting point, and it is worth being precise about what is and is not wrong with it. It is not a rendering problem. Observation tracks property access, so a view that reads feed is not re-evaluated when notifications changes. The claim that one large @Observable model redraws every view on every change is not true, and if you split this model for that reason you will spend the effort and keep the real problem.

The real problem is ownership. Ask the questions the type does not answer. Who owns user, and what happens to feed and searchResults when the user signs out? How long does searchResults live: as long as the search screen, or as long as the app? Which async work belongs to this object, and who cancels it? If notifications are removed as a feature next quarter, what else in this class disappears with them? Can the feed logic be tested without constructing a user, a settings object and a search? Every property here has a different answer, and the type has flattened them into one.

Different answers are the reason to draw boundaries. A SessionState that owns the user and the sign-out sequence. A FeedState that lives while the feed is on screen and owns its own pagination and refresh tasks. A SearchState that owns the request generation from the first case and nothing else. A SettingsState that persists across sessions. These are not four models because four is a better number than one. They are four because they have four different lifetimes, four different mutation policies and four different sets of async work to cancel.

Splitting is not automatically better. A model with three properties that always change together, live for the same time and are mutated from the same place should stay one model; splitting it adds plumbing and nothing else. The test is not size. It is whether the parts give different answers to the ownership questions. When they do, the single model is hiding a design decision that will be made anyway, later, by whoever has to add the next feature under a deadline.

SwiftUI architecture is often state ownership disguised as view architecture.

These are not SwiftUI syntax problems

Put the three cases next to each other and the pattern is the same. The happy path worked. The failure appeared when the system had to answer a question the happy path never asked: which result still owns the UI, where the expensive work actually happens, and who owns this state and for how long. In each case the correction was not a modifier. It was a decision about ownership, made explicit in code.

The way through them is the same as well. Reproduce the failure first, in the smallest project that still shows it, because a failure you cannot trigger on demand is one you cannot prove fixed. Then find the mechanism, which means naming the exact step that produces the wrong state rather than the general area: a stale write after an await, a full sort on the main actor per keystroke, a lifetime that outlives its screen. Apply the smallest correction that proves the diagnosis, a generation guard, a moved filter, a split model. If the failure disappears, the diagnosis was right; if it does not, you have learned that before building anything on top of it. Only then design the boundary that prevents the whole class of failure rather than this one instance, and prove the correction with something you can run again, a test, a trace or a counter, so the next change cannot quietly bring the failure back.

SwiftUI gets harder after you know SwiftUI

Early SwiftUI is about getting the screen to work: the layout, the binding, the modifier that does what you meant. That stage ends, and it ends sooner than it feels like it should. What comes after is production: real latency, real data volumes, real images, state that has to live for a specific time and then go away, cancellation that is cooperative rather than immediate, migrations away from the code that was there before, and real users who do things in an order nobody sketched.

At that stage, building the view is no longer the hard part. Keeping the system underneath it truthful is.

That is the stage I wrote SwiftUI Under Load for. I did not want another component reference or another collection of isolated SwiftUI recipes. The material starts with failures you can reproduce, then works through the mechanism, the smallest correction, the design that holds, and the evidence that proves it.

First published on salari.dev.

You cancelled the caller. Why is the shared Task still running?

Mike Salari — Tue, 20 Oct 2026 13:00:00 +0000

Here is a Swift concurrency question that looks easier than it is.

A caller is waiting for the value of a shared Task.

The caller gets cancelled.

What happens next?

A very tempting answer is:

The await throws CancellationError, so the caller leaves immediately.

That is not what the shared-task case guarantees.

If the task you are awaiting is a separate unstructured Task, cancelling the caller does not automatically cancel that task. Accessing the task's value waits for the task to complete and then returns or propagates that task's result.

That distinction matters because Swift cancellation is not a general-purpose interrupt.

It is a signal.

The small example

Consider a service that deduplicates refresh work:

actor RefreshStore {
    private var refreshTask: Task<String, Error>?

    func refresh() async throws -> String {
        if let refreshTask {
            return try await refreshTask.value
        }

        let task = Task {
            try await performRefresh()
        }

        refreshTask = task

        defer {
            refreshTask = nil
        }

        return try await task.value
    }

    private func performRefresh() async throws -> String {
        try await Task.sleep(for: .seconds(2))
        return "fresh"
    }
}

The important part is not the actor.

It is that task is its own task.

Several callers may end up awaiting the same handle.

Now imagine one of those callers is cancelled while this line is suspended:

return try await task.value

It is easy to read try await and mentally substitute:

caller cancelled
↓
await throws CancellationError
↓
shared task stops

But those are separate events.

Cancelling a Task is cooperative

Swift's Task.cancel() does three important things: it marks the task as cancelled, triggers its cancellation handlers, and propagates cancellation through its structured child tasks.

What it does not do is force arbitrary asynchronous work to stop.

The Swift documentation is explicit about this: cancellation is cooperative. Code has to observe cancellation and decide how to react.

That can happen through:

Task.isCancelled

or:

try Task.checkCancellation()

or because an operation you call is itself cancellation-aware.

A cancelled task can continue running if its code never responds to the cancellation signal.

That is the first mental model to keep.

The caller and the shared task are not the same task

Now return to:

try await task.value

The current task is the caller.

task is another task represented by a Task handle.

Cancelling the current task marks the current task as cancelled.

It does not mean:

task.cancel()

was called on the shared task.

And it does not mean the shared task must inherit that cancellation just because another task is awaiting its value.

That is the key difference between waiting on an unstructured task handle and cancellation propagation inside a structured task tree.

What Task.value actually promises

For a throwing task, value is an async throwing property.

If the task has not completed, accessing value waits for it.

If that task eventually throws, value propagates that error.

If that task responds to its own cancellation by throwing CancellationError, then awaiting its value propagates that error.

Notice which task those statements are about.

They are about the task represented by the handle.

That is not the same as saying:

If the caller waiting for value becomes cancelled, value automatically throws CancellationError from the caller's cancellation.

That assumption is exactly where the bug in the mental model starts.

Structured cancellation is different

Swift does propagate cancellation through structured concurrency.

If you cancel a task that owns child tasks created through a task group or another structured construct, cancellation is propagated down that hierarchy.

But an unstructured Task { ... } stored in a property and shared among callers is a different shape.

You now have independent task lifetimes.

That can be useful.

For example, you may intentionally want one network refresh to continue even if one screen disappears, because another caller is still waiting for the same refresh.

But once you make that choice, you have to decide explicitly what caller cancellation should mean.

Sometimes you do want the caller to stop waiting

Suppose the shared refresh should continue for other clients, but a cancelled caller should stop caring about its result.

Those are two different cancellation decisions:

Should the underlying shared operation be cancelled?
Should this particular caller continue waiting for it?

Do not collapse them into one boolean.

If you need the waiting caller to react immediately, you need to design that behaviour explicitly. A cancellation handler can observe cancellation immediately, but you still need a safe mechanism for racing the shared result against the caller's cancellation without accidentally cancelling work needed by other consumers.

The correct design depends on the ownership model of the operation.

That is why "just cancel the task" is usually too vague.

The inverse problem is just as dangerous

There is another common mistake:

return try await withTaskCancellationHandler {
    try await task.value
} onCancel: {
    task.cancel()
}

This may be correct if the caller owns the task.

It can be very wrong if task is shared.

Imagine three callers waiting on the same refresh:

Caller A ─┐
Caller B ─┼──> Shared Task
Caller C ─┘

Caller A goes away.

If A's cancellation handler blindly calls:

task.cancel()

A has now changed the operation for B and C too.

That may be exactly what you did not want.

Shared work needs shared ownership semantics.

Cancellation is not ownership

This is the broader lesson.

Cancellation is often discussed as if it were a universal "stop" command.

It is not.

In Swift it is cooperative, and propagation depends on the task relationship you built.

Before writing cancellation code, ask:

Which task was cancelled?
Which task owns the work?
Is the operation structured or unstructured?
Is the task handle shared?
Should one caller be able to cancel work used by another caller?
Does the operation check cancellation itself?
Do I want to cancel the work, stop waiting, or both?

Those questions are much more useful than simply asking whether something is async throws.

Why this matters in interviews

A senior Swift concurrency answer should not stop at:

Cancellation throws CancellationError.

That is too broad.

A stronger answer separates the pieces:

Cancelling a Swift task sets cancellation state and propagates through structured children. It does not forcibly stop arbitrary work. If I am awaiting a separate shared Task handle, cancelling my caller does not by itself cancel that shared task. I need to decide explicitly whether the caller should stop waiting, whether the shared work should be cancelled, or both.

That is the answer I would want to hear before we start editing code.

This was corrected in Share Your Screen 1.3

An earlier version of Share Your Screen described this shared-task case incorrectly. It said that a cancelled caller would leave the await with CancellationError.

Version 1.3 corrects that explanation.

The point of the correction is not that cancellation "never throws". It absolutely can. Swift provides Task.checkCancellation(), cancellation-aware APIs can throw, and a task can propagate its own cancellation error through value.

The important correction is narrower:

Cancelling the caller is not, by itself, a rule that makes an await on a separate shared task handle immediately throw CancellationError.

Once you separate the caller from the shared work, the behaviour becomes much easier to reason about.

References

Swift, Task.cancel()
Apple, Task.value
Swift, withTaskCancellationHandler(operation:onCancel:)
Swift, TaskGroup

First published on salari.dev.

An actor protects state. It does not own every retain and release.

Mike Salari — Tue, 13 Oct 2026 13:00:00 +0000

Swift actors make an important promise.

They isolate mutable state.

That promise is strong enough for Swift 6 to reject programs that cross concurrency boundaries unsafely, and it gives us a much better language for reasoning about data races.

But there is a tempting shortcut hiding inside that model:

If an object is actor-isolated, its references must be isolated too.

From there it is easy to jump again:

If those references are isolated, ARC should not need atomic reference counting.

That sounds reasonable.

It is also more than actor isolation actually promises.

Start with the guarantee actors do make

An actor protects its actor-isolated state from concurrent access that violates Swift's isolation rules.

An actor also conforms to Sendable.

Those are language-level concurrency properties.

They help answer questions like:

Can this mutable state be accessed from here?
Does this value cross an isolation boundary legally?
Does this code need await?
Is the compiler able to prove that a particular access is safe?

Those are valuable guarantees.

But notice what is missing.

Actor isolation does not say:

Every reference-count operation associated with every object reachable from this actor happens only while executing on this actor.

That would be a much broader lifetime guarantee.

A reference can participate in more than one mechanism

Consider an actor that stores a class instance:

final class Payload {
    let value: Int

    init(value: Int) {
        self.value = value
    }
}

actor Store {
    private var payload = Payload(value: 42)

    func currentValue() -> Int {
        payload.value
    }
}

The actor isolates access to payload as actor state.

That tells you something important about how the property can be accessed.

But ARC is not merely a record of source-level property accesses.

Reference lifetime can be affected by generated temporaries, function arguments, return values, captures, ownership conventions, optimizer decisions and other lowering details.

So there are two different questions:

Who may access this state?

and:

How is this object's lifetime represented and updated in generated code?

The first is where actor isolation operates.

The second belongs to ownership, ARC and compiler lowering.

This is exactly what the ARC experiment tested

I built a small Swift 6 lab around this distinction.

The negative control was a deliberately illegal case: non-Sendable mutable reference state crossing a concurrency boundary.

Swift 6 rejected it.

Then I tested valid cases using actor isolation, Sendable, and @unchecked Sendable.

Those cases compiled.

If concurrency isolation also acted as a direct ARC atomicity selector, this would be a reasonable place to expect the generated reference-counting path to change.

In the Apple Swift 6.3.3 cases I tested, it did not.

Ordinary builds still emitted:

swift_retain
swift_release

The actor-isolated and Sendable cases did not switch those observed calls to:

swift_nonatomic_retain
swift_nonatomic_release

Then I changed a different assumption.

I compiled with:

-Xfrontend -assume-single-threaded

Now the observed calls changed to the non-atomic variants.

That is a much cleaner signal than trying to infer ARC behaviour from the presence of actor or Sendable.

The A/B

For the controlled retain/release case in the lab:

Build	Retain	Release
normal `-Onone`	`swift_retain`	`swift_release`
single-threaded `-Onone`	`swift_nonatomic_retain`	`swift_nonatomic_release`
normal `-O`	`swift_retain`	`swift_release`
single-threaded `-O`	`swift_nonatomic_retain`	`swift_nonatomic_release`

The result is deliberately narrow.

It does not prove that Swift ARC is always atomic.

It does not prove that actor isolation can never participate in an ARC optimization.

It does not prove that Sendable can never influence optimization.

It shows that in these tested Apple Swift 6.3.3 cases, changing the concurrency validity of the program did not change the observed ARC runtime entry-point selection, while the explicit single-threaded compiler assumption did.

That is compiler/runtime implementation evidence for the tested toolchain, not a Swift language guarantee.

Why Sendable does not close the gap

Sendable is another place where the same mental shortcut appears.

A type conforming to Sendable is saying something about crossing concurrency boundaries safely under Swift's concurrency model.

For unchecked conformance:

final class Box: @unchecked Sendable {
    // You are taking responsibility for the safety contract.
}

the compiler is not proving your synchronization strategy for you.

You are asserting that the type can be used safely across those boundaries.

That still does not mean:

Sendable
↓
non-atomic refcount

Sendable is not an ARC annotation.

The Swift documentation describes @unchecked Sendable in exactly that spirit: you assume responsibility for correctness when the compiler cannot enforce the conformance itself.

Isolation is about access, not exclusive lifetime ownership

The easiest way to remember the distinction is:

Actor isolation controls access to isolated state. It does not mean the actor is the only place where all lifetime bookkeeping for every related reference can occur.

That difference becomes more visible when values move across APIs.

An actor method can return a Sendable value.

A reference may be captured by generated code.

A function call may introduce ownership traffic that is not interesting at the source level.

Optimization may remove, combine or reposition retain/release operations.

None of that means actor isolation is broken.

It means source-level isolation and runtime lifetime accounting are different layers of the implementation.

Why this matters for performance reasoning

This is where developers can accidentally turn a correctness feature into an imagined performance guarantee.

For example:

I moved this behind an actor, so ARC can be cheaper now.

That conclusion does not follow from the actor model.

The actor may absolutely improve the correctness and architecture of the code.

It may also change performance in many ways, including scheduling and serialization costs.

But if your performance claim is specifically about reference-count atomicity, you need evidence from generated code or runtime behaviour.

Do not infer it from actor.

Do not infer it from Sendable.

Measure the layer you are making the claim about.

Why SIL alone is not enough

This also explains why looking at one intermediate representation can be misleading.

SIL exposes ownership operations, but the question in the ARC experiment was narrower:

Which runtime ARC entry points survive into the generated program?

For that, LLVM IR and assembly are more directly useful.

Optimization can eliminate or combine ARC traffic, so even the presence of an ownership operation in one stage does not guarantee a corresponding runtime call later.

This is why the lab keeps SIL, LLVM IR and assembly evidence separate.

The more specific your claim, the closer your evidence should be to the layer you are claiming something about.

A better senior-level mental model

When reasoning about Swift concurrency and ownership, keep three layers separate:

1. Isolation

Who is allowed to access this state, and from which concurrency domain?

Actors and global actors live here.

2. Transfer

Can this value cross a concurrency boundary safely?

Sendable lives here.

3. Lifetime accounting

How does the generated program keep the referenced object alive and eventually destroy it?

ARC and compiler lowering live here.

These layers interact.

They are not interchangeable.

That is why a program can become valid under Swift 6's concurrency checker while the ARC entry points observed in generated code remain unchanged.

The practical rule

If Swift 6 rejects the program, fix the concurrency problem.

If you want to know what ARC is doing, inspect ARC.

Do not use one as a proxy for the other.

That sounds obvious when written down.

It is much less obvious when an actor has just given the compiler a strong new proof and you are staring at a pair of swift_retain / swift_release calls that refuse to disappear.

The compiler is not contradicting itself.

You were asking two different questions.

Reproduce the ARC experiment

The full lab is public:

https://github.com/salari-dev/swift6-arc-atomicity-lab

It includes:

the negative concurrency control;
actor-isolated, Sendable, and @unchecked Sendable cases;
SIL, LLVM IR and assembly evidence;
the atomic versus non-atomic A/B;
compiler-selection tracing;
reproduction scripts.

The tested environment documented in the repo is Apple Swift 6.3.3, Xcode 26.6, macOS 26.6.2, arm64, Swift language mode 6, with iPhone 17 Simulator used for simulator validation.

No second official Swift toolchain was tested, so this should not be presented as a permanent language rule.

References

Swift, Actor
Swift, Sendable
Reproduction repository: salari-dev/swift6-arc-atomicity-lab

First published on salari.dev.

Swift 6 rejected the race. ARC stayed atomic.

Mike Salari — Tue, 06 Oct 2026 15:06:00 +0000

Swift 6 rejected the unsafe program exactly where I expected it to.

I had a small reference-type experiment with state shared across concurrency boundaries. In Swift 6 language mode, the negative control failed with concurrency diagnostics. Good. That part was boring in the best possible way.

Then I fixed the concurrency problem.

I moved the state behind actor isolation. I tested Sendable variants. I also tested an @unchecked Sendable case where I was explicitly taking responsibility for the safety guarantee.

The code compiled.

Then I looked at what ARC was doing.

I expected the generated code to change.

It did not.

In the Apple Swift 6.3.3 cases I tested, the runtime still went through the normal:

swift_retain
swift_release

Actor isolation had changed what Swift could prove about access to the program state.

It had not changed the ARC runtime entry points I was observing.

That was the interesting part.

The question

Swift 6 has a much stronger concurrency model than earlier Swift versions.

The compiler can reject code that moves non-Sendable state across isolation boundaries. Actors provide isolation. Sendable describes values that can safely cross concurrency domains. Strict concurrency checking catches classes of mistakes that previously survived compilation.

So I wanted to test a fairly simple question:

If Swift 6 can prove that some object access is isolated from concurrent mutation, can ARC use cheaper non-atomic reference counting for that object?

That sounds plausible.

If the compiler knows an object is actor-isolated, why pay synchronization costs for reference-count updates that should not race?

The problem is that two different questions are being mixed together.

Swift concurrency asks whether program state is being accessed or transferred safely.

ARC asks how object lifetime is accounted for.

Those are related, but they are not the same contract.

I wanted to see where that distinction showed up in generated code rather than stopping at the language model.

The experiment

I ran the experiment using Apple Swift 6.3.3 from Xcode 26.6, explicitly compiling in Swift 6 language mode.

The test environment was:

Apple Swift 6.3.3
Xcode 26.6
macOS 26.6.2
arm64
Swift language mode 6
iPhone 17 Simulator for simulator validation

The repository contains a negative control plus several valid cases, including actor isolation and Sendable variants.

The negative control matters.

Without it, seeing a successful Swift 6 build tells us almost nothing. I wanted a case where the compiler demonstrably rejected unsafe sharing, then closely related cases where the concurrency problem had actually been addressed.

The unsafe case failed as expected.

The valid cases compiled.

Then I looked at multiple stages of compiler output.

That distinction matters because SIL ownership instructions are not the same thing as the final ARC runtime calls.

At the SIL level you can see ownership operations and retain/release behaviour represented in Swift's intermediate representation.

But if the question is:

Which runtime reference-counting entry point does this build actually use?

then LLVM IR and assembly are the more interesting places to look.

In the ordinary Swift 6 builds I tested, I continued to find:

swift_retain
swift_release

That remained true when the concurrency model around the object changed.

Actor isolation did not turn the observed calls into non-atomic ARC operations.

Neither did the Sendable or @unchecked Sendable cases I tested.

Then I changed one compiler assumption

There is a compiler option that makes this experiment much more useful:

-Xfrontend -assume-single-threaded

The name is refreshingly direct.

Instead of asking the compiler to infer from actor isolation that some individual object's reference counting can be cheaper, this flag changes a much broader assumption about the program.

The compiler is being told to assume single-threaded execution.

I compiled the controlled case again.

This time, the output changed.

Instead of the ordinary ARC runtime entry points, I observed:

swift_nonatomic_retain
swift_nonatomic_release

And that happened in both the unoptimized and optimized configurations I tested.

The clean A/B looked like this:

Build	Retain	Release
normal `-Onone`	`swift_retain`	`swift_release`
single-threaded `-Onone`	`swift_nonatomic_retain`	`swift_nonatomic_release`
normal `-O`	`swift_retain`	`swift_release`
single-threaded `-O`	`swift_nonatomic_retain`	`swift_nonatomic_release`

That gave me the selector I wanted.

The same general reference-counting operation could be lowered differently when the compiler was explicitly told to assume a single-threaded program.

But Swift 6 actor isolation by itself had not produced the same result in my experiment.

Why this distinction matters

It would be easy to look at Swift 6 concurrency and reason like this:

An actor guarantees isolated access.
Therefore this reference cannot be touched concurrently.
Therefore ARC for this reference does not need atomic operations.

The first statement can be valid.

The jump from the first statement to the third is where things become much less obvious.

Actor isolation is a source-level concurrency guarantee about access to isolated state.

ARC lifetime operations may happen for references that move through code outside the isolated body, through calling conventions, temporary values, captures, ownership transfers, bridging, optimizer transformations, and other parts of the generated program.

A proof that some mutable state is actor-isolated is not automatically the same thing as a whole-program proof that every relevant lifetime operation for an object can use non-atomic accounting.

The experiment does not prove why every individual retain or release remains on a particular runtime path.

What it does show is narrower and more useful:

In the Apple Swift 6.3.3 cases I tested, making the program concurrency-safe through actor isolation, Sendable, or @unchecked Sendable did not change the observed ARC calls from swift_retain / swift_release to their non-atomic counterparts.

Explicitly switching the compiler to a single-threaded assumption did.

This is compiler/runtime implementation evidence for the tested toolchain, not a Swift language guarantee.

That distinction matters.

Following the compiler

I also traced the relevant compiler path instead of treating the runtime symbol names as magic.

For the toolchain path examined in the repository, the single-threaded assumption flows roughly like this:

-Xfrontend -assume-single-threaded (frontend option)
CompilerInvocation
SILOptions::AssumeSingleThreaded
SILModule::isDefaultAtomic()
IRGen atomicity
GenHeap runtime call selection

A normal build emits swift_retain / swift_release. With the single-threaded assumption it emits swift_nonatomic_retain / swift_nonatomic_release. For an actor-isolated object or a Sendable type, no rule was found: that branch does not reach IRGen.

That is useful because it connects the frontend assumption to the ARC lowering decision.

The interesting part is what I did not find in that path.

I did not find a corresponding rule that says:

actor-isolated object
↓
non-atomic ARC

or:

Sendable
↓
non-atomic ARC

And the generated output from the experiment matched that.

That does not mean such an optimization could never exist.

It means I could not demonstrate it in these cases, with this toolchain, and the compiler path I traced points to a broader default-atomicity decision rather than a simple mapping from Swift concurrency annotations to ARC atomicity.

There is one additional limitation worth stating clearly: the open-source Swift source revision inspected in the repo is not proven to be the exact source revision Apple used to build Swift 6.3.3.

So the compiler-source tracing is supporting evidence, not a claim of exact source-build identity.

Sendable is not an ARC annotation

This is also a useful reminder about Sendable.

Sendable is frequently discussed as if it were a general "thread safe" marker.

That is too vague.

Its job is about whether values can safely cross concurrency boundaries under Swift's concurrency model.

It does not say:

Use non-atomic reference counting for this instance.

Likewise, @unchecked Sendable does not unlock an ARC optimization.

It tells the compiler that you are taking responsibility for a guarantee it cannot verify itself.

In my tested cases, neither changed the ARC runtime calls I was looking at.

That separation is important because otherwise it becomes very easy to assign performance properties to concurrency annotations that the language never promised.

Actor isolation is still doing real work

None of this makes actor isolation less valuable.

The negative control was rejected.

The isolated version compiled.

That is a meaningful change in the program.

Swift 6 was enforcing a concurrency contract and preventing a class of unsafe access.

What did not happen was a second, independent assumption:

Because this code is now accepted by the concurrency checker, ARC can use non-atomic lifetime accounting.

Those are two different decisions.

That distinction is probably the main thing I took away from the experiment.

Swift's concurrency model can become more precise without every other subsystem automatically inheriting those proofs.

Why not just look at SIL?

Because SIL can easily tempt you into making claims one level too early.

Ownership operations in SIL tell you something about Swift's ownership representation and optimization pipeline.

They do not necessarily tell you which reference-counting runtime function survives into the final generated program.

Optimization makes this even more complicated.

A retain may disappear. Two operations may be combined. A lifetime can be shortened or extended. Something visible at -Onone may not exist at -O.

For this question, I wanted to check SIL, then continue down to LLVM IR and assembly rather than infer the final runtime behaviour from one intermediate stage.

That also makes the experiment easier to falsify.

You do not have to trust my interpretation of a SIL ownership instruction.

You can inspect the generated IR or assembly and search for the actual runtime symbols.

What this experiment does not prove

There are several conclusions I would not draw from this.

It does not prove:

Swift ARC is always atomic.

It does not prove:

Actor-isolated objects always use atomic refcounts.

It does not prove:

Sendable can never influence ARC optimization.

It does not prove:

Atomic reference counting protects your mutable program state.

It does not prove:

-assume-single-threaded is a production optimization you should enable.

And it does not prove that the behaviour observed in this toolchain is a permanent Swift language rule.

Those claims are much broader than the evidence.

The result is specifically about the compiler configurations and source cases I tested.

The defensible claim is:

In these Apple Swift 6.3.3 experiments, actor isolation, Sendable, and @unchecked Sendable changed the concurrency validity of the program but did not change the observed ARC runtime entry points. Explicitly compiling with -assume-single-threaded did.

That is the claim I am comfortable publishing.

The practical lesson

Most application developers will never choose ARC entry points manually.

That is not really the point.

The useful lesson is about how to reason about compiler guarantees.

Swift 6 rejecting a data race does not mean every subsystem now gets to assume that the entire lifetime of every involved object is single-threaded.

Concurrency safety is one contract.

Object lifetime accounting is another.

Sometimes a compiler can connect proofs across those boundaries.

Sometimes it cannot, or deliberately does not.

And sometimes you need to stop looking at the language feature and inspect the generated program.

That is what happened here.

Swift 6 rejected the race.

ARC stayed on the ordinary path.

Only when I explicitly told the compiler to assume a single-threaded world did the reference-counting path change.

Reproduce it

The full experiment is public:

GitHub: https://github.com/salari-dev/swift6-arc-atomicity-lab

The repository includes:

the Swift test cases;
the negative concurrency control;
generated SIL, LLVM IR and assembly evidence;
the atomic versus non-atomic A/B;
compiler-selection tracing;
runtime-source mapping;
claim auditing;
simulator validation;
reproduction scripts.

To regenerate the compiler experiment:

./run-experiment.sh

For simulator validation:

./run-simulator-validation.sh

The repository preserves the frozen evidence under Evidence/, while regenerated output is written separately.

The experiment currently uses one official Apple Swift toolchain. No second official Swift toolchain was installed and tested, so cross-toolchain reproduction remains unresolved.

I would encourage you to run it rather than take this article on faith.

Compiler behaviour is exactly the kind of thing where the interesting answer may change with a future toolchain.

And if a newer Swift compiler starts lowering one of these cases differently, that would make the experiment more interesting, not less.

References

Swift, Actor
Swift, Sendable
Reproduction repository: salari-dev/swift6-arc-atomicity-lab

First published on salari.dev.