[iOS] Panic on CaptureMTLDevice when requesting adapter with Xcode GPU Frame Capture enabled (v29.0.0)

[jinleili]

Description
After upgrading wgpu from v28 to v29, running my iOS app natively on a device with Xcode's GPU Frame Capture enabled immediately crashes.

Repro steps
The initial crash occurs when wgpu_hal::metal::AdapterShared::expose attempts to call supports32BitFloatFiltering on the device, resulting in an unrecognized selector error. If this is patched dynamically via Objective-C runtime, it immediately crashes again on hasUnifiedMemory.

These selectors seem to be unimplemented by Apple's private CaptureMTLDevice proxy object used during Metal frame capture. wgpu v28 handled this gracefully (or did not query these capabilities directly through objc2-metal).

Extra materials
Stack traces:

thread '<unnamed>' panicked at /.../objc2-metal-0.3.2/src/generated/MTLDevice.rs:
invalid message send to -[CaptureMTLDevice supports32BitFloatFiltering]: method not found
...
  15: objc2_metal::generated::__MTLDevice::MTLDevice::supports32BitFloatFiltering
  16: wgpu_hal::metal::adapter::<impl wgpu_hal::metal::CapabilitiesQuery>::new
  17: wgpu_hal::metal::AdapterShared::expose

And after swizzling supports32BitFloatFiltering, the crash moves to hasUnifiedMemory:

thread '<unnamed>' panicked at /.../objc2-metal-0.3.2/src/generated/MTLDevice.rs:
invalid message send to -[CaptureMTLDevice hasUnifiedMemory]: method not found
...
  15: objc2_metal::generated::__MTLDevice::MTLDevice::hasUnifiedMemory
  16: wgpu_hal::metal::adapter::<impl wgpu_hal::metal::CapabilitiesQuery>::new
  17: wgpu_hal::metal::AdapterShared::expose

Platform
macOS v26.3, Xcode v26.3, iOS v26.3, wgpu v29, .

[jinleili]

For anyone else currently blocked by this while developing and needing Xcode's GPU Frame Capture, here is a temporary client-side workaround.

The root cause is that when GPU Frame Capture is enabled, Xcode wraps the actual MTLDevice in a private proxy class called CaptureMTLDevice.

Since this proxy is an Objective-C object, we can use the Objective-C runtime to dynamically inject these missing methods at app launch, gracefully defaulting them so wgpu doesn't panic.

import UIKit
import ObjectiveC

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        
        // [wgpu v29 workaround]: Patch Apple's CaptureMTLDevice missing selectors
        // to prevent unrecognized selector panics when GPU Frame Capture is enabled.
        if let captureDeviceClass = NSClassFromString("CaptureMTLDevice") {
            let blockFalse: @convention(block) (Any) -> Bool = { _ in false }
            let impFalse = imp_implementationWithBlock(blockFalse)
            let blockTrue: @convention(block) (Any) -> Bool = { _ in true }
            let impTrue = imp_implementationWithBlock(blockTrue)
            
            // Fix 1: supports32BitFloatFiltering
            let selFloat = NSSelectorFromString("supports32BitFloatFiltering")
            if !class_respondsToSelector(captureDeviceClass, selFloat) {
                class_addMethod(captureDeviceClass, selFloat, impFalse, "B@:")
            }
            
            // Fix 2: hasUnifiedMemory
            let selUnified = NSSelectorFromString("hasUnifiedMemory")
            if !class_respondsToSelector(captureDeviceClass, selUnified) {
                // Return true for iOS since physical devices have unified memory
                class_addMethod(captureDeviceClass, selUnified, impTrue, "B@:")
            }
            
            // Fix 3: supportsRaytracing
            let selRaytracing = NSSelectorFromString("supportsRaytracing")
            if !class_respondsToSelector(captureDeviceClass, selRaytracing) {
                class_addMethod(captureDeviceClass, selRaytracing, impFalse, "B@:")
            }
        }

        // ... continue with standard setup ...
        
        return true
    }
}

[andyleiserson]

It seems that CaptureMTLDevice actually does catch the "method not found" exception when these are called and handles them. (We called them even before switching to objc2.) But in debug builds, objc2 inserts a pre-check for validity before method calls, which is what is panicking.

I opened a PR that puts additional guards before calling these methods.