In some cases I would expect that would resolve the issue, especially in simple cases like demo apps. However that assumes that the structs are not recreated. However that won't work in more complex cases. For example if you get that data from your server reloading would generate a new object with a new UUID. That is why they recommend long life ids, like database ids, which would persist through operations like reloading from your server.

I have filed feedback with a sample project here: FB9155790.

I also wasn't able to get it to work using init, however I'm not really surprised by that given how other property wrappers like @State work. I was eventually able to get it working using onAppear, however after a bunch of testing I found that I'm able to get it work with simple Views but as the view gets more complex the behavior gets confusing/inconsistent. For example I have included the code for a View below that: Will set the focus state that will focus a field when the view appears. Will not set the focus state if you you uncomment the NavigationView. Will set the focus state if it is the destination of a NavigationLink inside a NavigationView. Will not set the focus state if you follow a NavigationLink inside the view then go back. I'm not sure what the intended behavior is, however I'm guessing that this isn't it. Here is my sample View: struct ComposeView: View {   enum FocusField: Hashable {     case field   }   @FocusState private var focusedField: FocusField?   @State var text: String = ""   var body: some View { //NavigationView { VStack {     TextField("textField", text: $text)       .focused($focusedField, equals: .field)       .onAppear {         self.focusedField = .field }     } //}   }

When I implement UITextInput I do get the exact behavior you predicted where insertText is not called but setMarkedText and unmarkText are called. However that makes it so that after text is recognized and passed to setMarkedText I cannot distinguish between the user pressing insert and the user pressing the "x" to dismiss the camera. Both result in 2 calls to unmarkText. In one case I'm supposed to save the text, in the other I'm supposed to get rid of it. Our use case is for the user to scan 1 word from an object that has a lot of words around the word we want to scan. We need to the user to be able to cancel without dumping a long string of junk into the textfield, which currently seems to be the only option. Is there any way to tell if the user selected Insert or cancelled out of the view?

I just gave it a try and here is what I found: If I get preview "marked text", then cancel I get these calls in this order: setMarkedText: with "". setMarkedText: with "some string". setMarkedText: with "". unmarkText. If I hit insert I get these calls in this order: setMarkedText: with "". setMarkedText: with "some string". unmarkText. setMarkedText: with "". So if I understand correctly that means that if I receive unmarkText while there is marked text it should be inserted. I gave that a try in my code and it works! Thanks! Upon re-reading the documentation That now makes sense. I think that if I was actually fully implementing UITextInput I would have figured it out. However since I was only using the methods mentioned in the talk for camera I didn't have the extra context, even after reading the UIKeyInput and UITextInput documentation. I will update my Feedback with this information, and I think it basically turns into some combination of: When using the captureTextFromCamera the behavior of UIKeyInput and UITextInput don't make sense, since changing the declared protocol conformance changes the behavior. The session implies that you can just implement UITextInput to get the marked text (e.g. preview text) behavior without changing the logic from your UIKeyInput conformance for dealing with the "inserted" text.