I think it works the same way as how you submit a full Mac app. I am working on a prototype, so I created a separate project for Vision OS using the same bundle identifier. When I installed it, it replaced iOS version of the app I had installed from the App Store with with the full Vision OS version from Test Flight.

Add it from the "Supported destinations" on the first step: https://developer.apple.com/documentation/visionos/bringing-your-app-to-visionos

You can't use the option you selected for the iPad compatible VisionOS. You should see the: Any Apple VisionOS Device (armv7) But I don't know why you don't see this in the list, your settings look correct. Did you add Apple Vision to the general tab in the project for an existing iOS project? Remove the designed for iPad and add the Apple Vision destination. Try to create a new VisionOS App project to see if you have the build option.

Hopefully this fixed it by using optional binding of the Frameworks protocol type. @objc func setDelegate(vc: ViewController?) { if let delVC = vc as? FrameworkDelegate { self.framework = Framework() self.framework.delegate = delVC self.start() } }

I don't know buy this forum seems like a ghost town after beta release. Looking at daily posts, I don't see many answered.

Trouble is, I can't duplicate it on my own phone, so all I can use is the crash log from the app from someone else's device. Exception Type: EXC_BREAKPOINT (SIGTRAP) If the Swift runtime encounters a programming error, the runtime catches the error and intentionally crashes the app. This crash points to Thread 5 - some concurrency library: Thread 5 Crashed: 0 libswiftCore.dylib 0x000000019200ab74 _assertionFailure(_:_:file:line:flags:) + 308 (AssertCommon.swift:132) 1 libswiftCore.dylib 0x000000019207232c swift_unexpectedError + 484 (ErrorType.swift:188) 2 libswift_Concurrency.dylib 0x000000020f5397cc swift::runJobInEstablishedExecutorContext(swift::Job*) + 244 (Task.h:282) 3 libswift_Concurrency.dylib 0x000000020f53a1e8 swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 72 (Actor.cpp:1488) 4 libdispatch.dylib 0x000000018d212164 _dispatch_root_queue_drain + 396 (inline_internal.h:0) 5 libdispatch.dylib 0x000000018d21296c _dispatch_worker_thread2 + 164 (queue.c:6935) 6 libsystem_pthread.dylib 0x00000001feefd080 _pthread_wqthread + 228 (pthread.c:2612) 7 libsystem_pthread.dylib 0x00000001feefce5c start_wqthread + 8 (:-1) Since this error happened async, how can I find deterministically know what code triggered it? And if the thread was running long enough, maybe the code lines are not even still in the log. So my advice to myself is to wrap any async calls in its own function call so I can hopefully trace what may have happened.

Yes, that's what I'm trying to do with some tools. I didn't intend it the way you mean - even stated mine looks messy. Running static analyzer on the code was pretty clean actually (just a bunch of deprecations and using var instead of let where I should be). A lot more of the warnings are from an SDK I'm using from a major tech company. I can understand why because the code is much more complex than my project, but not finger pointing. I'll look at the SDK repo to see if there were any crash fixes that are reported or updated. Do you have any helpful debugging advice though?

I found out that this is correct. Adding a new developer needs to be granted the Admin role to be able to click on the "Get Started" button under App Privacy for an App.