{"id":49034,"date":"2025-08-26T14:57:45","date_gmt":"2025-08-26T18:57:45","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49034"},"modified":"2025-08-26T15:00:41","modified_gmt":"2025-08-26T19:00:41","slug":"swiftdatas-modelactor-is-just-weird","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/08\/26\/swiftdatas-modelactor-is-just-weird\/","title":{"rendered":"SwiftData’s ModelActor Is Just Weird"},"content":{"rendered":"

Matt Massicotte<\/a> (Mastodon<\/a>):<\/p>\n

So, no doubt there’s lots of historical stuff going on here.<\/p>

But, that still doesn’t explain how much trouble<\/a> people have with ModelActor<\/a>. I’m not sure anyone<\/strong> has ever used ModelActor<\/code> without at least some surprises.<\/p>

[…]<\/p>

Actors exist to protect mutable state. The purpose of a ModelActor<\/code> is to own and isolate the ModelContext<\/code>. It does that! But if we start to dig into how<\/strong> exactly it does it, we will discover something very bizarre.<\/p>

[…]<\/p>

Somehow, we are on our custom, minimal, SwiftData-defined actor and<\/strong> also the MainActor<\/code> at the same time.<\/p>

[…]<\/p>

It is bad because consumers of this API have a very reasonable expectation that this will execute off the main thread. This type doesn’t do that. But worse, its relationship with the main thread isn’t visible in the type system. These things are not<\/strong> marked MainActor<\/code>, so the compiler doesn’t know what’s going on. This means even though you are on the main thread here, you cannot access MainActor<\/code> stuff.<\/p><\/blockquote>\n\n

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

\n

Anyone know if SwiftData’s ModelActor<\/code> still has weird concurrency behavior in OS 26?<\/p>\n

[…]<\/p>\n

Based on some limited testing, no, not fixed. ModelActor<\/code> types can still ultimately execute on the main thread, depending on calling context.<\/p>\n<\/blockquote>\n\n

Rick van Voorden<\/a>:<\/p>\n

AFAIK the legit workaround will continue to be to ensure the ModelActor<\/code> is created off main<\/code>. Which leads to workarounds like what we do in ImmutableData<\/code> sample products when we “box” the ModelActor<\/code> with a lazy<\/code> property in another<\/em> actor that is<\/em> created on main<\/code>.<\/p><\/blockquote>\n\n

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

\n

Someone proved that init off main is insufficient. I have a theory on what’s happening, and I think this workaround you suggest will always work. But yeah I’m hoping this all just goes away.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n