Wondering if you were able to solve this as we're facing a similar behavior of .xcresult files getting huge. Weird thing on our side is that we have several projects in our workspace and only one is affected.

We're facing a very similar issue (not with Alamofire but another dependency). Is there any workaround for this?

It looks like not much has been added in the last year by we're still facing the same issue. Is there any known solution to this issue?

Having the same issues. Also tried to sign out and in again in Xcode preferences. Didn't help :( Any other suggestions?

This one was fixed, at least of Xcode 14.0 it seems to be working fine

I wanted to share a crash report but before I did I inspected it once more in detail (with 3rd party editor rather than Xcode) and could see some information that are not included when inspecting from Xcode Crashes view: [...] Exception Note: EXC_CORPSE_NOTIFY Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [43798] Triggered by Thread: 10 [...] So what's interesting here is that this is actually not crashing in JavaScripCore but it's a segmentation fault (The way the crash report is shown in Xcode is misleading). We used to get a "segmentation fault: 11" every time when implementing the async/ await API of WKScriptMessageHandlerWithReply with Xcode 13 as I stated here. It seemed to be resolved as of Xcode 14, but now it simply happens only occasionally (We're unable to reproduce but our users are). So my best guess for now is that one shouldn't use the async variant of the WKScriptMessageHandlerWithReply API but wait for  to properly fix it.

Update: By now we rolled out an update of our app including the change to use the non async/await API of WKScriptMessageHandlerWithReply. Unfortunately it doesn't make a difference. Any other ideas how to solve this Segmentation Fault 11 crash are most welcome! Update @eskimo: I shared the crash logs with you as discussed.

Do any of the crash reports you sent me reflect that change? ’cause as far as I can tell they’re all doing async replies. They should. But to make sure I verified and sent some that definitely do!

Hmm that doesn't make any sense to me. If you check the same crash report you can see in frame 6 that this was called from the non async handler, i.e. replyHandler: 6 tttt ... closure #1 in ScriptMessageHandler.userContentController(_:didReceive:replyHandler:) + 64 (ScriptMessageHandler.swift:57) -> In other words it is stating that the non async API userContentController(_:didReceive:replyHandler:) is invoked. Why should it report later (in frame 2) that we're using the async handler. Maybe the "AsyncReply" part of the message ___ZN28ScriptMessageHandlerDelegate28didPostMessageWithAsyncReplyER is referring to the fact that this is an asynchronous API (using a closure) and not that it is using the async/await concurrency language feature?

We're using the third one: MyReplyHandler2

Thank you for your update. Sorry I confused something, we were using MyReplyHandler2 before, but changed to MyReplyHandler1 solution. I'll try your recommendation to dispatch the reply handler to main thread as you recommended and see if this helps.

By now we've used this change (to reply on main thread) for a few days and no longer see these crashes. Thank you! I guess it would make sense to fix this for WKScriptMessageHandlerWithReply or at least add a warning to the documentation (also for older versions).

I'm getting the same error. Did you find any solution?

Furthermore it would be great if the new Xcode 16 feature STRING_CATALOG_GENERATE_SYMBOLS could be used in SPMs as well. Xcode actually offers the refactor option even in string catalogs of packages (Convert Strings to Symbols). It automatically updates the catalog and the corresponding swift file, but it doesn't compile afterwards

I have an app currently built for iOS 18 with a companion watchOS app targeting watchOS 10. If I raise the iOS minimum deployment target to iOS 26, users on iOS 18 will no longer be able to update the app (which is fine). My question is about users who have phones running iOS 18 or iOS 26 (and thus can update the app on their iPhone) but have older Apple Watch hardware that cannot run watchOS 11 or later (and thus cannot update the watchOS companion app). • Will these users be able to update the app on their iPhone despite their watch being on an unsupported watchOS version? This would mean the app becomes useless for them. • If they update the app on the iPhone, will the watchOS companion app be removed or become non-functional because the bundled watchOS app requires at least watchOS 11? • How does Apple handle this situation where the iOS app can update but the companion watchOS app is not compatible with the older watch? • Is there any way I can prevent these users from updating the app to the latest version?