Same problem with XCode 15 Betas (up to 5 15A5209g) and iPadOS 17 Betas (up to 21A5291h) [update] My CDDisplayLink kept firing when Scene was inactive. Here is the workaround: class SceneDelegate: UIResponder, UIWindowSceneDelegate { func sceneDidBecomeActive(_ scene: UIScene) { NextFrame.shared.pause = false } func sceneWillResignActive(_ scene: UIScene) { NextFrame.shared.pause = true // ... } } public class NextFrame { public init() { link = CADisplayLink(target: self, selector: #selector(nextFrames)) // ... } @objc func nextFrames() -> Bool { guard !pause else { return false } // ... } }

Fixed by using . MacOS 13.4.1 . Xcode 15 beta 2 . iPadOS 17 Beta 2

Posted solution is not the solution. See, below.

Maybe it works, my config: iPad Pro 11" iPadOS 17 Beta 2 Xcode 15 Beta 2 MacBook Pro 13.4.1 In manage Run Destinations [+] Apple Vision Pro (not any VisionOS Simulator Device) => Wait for download and Run I can only partially confirm, as am getting a runtime error at UIScreen.main.displayLink(withTarget: self, selector: #selector(nextFrames)) So, at least it is running on my iPad. Good luck!

@royascuder, thanks for the reply. Took me a while to realize that the red text was source code highlighting, here are the steps: Current Xcode version from AppStore? Yes; XCode 14.3.1, plus current MacOS from AppStore Install any relevant Components? Failed; this is the stated problem Manually support Device files? Not available, iPadOS 17 not on the usual GitHub repo. Use Xcode 15.0 Beta? Failed; does not appear in Devices Windows (XCode > Window > Devices & Simulator) Reset Trust Settings on iPad / Trust this Computer? Yes. Shows up in XCode 14.3.1, but not XCode 15.0 Switch USB C Ports (as per another Thread)? Yes. No changes Reboot? Yes, all devices, and restarted 14.3.1 with 15.0 running in extensions Minimum Mac requirements? Yes; MBP M1 Max Reinstall XCode? Yes for 15, not yet for 14.3.1, which would be painful. Clear derived Data? Yes. Several betas ago, a similar device update issue was resolved automatically, perhaps a server issue? I am developing specifically for iPad Pro's Pencil + Camera + Midi input. So, Simulator is not an option. Since 2019, I've gone Digital Nomad; am in Bali. Before then, I had every single Apple iDevice since original iPhone, iPad, Watch etc. But, going nomadic means relying on a minimal setup. This is a common use case. Have met dozens of developers like me, here. For Indonesia, you have to register devices over $600. Many of us here are on long term single entry visas. Flying to Singapore to buy a redundant iPad to fix a problem that will probably be resolved in a few days if not weeks is problematic. Expect a lost week of development. Plus, you have to restart the immigration hassle. For digital nomads, redundant devices is problematic. Again, this is a common use case. Perhaps, Apple should adjust. Is this my problem or Apple's problem? Kinda both. Apple's Problem: The Device Support File issue seems to reoccur for initial betas. My Problem: I usually wait until after the first Beta update. Oops! Am going all-in on VisionOS. I suspect that iPadOS 17 will be essential. So, how to get Device Support of iPadOS 17 beta? Or, worst case: revert back to iPadOS 16?

The " Streaming an AR Experience" sample code works on two devices (haven't tried simulator). It actually is much smoother on only Bluetooth; chokes on WiFi. In fact, I found your post while search on how to make MultiPeerConnectivity exclusive on Bluetooth. I have a bare bones app to test Session and Streaming APIs here: https://github.com/musesum/MultiPeer -- maybe that would help

So, the Apple button example for @State has no real utility as a button. To be honest, I find a View's ability to interleave (procedural) state with (declarative) layout and gestures to be rather complex. Currently, am using a MVVM pattern; a combination of Model, ViewModel (or Vm), and View. The Vm is passed as an @ObservedObject and receives the View's .onAppear and .onChange messages. This eliminates the View's need for @State, @Binding, and @StateObject. So, the Vm focuses on the state machine, while the View focuses on layout and dispatching gestures. A Vm class can also persist and synchronize across devices, such as iWatch-iPhone-iPad-AppleTv-SharePlay, etc. But, maybe there is a better way of accomplishing the same goals with a self modifying struct. I dunno; still trying to wrap my head around the best approach. Thanks.

var tasks = Set<Task<Void, Never>>()

"why swiping to Desktop 2 ?" Not enough screen real estate. I work off a laptop and optionally sidecar an iPad. Desktop 1 for code, Desktop 2 for Browser, Email, etc.