@JagCesar2 Hey, have you heard anything from your bug report? I just dug back into this issue and was able to reproduce it with Apple's own DestinationVideo project: https://developer.apple.com/documentation/visionos/destination-video Only thing you need to modify is uncheck 'Requires full screen' in Deployment info. After that select any item in the sidebar and minimise the app. If it doesn't crash after the 1st attempt, retry it a couple of times. For me it always bails with: SwiftUI/SidebarAdaptableTabViewStyle_iOS.swift:482: Fatal error: Tried to update with invalid selection value I also created a radar under FB15759496

I'm experiencing the same issue. It occurs, when minimising the app. My guess is that this happens while generating the snapshot for the app switcher. Even adding an empty section will crash my app: TabSection("Feeds") { Tab("Home", systemImage: "house", value: Navigation.Sidebar.default) { EmptyView() } } Removing the wrapping "TabSection" fixes the issue.

@jep struggeling with the same issue. Have you found a solution?

Trying to revive this old topic. I'm able to reproduce my issue with the code example of @achernoff . @DTS Engineer does that help you reproduce the problem as well?

Same problem here. Has anyone figured this out?

Having the same issue. Has anyone found a solution in the meantime?

@edford: thx for the prompt response! Maybe I'm misunderstanding things, but I am indeed currently running Xcode using Rosetta. And the problem vanishes. As far as I thought I had understood it this is due to the Simulator also running in Rosetta - hence using the x86_64 arm64 lib and not giving me any problems when linking. Is there another explanation for this 'fix'?

@edford I have the same problem. However, the library I'm including is a legacy module that won't be updated by the 3rd party vendor. Lipo says: Architectures in the fat file: LegacyLib are: i386 armv7 x86_64 arm64 As far as I can tell my only option seems to be to run Xcode in Rosetta mode or do you see any other option?

Hey guys,I have the exact same question. In my case I'd like the UI to adopt if e.g. a user with limited physical and/or motor skills navigating the iOS app with a hardware keyboard (through the accessiblity feature) uses my app. Right now I have a list overlaying a map (similar to iOS' Maps app) and navigating that list with a keyboards doesn't work well.I'd like to be able to detect if a user navigates my app with a hardware keyboard and make that overlaying list fullscreen in that case.Any ideas on how to accomplish the hardware keyboard detection?Cheers,Sebastian

Ok, after some more digging it seems like what I speculated above is actually true.When you don't have an app that has any other background modes active (like location or audio) your app will be suspended (most of the times) when the users minimize/close it. When you then send a silent push notification to the app it is not running in the background and thus the callback "didReceiveRemoteNotification" will not get called.Instead, your app will be started in the background and the silent push notification's parameters will get passed into the initial funcapplication(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions:...as "launchOptions". So on app start you should check the launchOptions dictionary for your silent push notification's data and process it accordingly.

Quick addon: When running the app on the phone, attached to the XCode debugger, then minimizing the app, locking the phone and then sending it a silent push notification I also don't succeed in gettingfunc application(_: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void)to get called.In the Console at some point it says:COMPLETED com.apple.pushLaunch.de.myapp.app:0ADB2E at priority 5 ! NO LONGER RUNNING com.apple.pushLaunch.de.myapp.app:0ADB2E ...Tasks running in group [com.apple.dasd.defaultNetwork] are 0!The only suspicious logs I can see before that are:-CMSessionMgr- CMSessionMgrHandleApplicationStateChange: CMSession: Sending stop command to de.myapp.app with pid '494' because client is not allowed to play in the background AND does not continue AirPlaying video when device locks [sceneID:de.myapp.app-default] Scene action [SceneLifecycleEventOnly][0xe7ca] completed with success: 1 [sceneID:de.myapp.app-default] Scene activity state did change: BackgroundInactive. Invalidating assertion 27-57-731 (target:application) from originator 57