Could be related to this WebKit bug involving SameSite cookie policies: https://bugs.webkit.org/show_bug.cgi?id=279153
macdrevx
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
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.
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.
@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…
@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)
This appears to be resolved in Xcode 16
Thanks for the reply. Here's the bug report: FB14095059
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.
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.
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.