@bigzaphod @shadowfacts Yeah inherited async contexts can change too, the SDKs in Xcode 16 have added MainActor isolation all over the place including SwiftUI.View, sneakily changing the behaviour of tons of code accumulated over the years… Sort of our own faults for putting so much code in UI-related subclasses for so many years but 🤷‍♂️. Tooling should make this more obvious as well. In the mean time, I've started shifting code out of subclasses and into actors or abuse nonisolated

@bigzaphod @shadowfacts Yeah with synchronous methods things get a bit murky. But IMO if you are expecting your function to run off main, then you probably want your method to be `async` regardless anyways? At which point you can reach for nonisolated if needed. Agreed that naming scheme is unintuitive, we have an clearly obvious way to force something to run on main but the opposite is not true

@bigzaphod Technically the whole thing is that you don't _want_ to test any of this at runtime anymore and instead have compile time guarantees. If you want to ensure something is off main you'd just not mark the async function with MainActor or if you're in a type that is already MainActor isolated you'd mark that function as `nonisolated` to take it off