UIKit: detect GL and Metal backing layers

[brianconnoly]

Summary

• detect GL/Metal-backed UIKit windows by inspecting the view's backing layer
• keep the existing redraw queue path for CAEAGLLayer/CAMetalLayer-backed views

Related: #4620 preserves queued GPU redraws while the UIKit event loop is waiting.

Validation

• git diff --check
• CARGO_TARGET_DIR=/Volumes/RustBuilds/vibe-scrap-squad/target/winit-fork-uikit-layer CARGO_INCREMENTAL=0 cargo check -p winit-uikit --target aarch64-apple-ios

[tronical]

I must be missing something, but ... isn't this new code doing the same as the old code? (except that it introduces the use of unsafe)

Edit: nevermind, I see now that it performs the check on the layer, not the view.

[tronical]

Instead of this unsafe, block, would it be possible to use https://docs.rs/objc2-ui-kit/latest/objc2_ui_kit/struct.UIView.html#method.layerClass to obtain the class and then perform the check?

[brianconnoly]

Good suggestion to avoid the handwritten unsafe block. A direct UIView::layerClass call would inspect the base UIView class, while subclasses may override it, so it is not equivalent to checking the actual backing-layer instance. I enabled the objc2-quartz-core bindings and now use the safe typed view.layer() result followed by isKindOfClass checks. This removes the raw pointer and the entire unsafe block.

Verification: cargo check -p winit-uikit --target aarch64-apple-ios passes on macOS. I also tested the same typed access pattern through our 0.30 patch lineage on a physical iPad: signed install and launch passed, rendering looked correct, and the app remained alive through a controlled suspend/resume.

[tronical]

Thanks, this looks much better. I'm curious though: How do you set up your layers?

(We're using raw-window-metal, which creates the CAMetalLayer as a sub-layer, so this is a no-op either way)

[brianconnoly]

Thanks for asking — you are right about the layer setup. I went back and isolated the configurations on a physical iPad rather than relying on our downstream integration. Our supported path uses raw-window-metal in the same way: the CAMetalLayer is installed as a sublayer of the winit UIView, so this check is a no-op for us.

The confusion came from a separate downstream experiment where WinitView inherited MTKView directly. A controlled A/B showed that the experiment is not needed and that its delegate duplicates redraw delivery, so it does not provide a valid reason for this change.

Given that, I do not have a concrete upstream use case for this PR. Rather than broaden its scope speculatively, I am closing it. Thanks again for catching the assumption.