* macos: fix Vulkan/Metal renderer on macOS 26+ and bump MoltenVK
Four related changes that together let the Vulkan backend boot a game
on Apple Silicon Macs running macOS 26.x. Each is needed independently;
the combination was tested on a Mac16,6 (M4 Max) / macOS 26.4.1.
CMakeModules/DownloadExternals.cmake:
Bump bundled MoltenVK from v1.2.9 to v1.4.1. v1.2.9 does not
recognize macOS 26 surface objects and traps with an Objective-C
"unrecognized selector" inside vkGetPhysicalDeviceSurfaceCapabilitiesKHR.
src/video_core/renderer_vulkan/vk_instance.cpp:
Disable VK_EXT_tooling_info on MoltenVK. MoltenVK advertises the
extension but does not expose vkGetPhysicalDeviceToolPropertiesEXT
through its dispatcher, so the call inside CollectToolingInfo()
trips a vulkan-hpp assertion in Debug and dereferences NULL in
Release.
src/citra_qt/bootmanager.cpp:
Force-install a fresh CAMetalLayer on the NSView before handing it
to createMetalSurfaceEXT. Qt 6.11's QWindow::MetalSurface does not
always back the view with a CAMetalLayer on macOS 26, and MoltenVK
1.3+ aborts in MVKSurface::getNaturalExtent() if the layer is not
the right class. Implemented via objc_msgSend so no .mm conversion
is needed.
src/citra_meta/CMakeLists.txt:
Gate LaunchScreen.storyboard behind 'if (IOS)'. The storyboard is
iOS-only and previously broke the Xcode generator on macOS with
"iOS storyboards do not support target device type 'mac'."
* Move Metal layer creation logic into MetalUtil::CreateMetalLayer ObjC++ function
This change makes the code much more readable, as the logic is now in its native language
---------
Co-authored-by: SergeyMild <>
Co-authored-by: OpenSauce04 <[email protected]>
* [cmake] Fix MoltenVK fetch order/library conflicts
Rather than dealing with `find_library` shenanigans, just set the
library path directly (when using bundled MoltenVK). System MoltenVK
solely uses `find_library`.
Avoids cache nonsense that can cause system/bundled versions to get
mixed up, and overall makes the system/bundled mvk handling a lot more
consistent
```
cmake -S . -B build -DUSE_SYSTEM_MOLTENVK=ON
-- Using MoltenVK at /opt/homebrew/lib/libMoltenVK.dylib.
cmake -S . -B build -DUSE_SYSTEM_MOLTENVK=OFF
-- Using MoltenVK at /Users/crueter/code/azahar/build/externals/MoltenVK/MoltenVK/dynamic/dylib/macOS/libMoltenVK.dylib.
cmake -S . -B build -DUSE_SYSTEM_MOLTENVK=ON
-- Using MoltenVK at /opt/homebrew/lib/libMoltenVK.dylib.
```
Signed-off-by: crueter <[email protected]>
* remove old comment
Signed-off-by: crueter <[email protected]>
* Cleanup
---------
Signed-off-by: crueter <[email protected]>
Co-authored-by: OpenSauce04 <[email protected]>
* build: Rework CI and move all bundling into new build target.
* ci: Use "mingw" in msys2 release names for compatibility.
* ci: Use "osx" in macOS release names for compatibility.
* ci: Disable macOS upload.
Will be moved to a separate PR for canary merge.
The mingw builds aren't submitting telemetry because the curl library
they are linked against is configured to use openSSL and openSSL looks
for the certificates in the users home folder. This keeps it from
contacting web services because it can't communicate over SSL.
This commit adds a download in mingw builds that will download a
precompiled curl for mingw linked against winssl and sspi.
