app crashes on iPadOS 26

[zaratounga]

Unable to run the web app, either a locally stored one or the one on the webpage on iPadOS 26 public release

[mithrendal]

currently downloading iPadOS 26 ... still 3 hours to wait until download finished

[zaratounga]

ouch.. 😣 that’s a lot, I was lucky when I started the update, must be a lot of downloads right now. Thanks for having a look 👍

[ejelly]

Same on macOS 26, by the way. Might be easier to debug there.

[mithrendal]

I bet it has something to do with the build settings. What makes me think this is that a very old and unoptimized build still works. When I am back from holiday I will look into it. Apple timed the OS 26 attack perfectly with the beginning of my holidays 😂

[mithrendal]

ok I managed to find the issue ... it seems that macOS 26 Tahoe and iPadOS 26 can not handle native wasm-exceptions correctly anymore.

These native wasm exceptions are used in the last years in vc64web when we compile and link with -fwasm-exceptions at both compile time and link time. As a result, it reduced the code size and performance overhead compared to the old JavaScript-based implementation.

Now when I recompile and link with the old style software emulated exception implementation -fexceptions then it works fine again.

What should we do now ?

Wait that apple fixes its broken safari browser or switch to the legacy exception implementation ? Or publish the fix for tahoe safari only (all other browsers work fine... and I guess the next tahoe implementation will do so again)

see here

https://emscripten.org/docs/porting/exceptions.html

https://github.com/WebAssembly/exception-handling/blob/master/proposals/exception-handling/legacy/Exceptions.md

https://webassembly.org/features/

[mithrendal]

just published a build where I downgraded from the native wasm-exceptions to the slower javascript exception so that Safari 26.0 can handle it.

I expect that Apple fixes this and we can with safari 26.1 again use the faster wasm-exceptions. Until then we have a performance hit of around 14% due to apples latest OS :-(

Instructions:

• as Safari 26.0 can not start the vc64web app at all that means that also the upgrade workflow is broken ...
• You have to open a private safari tab and add the app to the dock again or in case of iPadOS add it to the home screen again
• when apple bug fixes its Safari in version 26.1 then the previous broken vc64web apps should work again and you get access to your saved snapshot data

[zaratounga]

Thanks a lot, looks like Apple still have a lot to fix on the latest release, especially on iPadOS26 but probably not limited too, It’s been only days but I’ve seen quite a lot of annoying bugs all over the place.

[dirkwhoffmann]

It’s been only days but I’ve seen quite a lot of annoying bugs all over the place.

same here 🤬

[mithrendal]

I just started a broken and docked vc64web app under macOS and I got the upgrade message. Self healing 😎. I previously thought the upgrade process was affected too by the safari 26.0 bug... Seems I was wrong ... all data is back on the upgraded docked vc64web app.

[mithrendal]

I opened a bug report in webkit. https://bugs.webkit.org/show_bug.cgi?id=299629

@eugeneia Could the following commit of yours be the reason why modern EH is no longer working in the two Commodore Emulators vc64web and vAmigaWeb on Safari 26?

https://github.com/WebKit/WebKit/commit/9a7661eb51582e1fbbb0b5d21fd5eba4cc057c4e

meanwhile I rebuild the two emulators to use the old slower legacy EH -fexceptions (performance impact around 14% 😥) so that it runs also in safari26... for testing I put a special build with the previous used modern and faster EH on https://vamigaweb.github.io/uat

It's best to use private tabs for testing, as both projects rely heavily on caching to support offline functionality.

[mithrendal]

Ok I tracked the problem down to this

only when using LinkerFlag -O3 and -fwasm-exceptions and Safari26

then it does not catch exceptions with the following statement catch(...)

for example

    try { emu->isReady(); } catch(...) { 
        EM_ASM({
          setTimeout(function() {message_handler( 'MSG_ROM_MISSING' );}, 0);
        });
    }

will produce an unhandled exception stopping the web app

if I change the code to catch(std::exception& e)

    try { emu->isReady(); } catch(std::exception& e) { 
        EM_ASM({
          setTimeout(function() {message_handler( 'MSG_ROM_MISSING' );}, 0);
        });
    }

then it can be handled by Safari26.

if we lower down the LF from -O3 to -O2 then it also works with catch(...) statements

just pushed a vc64web build with LF=-O2 to have the better performance back.