Since Xcode 27's Device Hub currently doesn't support sending a two-finger touch to a simulator, but does forward Mac trackpad pinch and rotate gestures to the iOS app as UIEvent.EventType.transform events, a possible workaround, in simulator builds only, is to add a UIPinchGestureRecognizer and UIRotationGestureRecognizer, which receive those events, and use their output to emulate the missing multitouch gestures.

Since Xcode 27's Device Hub currently doesn't support sending a two-finger touch to a simulator, but does forward Mac trackpad pinch and rotate gestures to the iOS app as UIEvent.EventType.transform events, a possible workaround, in simulator builds only, is to add a UIPinchGestureRecognizer and UIRotationGestureRecognizer, which receive those events, and use their output to emulate the missing multitouch gestures.

Since Xcode 27's Device Hub currently doesn't support sending a two-finger touch to a simulator, but does forward Mac trackpad pinch and rotate gestures to the iOS app as UIEvent.EventType.transform events, a possible workaround, in simulator builds only, is to add a UIPinchGestureRecognizer and UIRotationGestureRecognizer, which receive those events, and use their output to emulate the missing multitouch gestures.

This is disappointing.

Xcode 27 beta RC 1 release notes: Device Hub doesn’t currently support sending a two-finger touch to a device or simulator. (169537162) 🦗

This is in the Xcode 27 beta 4 release notes: ✅ Device Hub doesn’t currently support sending a two-finger touch to a device or simulator. (169537162)

This is in the Xcode 27 beta 4 release notes: ✅ Device Hub doesn’t currently support sending a two-finger touch to a device or simulator. (169537162)

I've tested Xcode 27 beta 4 and multitouch zoom gestures do not work in that version either. I am using macOS 26.5.2. Is it a known issue that Device Hub multitouch zoom gestures require macOS 27?

TIL, SwiftUI was released 7 years ago and TextField does support an API equivalent to UIKit's UITextField.clearButtonMode.

I have the same issue in visionOS 26, but in the context of the SwiftUI pushWindow API. Repro steps: App launches with window A visible. Window A users AVAudioPlayer to play continuous background audio. The app calls pushWindow, presenting window B. The audio stops. At this point AVAudioSession.interruptionNotification is received twice. A workaround is to resume the audio when AVAudioSession.interruptionNotification is received. This sounds glitchy.

@Vision Pro Engineer @drewolbrich Thank you for filing this bug report. This is helpful. At this time I don't have a workaround to address the unwanted cutout effect issue. Thank you for responding. Separately from this specific issue, I'd like to understand how RealityKit determines draw order between (not within) model sort groups, and between view attachments and scene geometry. (I'm aware ModelSortGroup's order parameter controls ordering within a group.) I can't find this documented anywhere. How do you recommend I go about getting this question answered? I've already submitted a bug report, a code-level support request, and posted to the developer forums.

Hi @Vision Pro Engineer I've created a sample app and attached it to FB22014370. The sample app contains a README file with repro steps and a description of the issue. I initially created a simpler sample app, and in that app, the issue could actually be fixed using breakthroughEffect as you suggested. (Incidentally, breakthroughEffect does not appear to fix the issue in the simulator.) However, in the actual app I'm working on, breakthroughEffect surprisingly did not solve the problem, and the cutout effect was still visible in that app. Through trial and error, I discovered that breakthroughEffect does not appear to help for scenes that use ModelSortGroupComponent and which also contain more than one ModelEntity with ModelSortGroupComponent assigned, and for which view attachments are positioned beyond the center point of the bounding box of model entities with the shared ModelSortGroup, from the perspective of the camera. This scenario is demonstrated in the sample app. In the sample app's README file, I've also included specific questions about the behavior of transparent view attachments when used with scenes that use ModelSortGroupComponent. I tried your OpacityComponent suggestion and the view attachment draw order I observed was the same as when I used the opacity view modifier. I appreciate any assistance you can provide to help address the unwanted cutout effect issue.

I was able to fix the issue this way: sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db \ "DELETE FROM access WHERE client = '/Users/drew/Library/Developer/Xcode/CodingAssistant/Agents/Versions/26.3/claude'" (anyone else trying this will have to change the user name in the string) and then sudo killall tccd and then restarting Xcode.

I was able to reproduce this issue in visionOS 26.2.

I believe I've discovered a workaround for this pushWindow bug. If I add the .restorationBehavior(.disabled) scene modifier to the WindowGroup corresponding to the pushed window, the bug doesn't happen. If the user pins a pushed window to the wall, the window doesn't disappear, and the app and all other apps that may call pushWindow aren't bricked until the next device reboot.