Ventura 13.1 Beta WebKit crash?

I’m testing the latest Ventura beta (beta 2 of 13.1) and am seeing massive failures in WebKit. This is in an app built with Xojo 2019R1.1, using MBS Plugins 21.3, in a x64 build running on an M1 mac. My app is using the WKWebViewControlMBS

My Xojo App itself is not crashing, the WKWebViewControlMBS is just empty - the crash log shows that it’s WebKit itself which is crashing.

Crash Log
Translated Report (Full Report Below)

Process:      [2746]
Path:                  /Volumes/VOLUME/*/WebKit.framework/Versions/A/XPCServices/
Version:               18614 (18614.
Build Info:            WebKit-7614003004011002~3
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
Responsible:           MyApp [2669]
User ID:               501

Date/Time:             2022-11-13 14:56:39.2670 -0800
OS Version:            macOS 13.1 (22C5044e)
Report Version:        12
Anonymous UUID:        FBBCB89E-FDE9-DC5F-A772-C2A232F4CD15

Time Awake Since Boot: 450 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue:

Exception Type:        EXC_BREAKPOINT (SIGKILL)
Exception Codes:       0x0000000000000001, 0x00000001aebfe8d0

Termination Reason:    Namespace PAC_EXCEPTION, Code 1 

Thread 0 Crashed::  Dispatch queue:
0   JavaScriptCore                	       0x1aebfe8d0 WTFCrashWithInfoImpl(int, char const*, char const*, int, unsigned long long) + 4
1   WebKit                        	       0x1b53971dc WebKit::AuxiliaryProcess::didReceiveInvalidMessage(IPC::Connection&, IPC::MessageName) + 612
2   WebKit                        	       0x1b55b4b74 IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >) + 1424
3   WebKit                        	       0x1b55b750c WTF::Detail::CallableWrapper<IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)::$_13, void>::call() + 188
4   JavaScriptCore                	       0x1aec3fb90 WTF::RunLoop::performWork() + 200
5   JavaScriptCore                	       0x1aec408c8 WTF::RunLoop::performWork(void*) + 36
6   CoreFoundation                	       0x195493a18 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
7   CoreFoundation                	       0x1954939ac __CFRunLoopDoSource0 + 176
8   CoreFoundation                	       0x19549371c __CFRunLoopDoSources0 + 244
9   CoreFoundation                	       0x195492320 __CFRunLoopRun + 836
10  CoreFoundation                	       0x195491888 CFRunLoopRunSpecific + 612
11  Foundation                    	       0x196399e58 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
12  Foundation                    	       0x196412cf0 -[NSRunLoop(NSRunLoop) run] + 64
13  libxpc.dylib                  	       0x19512f380 _xpc_objc_main + 860
14  libxpc.dylib                  	       0x19512eca0 xpc_main + 108
15  WebKit                        	       0x1b53c69ec WebKit::XPCServiceMain(int, char const**) + 256
16  dyld                          	       0x19508be50 start + 2544

This wasn’t happening in the first beta of 13.1, but I’m not sure if this is an Apple bug, related to Xojo, MBS plugins, etc.

Anyone else seeing massive problems with macOS 13.1 (22C5044e) ?

Edit: I’ve reported to Apple as FB11786440 if anyone else is running into this.

Update: I’m also seeing this with a WKWebView which is part of a Swift app, where there are no Xojo or MBS Plugins in use. This seems very much like an Apple bug.

Updated to 13.1 beta 3, and it’s still happening. This is worrying me, as Apple usually doesn’t have too many betas for these .1 releases.

It appears the problem is that HTMLViewers and DesktopHTMLViewers that are built for Intel no longer work on M1 macs.

Am I the only one seeing this? Would appreciate if someone else can reproduce this bug - please test the sample project here:

Yes, I can reproduce the crash. The crash also happens with Xojo 2022r3.


1 Like

But you are saying that it is only an Intel WebKit that crashes when run on an M1 Mac? Can you not simply build for Universal. Also, if it is not Xojo specific you surely need to report it to Apple?

@Beatrix_Willius : thanks for the confirmation, I was worried it was just something I alone was seeing


  • yes, it appears that building for Arm or Universal is a workaround, however this affects apps built with older versions of Xojo that predate the Arm compiler
  • I’ve added a XCode / WKWebview project which reproduces the crash, so this is 100% an Apple bug
  • I submitted a DTS/TSI incident this morning, but the autoreply says that Apple is taking Nov 15 through 27th off for the holidays, so I’m not expecting anything to come back quickly :frowning:
1 Like
  • older versions of Xojo (such as 2019r1) use the older WebView (WebKit1) rather than the newer WKWebView (WebKit2) control still work OK. I believe the changeover happened around the time of API2, which would be 2019R2 or later?
  • unfotunately, my main app is built using 2019r1 (yay!) but uses the WKWebViewControlMBS which does show the bug

Well, all the older versions of my app have the hard crash for RuntimeException.stack which crashed every dialog on Intel for Ventura. Using older version of Xojo on the sugar show that is Ventura is not a good idea.

Actually, I just ported your RuntimeException crash sample project back to API1.1, built it in Xojo 2019R1.1 (Intel only) and it seems to work fine in Ventura 13.1 beta 3 on M1.

My general experience (until the Webkit bug being discussed in this thread) has been that Intel Apps built with 2019R1.1 are quite stable on Ventura.

My theory is that the new API2 controls, perhaps in conjunction with the ARM compiler, are what is giving Xojo trouble…

1 Like

Apple replied to my TSI saying basically “there is no workaround, it’s still under investigation” - and credited me back the TSI.

I choose to interpret this as good news, in that it’s on their “Radar” (haha). Hoping it gets fixed by Ventura .1 beta 4?