Using .cancellationAction instead of .topBarLeading works for watchOS 10.5. On watchOS 11.1 both crash.

The issue seems still be present using watchOS 11.1 on an Ultra. Any news on this?

I'm experiencing a similar issue on macOS Sonoma using Parallels with Ubuntu 22.04. All dependencies of the X64 binary are available but the execution fails with the following error: 2976 Illegal instruction (core dumped) which creates a core file: /var/lib/apport/coredump/core._media_psf_RosettaLinux_rosetta.1000. suggesting that Rosetta is indeed used. Any suggestion how to progress from here? Thanks!

Thanks for the detailed explanation, I read about it some years ago. The software in question is a graphical in-house development tool, the final products are signed and notarized of course. I still think the error explanation in the crash log is in contrast to the documentation and your explanation ("app's Info.plist must contain an com.apple.security.device.camera key"). I filed a radar for it: FB9910936. What I also don't understand why it runs when I start the App from Terminal and only crashes when launched from Finder ...

Dear Makav, thanks for your response. Is it mandatory now to have the macOS App signed to allow camera-access? The app isn't singed at all, and the camera access code is provided by an unsigned plugin. I cannot easily sign the whole thing, it basically loads most of the functionality from plugins that are written by external developers.

For medical applications I also would like to be able to directly work in Core ML with data loaded in 3D Metal textures. The data is possible quite large (CT, MRI) hence an efficient path to Core ML would be most beneficial. Thanks I filed FB9814339 for this.

I would be very interested if anything besides the Bonjour C-API (e.g. DNSServiceRegister) is still supported on macOS & iOS.

Found a solution for my specific issue on iOS 14: There seems to be an issue with URL types in the userInfo dictionary. Not sure if the value itself is evaluated but replacing the URL by a string solved the issue for me. My dictionary only had two entries, a String and a URL. Both values were cleared. Now the two Strings are passed to the new scene.

I'm running into the same issue. I tried setting the requiredUserInfoKeys and using an NSUserActivityDelegate with needsSave with no effect. Did you or someone else find a solution to this issue?

I'm running into the same issue. I tried setting the requiredUserInfoKeys and using an NSUserActivityDelegate with needsSave with no effect. Did you or someone else find a solution to this issue?

I was able to resolve all navigation issues and state side effects in my app (iOS & iPadOS) using an adaptation of the method referenced by "basememara" and originating from "Swift with Majid". I'm mostly using grid and list based item views with navigation links. SwiftUI is broken in so many areas currently, that the slowdown you get by finding many plan B's will eat all its proposed swiftness. I filed bug reports for all of them, please do the same.

I just got feedback to my bug report from Apple, saying the issue should be fixed with the latest macOS 10.15.4 beta 4. I don't have access to my Macs right now, maybe some of you want to give it a spin...

I can confirm this issue with the very same symptoms on 10.15.3. Did you file a bug report (and ever got an answer)? The preview works fine on Catalina, just it's hard to test automatically.

After replacing every occurence of the double4x4 inverse function with my own function, the App works correctly. My bet is on the double4x4 inverse function to be incorrect.The most simple replacement that works for me is just an encapsulation of the inverse function call by another function:extension double4x4 { public var inverseReplacement: double4x4 { return self.inverse } }However, I would not ship an app with this bug.

Yes, the code I posted initally is also attached to the bug report. This issue only ever occured to me on Catalina, all iOS platforms and Mojave are unaffected.