Ok, specific problem then. I downloaded Emoji Rangers, switched language mode to Swift 6, udpated some static vars to static lets, commented out the contents of ImageURLProtocol.stopLoading and finally got to the issue in AdventureView.swift: This error is the one I can't seem to solve - Main actor-isolated value of type '() async -> Void' passed as a strongly transferred parameter; later accesses could race. As far as I understand it, here it basically means that something that is not Sendable is being sent between contexts. It is not possible to remove @MainActor here because activityViewState is isolated to it: And even if this was not a factor, the original error reappears once activityViewState is no longer in the picture: The only workaround I've found feels wrong: extension Activity: @unchecked @retroactive Sendable {}

Well, I updated to Xcode 15.4 and it works now. Don't see anything about this in the changelog, but I'm glad it's sorted.

Nope, neither of those work. Creating an Xcode project as a wrapper that only exists to hold the package is one workaround. But this is clearly some kind of bug, because it worked in previous Xcode releases. It also works with some of my other packages (with no Xcode project).

Thanks, but this is a Swift Package. There are no build settings except for Package.swift.

Hey Quinn, thanks for responding. I was about to write that your suggestion will crash, but it turns out that only true for the async version. The version with the replyHandler that you posted does get called from the main thread, while the async one seems to be called from arbitrary threads (and thus crashing). I submitted feedback FB13774556.

Hey, has there been any progress on this? The feedback assistant report hasn't seen any activity, but since nobody replied to the number, I suppose it might have been overlooked...

Hey, this is happening in CI, which runs our builds in a VM, so we always have a clean environment (with a brand new simulator). I've actually watched the session on interruptions earlier and am now testing to see if I can make it work. The session mentions there are built-in interruption monitors for common system dialogs - shouldn't this be added there too? There is nothing for the test to do besides tapping the "Continue" button anyway...

Thank you for responding! I have already filed a feedback for this: FB7724987