ocornut
WebGPU backend fails (device lost) on Safari 26 (macOS + iOS) when building to WASM using Emscripten
Version/Branch of Dear ImGui:
master
Back-ends:
imgui_impl_glfw.cpp + imgui_impl_wgpu.cpp
Compiler, OS:
macOS emscripten
Full config/build information:
Copy/paste from clipboard doesn't seem to work when running inside a browser so here's a screenshot running in Chrome:
Details:
I am not sure this is actually a bug in the ImGui WebGPU backend instead of a bug in Safari 26, but I wanted to report it here anyway in case someone else runs into this problem, or someone better at WebGPU debugging knows a way to further analyse. I also filed a bug against Safari directly with Apple.
I built a simple WebGPU application that can use both a native backend (using wgpu-native) or can be compiled to WASM using Emscripten, and uses Dear ImGui to render its UI. The application works perfectly in all of the following situations:
- Compiled to WASM/Emscripten in Chrome & Firefox, on both macOS and Linux
- Compiled to native using wgpu-native backend on both macOS and Linux
However, the ImGUI-related parts of the application do not work in the following situations:
- Compiled to WASM/Emscripten in Safari 26.1 (with WebGPU flags enabled obviously) on macOS, or on iOS 26 Safari (WebGPU enabled by default)
In the above scenario, WebGPU is working correctly in Safari for a simple triangle render pass, but as soon as I dispatch the ImGui render pass, the application aborts with a device lost (destroyed) error.
My application is directly derived from the example_glfw_wgpu.cpp example, and the problem can easily be reproduced with that example by compiling to WASM using Emscripten, serving the shell HTML using python http.server and loading it in Safari. The ImGui example also works fine for all other combinations of browsers and platforms, it is just Safari that fails.
I have not been able to get any kind of error information or validation messages from either Safari, Chrome, Firefox or wgpu-native, which suggest again the problem is not in the application itself, but the example hits some unsupported or bugged case in the Safari WebGPU backend.
I tried to pinpoint the exact point that triggers the error and the closest I got was the following statement on line 358 of backends/imgui_impl_wgpu.cpp:
wgpuRenderPassEncoderSetPipeline(ctx, bd->pipelineState);
My guess/assumption is that the pipeline for the ImGui render pass is configured to use some feature or bind group layout that triggers some internal assertion in the Safari WebGPU backend or causes some kind of invalid buffer access. So again, I do not think this is necessarily a problem in Dear ImGui itself, and this report is mostly intended to be helpful in case someone else runs into the same issue. I would not also not be surprised if some simple change in the ImGui WebGPU backend could potentially side-step this issue so ImGui could work on Safari even despite a potentially broken WebGPU backend, which would of course be preferred to having to wait until Apple fixes this (if ever).
Screenshots/Video:
No response
Minimal, Complete and Verifiable Example code:
- The example_glfw_wgpu.cpp included with Dear ImGui reproduces this problem when compiled to WASM using Emscripten when run with Safari 26.1 on macOS
- Live demo application I've been using can be accessed here [1]
[1] https://www.wouterbijlsma.nl/~wouter/tmp/wgpu-playground/wgpu-playground.html
I am also observing this. However, in Safari, the examples here are also failing with a "device destroyed" error: https://webgpu.github.io/webgpu-samples/?sample=computeBoids
All examples beyond the simple triangle rendering present this issue. These do not use ImGUI AFAICT, so perhaps it is not an imgui issue?
@RaulPPelaez yes I also suspect this might not actually be an issue in ImGui, and have filed a separate Safari bug report with Apple as well, I have extremely low confidence this will move anything on their side though.
That said, interestingly the webgpu-samples including the boids one work on iOS 26, but not on Safari 26.1 on macOS, while I would expect these use pretty much identical WebGPU implementations. Anything using Dear ImGUI works on none of them though, so there seems to be something specific that ImGUI is doing that breaks Safari everywhere.
My intuition is that while ImGUI might not actually be at fault, there could still be something it could differently to side-step the issues on Apple platforms. Or, maybe ImGUI is actually doing something outside of the WebGPU spec, but other platforms are just more forgiving. In any case the purpose of filing this ticket is primarily to inform others who want to deploy ImGUI + Apple and maybe nerd-snipe someone with better WebGPU debugging skills to pinpoint what's going on and possibly offer a workaround until Apple fixes their stuff.