Fixing actor-isolated protocol conformance associated errors in Swift 6.2 – Donny Wals

Swift 6.2 comes with a number of high quality of life enhancements for concurrency. Considered one of these options is the flexibility to have actor-isolated conformances to protocols. One other characteristic is that your code will now run on the primary actor by default.

This does imply that generally, you’ll run into compiler errors. On this weblog publish, I’ll discover these errors, and how one can repair them once you do.

Earlier than we do, let’s briefly speak about actor-isolated protocol conformance to know what this characteristic is about.

Understanding actor-isolated protocol conformance

Protocols in Swift can require sure capabilities or properties to be nonisolated. For instance, we are able to outline a protocol that requires a nonisolated var title like this:

protocol MyProtocol {
  nonisolated var title: String { get }
}

class MyModelType: MyProtocol {
  var title: String

  init(title: String) {
    self.title = title
  }
}

Our code is not going to compile for the time being with the next error:

Conformance of 'MyModelType' to protocol 'MyProtocol' crosses into foremost actor-isolated code and might trigger knowledge races

In different phrases, our MyModelType is remoted to the primary actor and our title protocol conformance isn’t. Because of this utilizing MyProtocol and its title in a nonisolated manner, can result in knowledge races as a result of title isn’t truly nonisolated.

While you encounter an error like this you might have two choices:

1. Embrace the nonisolated nature of title
2. Isolate your conformance to the primary actor

The primary resolution often implies that you don’t simply make your property nonisolated, however you apply this to your total kind:

nonisolated class MyModelType: MyProtocol {
  // ...
}

This would possibly work however you’re now breaking out of foremost actor isolation and probably opening your self as much as new knowledge races and compiler errors.

When your code runs on the primary actor by default, going nonisolated is usually not what you need; every part else continues to be on foremost so it is smart for MyModelType to remain there too.

On this case, we are able to mark our MyProtocol conformance as @MainActor:

class MyModelType: @MainActor MyProtocol {
  // ...
}

By doing this, MyModelType conforms to my protocol however solely after we’re on the primary actor. This mechanically makes the nonisolated requirement for title pointless as a result of we’re at all times going to be on the primary actor after we’re utilizing MyModelType as a MyProtocol.

That is extremely helpful in apps which can be foremost actor by default since you don’t need your foremost actor varieties to have nonisolated properties or capabilities (often). So conforming to protocols on the primary actor makes lots of sense on this case.

Now let’s take a look at some errors associated to this characteristic, we could? I initially encountered an error round my SwiftData code, so let’s begin there.

Fixing Predominant actor-isolated conformance to ‘PersistentModel’ can’t be utilized in actor-isolated context

Let’s dig proper into an instance of what can occur once you’re utilizing SwiftData and a customized mannequin actor. The next mannequin and mannequin actor produce a compiler error that reads “Predominant actor-isolated conformance of ‘Train’ to ‘PersistentModel’ can’t be utilized in actor-isolated context”:

@Mannequin
class Train {
  var title: String
  var date: Date

  init(title: String, date: Date) {
    self.title = title
    self.date = date
  }
}

@ModelActor
actor BackgroundActor {
  func instance() {
    // Name to foremost actor-isolated initializer 'init(title:date:)' in a synchronous actor-isolated context
    let train = Train(title: "Operating", date: Date())
    // Predominant actor-isolated conformance of 'Train' to 'PersistentModel' can't be utilized in actor-isolated context
    modelContext.insert(train)
  }
}

There’s truly a second error right here too as a result of we’re calling the initializer for train from our BackgroundActor and the init for our Train is remoted to the primary actor by default.

Fixing our downside on this case implies that we have to permit Train to be created and used from non-main actor contexts. To do that, we are able to mark the SwiftData mannequin as nonisolated:

@Mannequin
nonisolated class Train {
  var title: String
  var date: Date

  init(title: String, date: Date) {
    self.title = title
    self.date = date
  }
}

Doing it will make each the init and our conformance to PersistentModel nonisolated which implies we’re free to make use of Train from non-main actor contexts.

Notice that this does not imply that Train can safely be handed from one actor or isolation context to the opposite. It simply implies that we’re free to create and use Train cases away from the primary actor.

Not each app will want this or encounter this, particularly once you’re working code on the primary actor by default. If you happen to do encounter this downside for SwiftData fashions, you need to in all probability isolate the problematic are to the primary actor except you particularly created a mannequin actor within the background.

Let’s check out a second error that, so far as I’ve seen is fairly widespread proper now within the Xcode 26 beta; utilizing Codable objects with default actor isolation.

Fixing Conformance of protocol ‘Encodable’ crosses into foremost actor-isolated code and might trigger knowledge races

This error is kind of fascinating and I wonder if it’s one thing Apple can and will repair throughout the beta cycle. That mentioned, as of Beta 2 you would possibly run into this error for fashions that conform to Codable. Let’s take a look at a easy mannequin:

struct Pattern: Codable {
  var title: String
}

This mannequin has two compiler errors:

1. Round reference
2. Conformance of ‘Pattern’ to protocol ‘Encodable’ crosses into foremost actor-isolated code and might trigger knowledge races

