I've heard that learning WebGPU is a pretty decent alternative, it's cross-platform, has runners that are non-web, and has some of the niceties of Metal without being platform lock-in
Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.
"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.
You always need to explicitly say which platforms you target, and then test on those platforms.
The main questions should be "on which platform will my users run it" and "can I debug and test this".
So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).
The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM. In that regard there are also some interesting projects/opportunities.
Having shipped non-trivial WASM code in two projects That's not a positive thing. WASM is stuck in zone between living and the dead - just good enough (barely) to merit creating production code when you need the perf in browser but not good enough to register as industrial quality tool as it's not possible really to debug a WASM application.
If you really, really need the perf in your browser app, WASM may be the only option, but it's not really a good one.
Then again perhaps the devx was just not as bad as I expected given how often I had heard this warning.
...as others have said, this is a solved problem and has been for quite a while:
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
I might even go that far and say that this solution is on average more robust and more responsive than debugging native code in Xcode.
If you don't mind - what's your specific setup when debugging Sokol, I might start from replicating that workflow?
And only "works" for specific languages.
It should also work for all compiler toolchains that generate DWARF debug info, which is pretty much standard across all compiled languages, otherwise gdb or lldb couldn't be used either with those languages (Microsoft of course does its own thing, as is tradition, but its not like msvc supports wasm output in the first place - Blazor oth appears to support wasm debugging in VS and VSCode)
Given how bad most of WebAssembly tooling still is to this day, versus native languages, I was kind of sceptic.
Quite right.
After 15 years, browsers vendors still don't care about 3D APIs on the developer tools, you need to have a native version and hope that the issue is actually on your code and not something that the browser does.
Because of its nature and the browser sandbox, you have no idea if the application is actually working on customer browsers, or even be able to have workarounds like on native APIs.
Finally it lags a decade behind hardware capabilities being surfaced on the API.
However there is nothing else on the browser.
The only positive thing is being 3D APIs designed with managed languages in mind.