Removed this answer, as it was not intended

After some debugging I managed to find a workaround to this problem. In short, it looks like the safe area is not updated after UIViewController.viewWillDisappearis called, and hence any changes to .additionalSafeAreaInsets is ignored (since these insets modifies the safe area of the view controller's view). My current workaround is somewhat hacky, but it gets the job done. Since UIViewControllerTransitioningDelegate.animationController(forDismissed...) is called right before UIViewController.viewWillDisappear and UIViewControllerAnimatedTransitioning.animateTransition(using transitionContext...), I start the dismiss animation already in that method. That way the layout calculations for the animation get correct, and the correct safe area is set. I've attached the code for my custom UIViewControllerTransitioningDelegate with the workaround. Note: I've removed the use of .additionalSafeAreaInsets since its not necessary at all! And I've no idea why I thought I needed it in the first place... I've also created a new post regarding the issue with safe area. Check it out here: https://developer.apple.com/forums/thread/696875 FullScreenTransitionManager.swift

I also cross posted this question on StackOverflow, and got a super nice answer back 🙌 Turns out I was missing a detail in the documentation of StateObject. The initializer to StateObject is prefixed with @autoclosure, and so the instantiation of MyViewModel is wrapped in a closure lazily evaluated by SwiftUI (inside StateObject initializer). That way MyViewModel is only created once! In short: by writing the custom initializer like below, we are good and get the expected behaviour 🥳 struct MyView: View {     @StateObject var viewModel: MyViewModel     init(viewModel: @autoclosure @escaping () -> MyViewModel) {         self._viewModel = StateObject(wrappedValue: viewModel())     }     var body: some View {         Text("Hello world!")     } }

I need to correct my original post, as I referred to a forum post (https://developer.apple.com/forums/thread/728314) where one of the answers hinted to that it is possible to convert SecureEnclave.P256.Signing.PrivateKey to a SecKey (representing the exact same key). After reading through the forum post more thoroughly, it actually seems to be the opposite. Hence I would like to reword my original question: Is it possible to convert to and from a SecureEnclave.P256.Signing.PrivateKey object and a SecKey object, both representing the same Secure Enclave protected key?