Metal/Vulkan is not a viable cross-platform replacement for OpenGL.
At the moment it is possible to have some custom OpenGL in JUCE software that will render identically on all major platforms that JUCE supports, and this fits well with with write-once-run-everywhere behaviour of the rest of the JUCE framework. Unfortunately the deprecation of native OpenGL on Apple platforms means that this will not continue to be the case forever.
If you are currently using custom OpenGL with JUCE then moving to WebGL within a webview is likely to be the least friction path to maintaining cross-platform support. WebGPU is the next generation web standard for interacting with GPU and this will probably be a better target in the future when support becomes more widespread, with source transformation tools to convert your WebGL code to WebGPU.
There will be people who cannot use an embedded browser, but the native options to continue using a single shader language are pretty restrictive.
There’s Google’s Dawn, that provides a native C++ interface to WebGPU, but this is both a very heavy dependency and is changing fairly frequently.
There’s Google’s ANGLE, that provides a translation later from OpenGL ES to the native backends on each platform, but again it’s a whopper of a dependency.
For both Dawn and ANGLE we would need to increase our minimum supported deployment targets significantly. If I don’t sound convincing about the complexity of having these projects as dependencies please attempt to build them yourselves and think about what a workable integration with JUCE would look like. We’re currently watching both projects and evaluating them again every few months.
Another option is using Vulkan with MoltenVK for Apple platforms. Whilst it’s possible to get this working, it certainly isn’t straightforward. The real blocker here may not even be the complexities of MoltenVK - Vulkan driver stability on older Windows machines is very unpredictable, to the point where Vulkan loses much of its promise as a viable write-once-run-everywhere target.
What we should be able to offer, however, is the ability to continue using a mixture of OpenGL/Metal to render JUCE components. Our OpenGL rendering pipeline is not complex, and we could implement the Metal equivalent at short notice. So if you are using JUCE’s existing OpenGL renderer to accelerate the drawing of JUCE components only (no explicit OpenGL code within you project) then this could continue to happen using Metal when Apple eventually removes OpenGL from its platforms.
Yes. Although we will continue to develop our non-webview GUI functionality as we don’t want to force a major rewrite upon everyone, I think that webview-based GUIs are ultimately the future. Moving away from C++ for GUI work will make the need for JUCE-provided widgets much less pressing, but we will see how things evolve. Initially we will provide something along the lines of plug-in parameter attachments, where there is an easy way to link a C++ plug-in parameter with a value in JavaScript, but styling sliders and buttons will be left to the user.