The Feb 29, 2024 Apple Developer News article titled Privacy updates for App Store submissions seems to clarify that the signing requirement only applies to binary dependencies.

Also, to clarify — we believe that Xcode is responsible for making the unexpected modifications to Package.resolved for several reasons: The unexpected edits do not occur if the project is not open in Xcode None of the other files in our project are impacted by this problem when changing branches It seems unlikely that 3rd-party tools like the git CLI would contain special treatment for the Package.resolved file.

Another update on this issue — I'm now able to repro the issue when switching branches using Xcode as well as 3rd-party git clients. Also, using FSMonitor (https://fsmonitor.com), I've confirmed that Xcode is the process that modifies Package.resolved unexpectedly.

Thanks for the reply. Here's the bug report: FB14095059

This appears to be resolved in Xcode 16

@DTS Engineer this issue is still present in Xcode 16 RC (Version 16.0 (16A242)). (I just noticed that the RC appears to have the same swift version, so this makes sense)

@DTS Engineer that works but only when I have SWIFT_COMPILATION_MODE = singlefile If I use SWIFT_COMPILATION_MODE = wholemodule, then the issue still occurs. Perhaps this suggests a further workaround of moving the offending code into a separate module…

Sharing a further cross-post: https://forums.swift.org/t/seeking-workaround-for-issue-76171/74518 I've realized that in our full project, there is other code beyond WKWebView.isInspectable that must also be causing this issue, but I don't know of any good ways to identify all of them. I did find one other piece of code that causes the problem by tearing the project down bit by bit until the error went away — a usage of URL(fileURLWithPath:) within an extension method on WKWebView. Other than being in an extension of WKWebView, it's not clear how this relates to the cause identified in the original post. Suspecting something related to extensions of classes from WebKit, I tried refactoring all such extensions into helper classes, but this did not help.

We found a workaround — use Task instead of Task.detached. This happens to work regardless of whether the compiler see the NSItemProvider closures as main-actor isolated.

Could be related to this WebKit bug involving SameSite cookie policies: https://bugs.webkit.org/show_bug.cgi?id=279153