Compatibility of Nuke 13+ with Swift 5 mode apps

[freak4pc]

Hey @kean,
This is more of a discussion than an issue, I think :)

We recently upgraded to Nuke 13.x and are getting various crashes from internal Swift Concurrency assertions:

Our assumptions are its because its in older areas of the app that area still in legacy Swift 5 mode, but the code itself looks "innocent" theoretically speaking.

I'm wondering if you have thoughts on this, or bumped into reports on similar issues. Currently contemplating between downgrading to 12.x vs. going all-out on a Swift 6 migration for our older code.

Thank you for your time 🙏

[kean]

Hey, that is interesting. I haven't considered this scenario. Does it happen only in the debug mode?

the code itself looks "innocent" theoretically speaking.

com.apple.root.user-initiated-qos.cooperative – not the main thread, and LazyImage like all SwiftUI views is isolated to the main actor.

[freak4pc]

These crashes are from release users in production.

I understand the isolation concerns, but we have @MainActor on all views, I'm not 100% sure how to debug it beyond that, we tried a bunch of things but still seeing crashes happening.

BUT - the default isolation = MainActor thing is something that only happens in newer projects, so its not the default for all code, so it's much trickier to understand why and how we can avoid this.

[kean]

Got you. Yeah, it appears to be a common issue with Swift 6 libraries being used from pre-concurrency code that doesn't enforce actor isolation at compile time. Based on the crash log, MBRecentsDashboardCell does get instantiate in the background. Is that the case? Is that something you can reliable reproduce and address?

[freak4pc]

We're not able to reproduce it unfortunately, if it would crash while debugging that'd be amazing.
Anyways I think it just might be worth a warning somewhere in the README as it is quite a risk for 13.x users.

Should I close this? Not sure there's much you can help me with (wish there was lol)

[kean]

The pragmatic option is probably to disable Swift 6 in the shipped framework (via swiftLanguageModes: [.v5])) and continue using it only during development. I have an Xcode project just for that. I'll explore this option today.

[freak4pc]

By the way, I think adding -disable-dynamic-actor-isolation in swiftSettings is also one way to prevent the compiler from injection these assertions. not sure if thats something you'd want

[kean]

I got to the point on the weekend where I was able to repro this crash.

For some reason, the root cause is this closure in LazyImage.init:

url.map { ImageRequest(url: $0) }

I know there are some weird rules and exceptions around closures in Swift Concurrency, and I can't say I understand them, but this turns out to be one of them. If I replace it without map, it eliminates the crash for me. Apparently, the compiler no longer has a place to insert an assertion.

-disable-dynamic-actor-isolation in swiftSettings is

I tried inserting it in both SwiftPM modules and the project that integrates it, but it does't seem to do anything in this case. I'm also not sure unsafeFlags is something you should use for non-local packages, but I would certainly opt out of the "please don't crash my framework without any warnings" behavior if I could.

[kean]

I consulted with the gurus and fixed it with one weird trick by removing seemingly harmless non-escaping closures. Shipping 13.0.6 momentarily as soon as CI is green.

[freak4pc]

Now I'm super curious who are your consulted gurus 🤣

[freak4pc]

@kean Interestingly downgrading to 12.9 didnt solve the issue and it's still crashing.
Should I try just upgrading to the latest 13.x ?

[freak4pc]

Hey @kean, i can't reopen this issue but the latest version didnt fix it.
This is a crash from our latest release that targets Nuke 13.0.6.
Seems like the same built-in concurrency assertions:

[kean]

Well, looks like it only fixed a subset of issues that I was able to reproduce. If you could share an example how to reproduce this crash, it would help.