{"id":49969,"date":"2025-11-07T17:41:21","date_gmt":"2025-11-07T22:41:21","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49969"},"modified":"2025-11-07T17:41:21","modified_gmt":"2025-11-07T22:41:21","slug":"mainactor-assumeisolated-preconcurrency-and-isolated-conformances","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/11\/07\/mainactor-assumeisolated-preconcurrency-and-isolated-conformances\/","title":{"rendered":"MainActor.assumeIsolated, Preconcurrency, and Isolated Conformances"},"content":{"rendered":"

Fatbobman<\/a>:<\/p>\n

\n

As Swift 6 gradually gains adoption, this problem becomes increasingly prominent: developers want to benefit from the concurrency safety guarantees provided by the Swift compiler, while struggling with how to make their code meet compilation requirements. This article will demonstrate the clever use of MainActor.assumeIsolated<\/code> in specific scenarios through an implementation case with NSTextAttachmentViewProvider<\/code>.<\/p>\n

[…]<\/p>\n

We seem to be caught in a dilemma: we need to construct UIHostingController<\/code> in MainActor<\/code>, yet we cannot assign the constructed view (UIView<\/code>) to self.view<\/code> within MainActor<\/code>.<\/p>\n

[…]<\/p>\n

Looking at MainActor.assumeIsolated<\/code>’s signature, we can see that this API provides a MainActor<\/code> context for its trailing closure. This means we can “synchronously” run code that can only execute in a MainActor<\/code> context within a non-MainActor<\/code> synchronous context, without creating an async environment, and return a Sendable<\/code> result<\/strong>.<\/p>\n

[…]<\/p>\n

I still hope we can move past this somewhat “chaotic” transition period soon. Perhaps in a few years, when numerous official and third-party frameworks have completed their Swift 6 migration, we’ll finally enjoy a more relaxed safe concurrent programming experience.<\/p>\n<\/blockquote>\n\n

Matt Massicotte<\/a>:<\/p>\n

I consistently find the @preconcurrency<\/code> attribute to be confusing. But, I’m tired of that. Let’s just, once and for all, get a better handle how to use this thing.<\/p>\n

[…]<\/p>\n

It has three<\/strong> distinct uses. And while they all apply to definitions, the details are quite different.<\/p><\/blockquote>\n\n

Jesse Squires<\/a>:<\/p>\n

UIKit provides two diffable data source APIs, one for collections<\/a> and one for tables<\/a>.\nRecently, while working on ReactiveCollectionKit<\/a>, I noticed that the APIs were updated for Swift Concurrency in the iOS 18 SDK, but the annotations were inconsistent with the documentation.<\/p>

[…]<\/p>

I reached out to Tyler Fox<\/a> from the UIKit team on Mastodon to ask if this was a mistake. As it turns out, it is not a mistake and his reply was incredibly helpful and insightful. For posterity and documentation purposes (and because social media is ephemeral and unreliable), I’m going to reproduce his entire response here<\/a>[…]<\/p><\/blockquote>\n\n

Wade Tregaskis<\/a>:<\/p>\n

\n

These might seem pretty similar – you’d be forgiven for assuming it’s just a convenience to put @MainActor<\/code> on the protocol overall rather than having to repeat it for every member of the protocol. Less error-prone, too.<\/p>\n

But, you generally shouldn’t do that. They are not<\/em> equivalent.<\/p>\n

The first form is not merely saying that all the members of the protocol require a certain isolation, but that the type<\/em> that conforms to the protocol must have that isolation. The whole<\/em> type.<\/p>\n<\/blockquote>\n\n

Matt Massicotte<\/a>:<\/p>\n

Further, as far as the compiler is concerned, there is an actor boundary both going into and returning from assumeIsolated<\/code>. This means you cannot work with non-Sendable<\/code> data here and that can be an enormous pain.<\/p>

[…]<\/p>

Before Swift 6.0, dynamic isolation was the only option. And before Swift 6.2, I think that preconcurrency conformances were the best tool for handling protocol isolation mismatches. They address pretty much all of the weakness of the nonisolated<\/code>-assumeIsolated<\/code> thing. But they just feel funny.<\/p>

[…]<\/p>

Swift 6.2 allows us to express this idea directly, by constraining a conformance to be valid only for a particular global actor.<\/p>

What we now have is exactly what we want. A MainActor<\/code> type that is Equatable<\/code> in that context only<\/strong>. This is not the same as a true, unconstrainted Equatable<\/code>, because those work everywhere. It’s a little like defining a new, special variant of that protocol right in line at the conformance declaration site.<\/p>

[…]<\/p>

But remember, not all protocols are compatible. And making this entire thing implicit makes the problems even more surprising. Don’t get me wrong, I really<\/strong> like isolated conformances and am very happy to see them come to the language. But they are not a magic bullet (and neither is MainActor<\/code>-by-default).<\/p><\/blockquote>\n\n

Lukas Valenta<\/a> at mDevCamp (Mastodon<\/a>):<\/p>\n

The talk focuses - as the name suggests - to strategy to migrate the project from Swift 5 compilation mode to Swift 6. We will discuss several issues anyone will encounter to have project that compiles under Swift 6 mode, such as issues with Combine and Async publishers, DispatchQueue.main precondition queue checks, working with older APIs that predate the concurrency, as well as a debate whether it is all worth it. I will also mention the transition of not only the project itself but also a story of external dependencies, some of which written by me, and how did the migration in the libraries took place.<\/p><\/blockquote>\n\n

Previously:<\/p>\n