I see the exact same behavior. And the defaultValue is even computed when the Environment is overridden with a new value. This simple app: import SwiftUI struct SomeValue { init() { print("SomeValue.init()") } } extension EnvironmentValues { @Entry var someValue: SomeValue = SomeValue() } struct ContentView: View { @Environment(\.someValue) private var someValue var body: some View { VStack { Text("Hello, world!") } .padding() } } @main struct MyAppApp: App { var body: some Scene { WindowGroup { ContentView() .environment(\.someValue, SomeValue()) } } } Will print the following: SomeValue.init() SomeValue.init() SomeValue.init() SomeValue.init() And if you put a break point inside the initializer of SomeValue, you will notice that the first time SomeValue is initialized is when it is passed to the .environment() modifier. The succeeding three times is from when the defaultValue is computed. Even without the use of the Entry macro, the defaultValue is always called/computed even if the value has been explicitly set with the .environment() modifier before it is ever being used. Though this might be completely by design, it is a bit unexpected (to me at least).

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?

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!")     } }

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

Removed this answer, as it was not intended