I’m not precisely certain why we’re seeing the primary error. I believe it is a bug as a result of it is mindless to me for the time being.

The second error says that our Encodable conformance “crossed into foremost actor-isolated code”. If you happen to dig a bit deeper, you’ll see the next error as a proof for this: “Predominant actor-isolated occasion technique ‘encode(to:)’ can not fulfill nonisolated requirement”.

In different phrases, our protocol conformance provides a foremost actor remoted implementation of encode(to:) whereas the protocol requires this technique to be non-isolated.

The explanation we’re seeing this error is just not completely clear to me however there appears to be a mismatch between our protocol conformance’s isolation and our Pattern kind.

We are able to do one in all two issues right here; we are able to both make our mannequin nonisolated or constrain our Codable conformance to the primary actor.

nonisolated struct Pattern: Codable {
  var title: String
}

// or
struct Pattern: @MainActor Codable {
  var title: String
}

The previous will make it in order that every part on our Pattern is nonisolated and can be utilized from any isolation context. The second choice makes it in order that our Pattern conforms to Codable however solely on the primary actor:

func createSampleOnMain() {
  // that is nice
  let pattern = Pattern(title: "Pattern Occasion")
  let knowledge = attempt? JSONEncoder().encode(pattern)
  let decoded = attempt? JSONDecoder().decode(Pattern.self, from: knowledge ?? Knowledge())
  print(decoded)
}

nonisolated func createSampleFromNonIsolated() {
  // this isn't nice
  let pattern = Pattern(title: "Pattern Occasion")
  // Predominant actor-isolated conformance of 'Pattern' to 'Encodable' can't be utilized in nonisolated context
  let knowledge = attempt? JSONEncoder().encode(pattern)
  // Predominant actor-isolated conformance of 'Pattern' to 'Decodable' can't be utilized in nonisolated context
  let decoded = attempt? JSONDecoder().decode(Pattern.self, from: knowledge ?? Knowledge())
  print(decoded)
}

So typically talking, you don’t need your protocol conformance to be remoted to the primary actor in your Codable fashions when you’re decoding them on a background thread. In case your fashions are comparatively small, it’s seemingly completely acceptable so that you can be decoding and encoding on the primary actor. These operations must be quick sufficient generally, and sticking with foremost actor code makes your program simpler to motive about.

The very best resolution will rely in your app, your constraints, and your necessities. At all times measure your assumptions when potential and stick to options that be just right for you; don’t introduce concurrency “simply to make sure”. If you happen to discover that your app advantages from decoding knowledge on a background thread, the answer for you is to mark your kind as nonisolated; when you discover no direct advantages from background decoding and encoding in your app you need to constrain your conformance to @MainActor.

If you happen to’ve applied a customized encoding or decoding technique, you may be working into a distinct error…

Conformance of ‘CodingKeys’ to protocol ‘CodingKey’ crosses into foremost actor-isolated code and might trigger knowledge races

Now, this one is a little bit trickier. When we’ve a customized encoder or decoder, we would additionally need to present a CodingKeys enum:

struct Pattern: @MainActor Decodable {
  var title: String

  // Conformance of 'Pattern.CodingKeys' to protocol 'CodingKey' crosses into foremost actor-isolated code and might trigger knowledge races
  enum CodingKeys: CodingKey {
    case title
  }

  init(from decoder: any Decoder) throws {
    let container = attempt decoder.container(keyedBy: CodingKeys.self)
    self.title = attempt container.decode(String.self, forKey: .title)
  }
}

Sadly, this code produces an error. Our conformance to CodingKey crosses into foremost actor remoted code and that may trigger knowledge races. Often this is able to imply that we are able to constraint our conformance to the primary actor and this is able to resolve our difficulty:

// Predominant actor-isolated conformance of 'Pattern.CodingKeys' to 'CustomDebugStringConvertible' can not fulfill conformance requirement for a 'Sendable' kind parameter 'Self'
enum CodingKeys: @MainActor CodingKey {
  case title
}

This sadly doesn’t work as a result of CodingKeys requires us to be CustomDebugStringConvertable which requires a Sendable Self.

Marking our conformance to foremost actor ought to imply that each CodingKeys and CodingKey are Sendable however as a result of the CustomDebugStringConvertible is outlined on CodingKey I believe our @MainActor isolation doesn’t carry over.

This may additionally be a tough edge or bug within the beta; I’m unsure.

That mentioned, we are able to repair this error by making our CodingKeys nonisolated:

struct Pattern: @MainActor Decodable {
  var title: String

  nonisolated enum CodingKeys: CodingKey {
    case title
  }

  init(from decoder: any Decoder) throws {
    let container = attempt decoder.container(keyedBy: CodingKeys.self)
    self.title = attempt container.decode(String.self, forKey: .title)
  }
}

This code works completely nice each when Pattern is nonisolated and when Decodable is remoted to the primary actor.

Each this difficulty and the earlier one really feel like compiler errors, so if these get resolved throughout Xcode 26’s beta cycle I’ll ensure that to return again and replace this text.

If you happen to’ve encountered errors associated to actor-isolated protocol conformance your self, I’d love to listen to about them. It’s an fascinating characteristic and I’m making an attempt to determine how precisely it matches into the best way I write code.