Can confirm, did you find any workaround?

I see, thank you. That's what I suspected but hoped there would be a better solution. Yes, they will. Are you saying that your watch app is the valuable bit, and the iOS app doesn't do anything without the watch app? Well, it's a fitness/workout app, and most users use the Watch to actually work out. The phone app is just for setup and checking your data. (workout is also possible but users prefer to use the watch) You didn't say whether the watchOS app is independent or not. Yes, my app is not independent. Not that I can think of, aside from communicating that watchOS 11 will be required with the next version of the app. Communicating the requirement of watchOS 11 (regardless of the channel) won't be noticed by all users running watchOS 10. Hence, many auto-updated iOS apps will render the app useless to most of these users. To conclude: The only "proper" workaround is to make the watch app independent, so users on older hardware can keep the older version. Correct? (I'm aware that making the app independent will imply a whole bunch of other issues, especially when it comes to data sync and DB schemes...)

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?

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'm getting the same error. Did you find any solution?

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).

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.

We're using the third one: MyReplyHandler2

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?

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!

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.

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.

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

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

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?