{"id":46235,"date":"2024-12-20T16:53:05","date_gmt":"2024-12-20T21:53:05","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=46235"},"modified":"2024-12-20T16:53:05","modified_gmt":"2024-12-20T21:53:05","slug":"swift-concurrency-in-real-apps","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/12\/20\/swift-concurrency-in-real-apps\/","title":{"rendered":"Swift Concurrency in Real Apps"},"content":{"rendered":"

Bryan Jones<\/a>:<\/p>\n

\n

Consider this code, wherein we create a custom NSTableColumn<\/code> that uses an image instead of a String<\/code> as its header.<\/p>\n<\/blockquote>\n\n

Holly Borla<\/a> posted a fix that special-cases NSObject.init()<\/code>:<\/p>\n

Now, overriding NSObject.init()<\/code> within a @MainActor<\/code>-isolated type is difficult-to-impossible, especially if you need to call an initializer from an intermediate superclass that is also @MainActor<\/code>-isolated. Standard opt-out tools like MainActor.assumeIsolated<\/code> cannot be applied to things like stored property initialization and super.init()<\/code>, making the issue extremely difficult to work around. This is a major usability regression for programs that interoperate with Objective-C and make heavy use of @MainActor<\/code>-isolated types.<\/p>

[…]<\/p>

I can’t reproduce a failure by overriding viewDidAppear<\/code> in a @MainActor<\/code>-isolated subclass of UIViewController<\/code>, but if this is happening for methods that are marked as nonisolated<\/code> or otherwise aren’t annotated with @MainActor<\/code>, then that is a deliberate result of my original change. Overriding superclass methods and changing isolation does risk a data-race, which is why I made the original change. If you believe the superclass method is incorrectly annotated, that is a framework problem that you should report via Apple Feedback Assistant.<\/p><\/blockquote>\n\n

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

(As it turns out, UINib<\/code> actually is<\/strong> MainActor<\/code>-isolated, while NSNib<\/code> is not. There’s one person out there somewhere maintaining a cross-platform app that uses nibs and this is going to make their life hell.)<\/p>

The whole point<\/em> of Nibs is to serialize UI<\/strong> components. That’s literally the only reason it exists. And that doesn’t work in Swift 6[…]<\/p>

[…]<\/p>

The compiler must honor the API contract of awakeFromNib<\/code>. The framework maintainers have decided to not apply any isolation. The types and APIs aren’t able to fully describe the concurrent behavior, but the developer knows what’s actually going to happen at runtime.<\/p>

This is a special-case of a very common issue and is exactly<\/strong> why dynamic isolation exists.<\/p>\n

[…]<\/p>\n

Some APIs, even really important ones that you use every day, just won’t ever work well with Swift concurrency. I’m certain some language changes could make things a little easier here and there. But, largely, these problematic APIs are going to be deprecated and replaced. It’s happening with Notifications<\/a> right now.<\/p><\/blockquote>\n\n

Drew McCormack<\/a>:<\/p>\n

\n

Pretty sure there are use cases for background threads. I think code for printing uses NSView<\/code>, and usually involves a background op.<\/p>\n<\/blockquote>\n\n

Der Teilweise<\/a>:<\/p>\n

TIL: awakeFromNib()<\/code> can be called more than once when objects are loaded from XIBs.<\/p>

IDK, maybe that is something that should be mentioned in the documentation<\/a>.<\/p><\/blockquote>\n\n

Previously:<\/p>\n