You can overwrite the top view controller's prefersHomeIndicatorAutoHidden method and return YES. That auto-hides the home indicator for devices that have one, but also apparently auto-hides the multitasking menu on iPads with iPadOS 15, even if they don't have a home indicator.

I see the same behavior and no way to hide the pointer. The prefersPointerLocked method is not called on iPhone. The GCMouse events work on iPhone fine, so it would make sense if the prefersPointerLocked method was also taken in consideration to hide the pointer.

Issue started with Beta 3 and persists with Beta 4

Assuming you're using something like this to end your live activities when the app is being terminated: class func stopLiveActivities() { print("Ending Live Activities") Task { for activity in Activity<TimeoutActivityAttributes>.activities { print("Ending Live Activity: \(activity.id)") await activity.end(nil, dismissalPolicy: .immediate) } } } This will not end the activities, the method returns and allows the app to terminate before the activities get a chance to actually end. Add a semaphore to force it to wait for the activities to end before returning from the method: class func stopSessionTimeoutAsync() { print("Ending Live Activities") let semaphore = DispatchSemaphore(value: 0) Task { for activity in Activity<TimeoutActivityAttributes>.activities { print("Ending Live Activity: \(activity.id)") await activity.end(nil, dismissalPolicy: .immediate) } semaphore.signal() } semaphore.wait() } This works for me (tested with a single activity). With the app in the background and live activity showing, I can force-kill the app and the live activity is removed.

Issue persists with Xcode 15 RC build installing on device with iOS 17 RC.

Have you tried the X button below the app?

We also tried using: "EXCLUDED_ARCHS[sdk=iphonesimulator*][arch=arm64]" = "" but it still doesn't get used. The default setting gets used instead. This is making use what is already available to use for user-defined settings. For those, the Xcode UI lets you choose both an SDK and an architecture. But interestingly enough, after testing with a user-defined setting, we found that even then the build doesn't use the correct setting. To test this we added: TEST_SETTING = TEST; "TEST_SETTING[sdk=xrsimulator*]" = "visionOS Sim - Native visionOS app"; "TEST_SETTING[sdk=iphonesimulator*][arch=arm64]" = "visionOS Sim - Designed for iPad"; "TEST_SETTING[sdk=iphonesimulator*][arch=x86_64]" = "iOS Sim - Native iPad"; These can be added manually or via the UI and they do show as separate entries: We also added TestSetting = $(TEST_SETTING) in Info.plist. And log the value: NSLog(@"TEST_SETTING: %@", [[NSBundle mainBundle] objectForInfoDictionaryKey:@"TestSetting"]); Results: Running Apple Vision Pro (simulator): visionOS Sim - Native visionOS app ✅ Running Apple Vision Pro (Designed for iPad): TEST ❌ Running iPad simulator: TEST ❌ So it's clear that there's a bug here. For the destinations that are architecture specific, the default setting is used instead. Created FB13351268

Same for me, but I tried again and it worked now

It is awesome to see. 10240x2880 in a 180° around you. It would be great if our apps could use this also! I haven't seen an API for it yet, it would be great if one exists. In the meantime, I opened FB13945590 (since June actually) suggesting one.

We started getting this warning also when uploading to TestFlight with Xcode 16.3. The app does not use any 3rd party libraries and does not use Push Notifications (and does not implement the above API). Hint to Apple: When we last uploaded with Xcode 16.2, this warning did not occur. This warning started after upgrading to Xcode 16.3.