same here [quote='793556022, JohnC2, /thread/678219?answerId=793556022#793556022, /profile/JohnC2'] I'm starting to see pieces of code where people simply instantiate a UIHostingController, grab the view from it and put it in their view hierarchy without properly adding the hosting controller instance as a child view controller of a parent view controller and such. [/quote]

x-posted as FB20456671

We're also seeing this: FB17747993

I'm seeing this in my project as well.

Thanks for the reply. It seems clear from the data that something about our app changed to result in the increase in terminations. If it were just due to other apps, I don’t think we’d see quite the same step change. Possibly related: can the system terminate a non-suspended app that is running in the background due to system pressure? That could explain why we don’t see a difference in memory at suspension.

Thanks for the replies! I just updated the FB with full crash reports. Several users have shared content with us, however it's not entirely clear which part of it is resulting in the crash. So far, our attempts to repro by loading that user-supplied content have not been successful in reproducing the crash. The app uses a variety of text rendering methods: UITextView, UILabel, UITextField, WKWebView. We also use some 3rd-party libraries in certain situations, some of which do appear to use CoreText and TextKit2.

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

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.