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