I just got this same kind of message, as of the 24th of August, 2021, being printed out in the Xcode Debugging Console after having built and run my app for the iPhone X (iOS 15.0) in the Simulator. The version of Xcode I'm using is: Version 13.0 beta 5 (13A5212g). I didn't notice any freezing of the Simulator and/or of my app running in it, but perhaps that was because this wasn't the first time I'd built and run my app in the Simulator since having most recently launched the Simulator.

I'm just reposting the content of my StackOverflow answer here: https://stackoverflow.com/questions/56613157/enable-keyboard-in-xcode-preview/69431429#69431429 . Workaround for Live Preview running in Xcode Previews app on physical iPhone device Send the Xcode Previews app into the background (such as by swiping up from the bottom of the screen to view the App Switcher). Bring the Xcode Previews app back into the foreground. Tested On: MacBook Pro (Retina, 13-inch, Late 2013) running macOS Big Sur Version 11.6 Xcode Version 13.0 iPhone X running iOS 15.0.1

I just discovered an additional bug that's related to this bug, which prevents the value of the SwiftUI View's @FocusState property (if it has one) from correctly updating in response to its TextField being tapped - even when the above workaround is successfully used to make the on-screen keyboard show when that TextField is tapped - providing that that SwiftUI View is the top-level View in the Preview. Please see below for a demonstration of this bug, and an example of how to workaround it: struct MyForm: View {   @FocusState private var isFocused: Bool   @State private var text = ""   var body: some View {     VStack {       Text("isFocused: \(isFocused ? "true" : "false")")       Form {         TextField("Enter text here", text: $text)           .focused($isFocused)       }     }   } } struct Bad_MyForm_Previews: PreviewProvider {   static var previews: some View {     /*      * Due to another bug, paired with the fact that MyForm is the top-level      * SwiftUI View in this Preview, the value of MyForm's `@FocusState`      * property won't update in response to its TextField being tapped.      * This is the case, regardless of if this Preview is being run as:      *   1. A "Live Preview" in the Canvas in Xcode,      *   2. Or as a "Preview on Device" via the "Xcode Previews" app on a      *    physical iPhone - even if the keyboard shows.      */     MyForm()   } } struct Good_MyForm_Previews: PreviewProvider {   static var previews: some View {     /*      * But the bug mentioned above that prevents the value of `MyForm`'s      * `@FocusState` property from correctly updating in response to its      * TextField being tapped, *won't* affect *this* Preview, as in *this*      * Preview, `MyForm` is *not* the top-level SwiftUI View.      */     ZStack {       MyForm()     }   } }

Preamble The solutions previously posted don't allow for the picker to initially have no value selected, but sometimes you may want this. Going with the code-example in the Original Poster's question above, let's say the Original Poster wished to initially have no player selected in the Picker, in which case "default" would be shown in the first Text View until the first time the user selects a Player via the Picker View. Problem The tag type doesn't match that of selection. Solution Cast the player to Player? in the .tag(...) View Method call, so that the tag's type will match that of selection/$selection.wrappedValue. Here's the Original Poster's code-example with this solution applied: struct TestView: View {   @Environment(\.managedObjectContext) var viewContext   @FetchRequest(     sortDescriptors: [NSSortDescriptor(keyPath: \Player.familyName, ascending: true)],     animation: .default)   private var players: FetchedResults<Player>       @State var selection: Player?       var body: some View {     VStack{       Picker("", selection: $selection){         ForEach(players, id: \.self){ (player: Player) in           Text(player.givenName!).tag(player as Player?) // Cast `player` to `Player?`, so that the tag's type will match that of `selection`.         }       }       Text(((selection?.familyName ?? "default")))       Text("\(players.count)")     }   } }

Yes, I believe there is a much better solution, based on my personal experience. I found that following the steps listed in the solution titled "Solution 2" along with the steps listed in the solution titled "Solution 3" of this post on StackOverflow: https://stackoverflow.com/a/47448911/13910236, in conjunction with the single step given in the first comment to that post on StackOverflow which I'll link to here: https://stackoverflow.com/questions/46316373/fixing-xcode-9-issue-iphone-is-busy-preparing-debugger-support-for-iphone#comment83623898_47448911 , fixed the problem for me. But I find I have to follow the same set of steps to solve the problem again after it re-occurs - however, I believe it only ever re-occurs after I quit Xcode and turn my computer off and on again (and possibly unplug my iPhone from my Mac computer) and then open Xcode and attempt to Build & Run my application on my iPhone. Please let me know how you go with those steps.

There is apparently a workaround for getting the on-screen keyboard to open in the Live Preview in the Canvas in Xcode (I remember reading about it somewhere on StackOverflow a long time ago). That workaround involved doing something like running your app in the Simulator app, clicking on a Text-Input-View and toggling on the on-screen keyboard if it isn't already toggled on, via the I/O -> Keyboard -> Toggle Software Keyboard Menu Item found inside the Menu Bar for the Simulator app, or alternatively, by hitting Command+K. But I don't know that this workaround ever worked for me - however, it may have indeed worked for me, but where I just didn't notice that it had, as even if you manage to get the on-screen keyboard to open for you in the Live Preview in the Canvas in Xcode, you'll probably find like I have, that it will be invisible whilst it's open! By the way, fortunately, any keyboard toolbar you add to your app, will be visible in the preview - at least providing that you succeed in getting the on-screen keyboard to open for you in the preview. Providing that you can get the on-screen keyboard to open for you in the preview, then to make it easier to type text into Text-Input-View's, you could do something like the following: Run your application in the Simulator app for a matching device to the one you'd be using when previewing your SwiftUI View, and get the on-screen keyboard to visibly open up in the Simulator. Then take a screenshot of it, and crop that screenshot-image down to just the on-screen keyboard portion of it. Create and use a ViewModifier that will display that cropped-screenshot-image of the on-screen keyboard for that device, at the bottom of the preview, whenever the on-screen keyboard is open. 3.1. By the way, you could hook into keyboard notifications that are automatically posted to the NotificationCenter whenever the on-screen keyboard opens and closes, to automatically set a boolean flag to false or true to represent this, and then use that flag to control when the ViewModifier you write does and does not display the image. 3.1.1. Alternatively, you could take the following approach that would make the implementation of the ViewModifier you write simpler, but make it more complex and verbose to **use**: 3.1.2. You could provide to the ViewModifier at the call-site, an `FocusState.Binding` instance or a `Bool` instance which you could set based on whether or not the `FocusState.Binding` instance's `wrappedValue` is currently equal to `nil`, to teach the ViewModifier when it should and should not display the screenshot-image of the on-screen keyboard. 3.2. A more complex solution that might work, would be programmatically finding the UIWindowScene that contains the actual on-screen keyboard (when it's known that the on-screen keyboard has been opened-up) and use the relevant UIKit-provided API's to create a snapshot view of its UIView Hierarchy, which you could then get your ViewModifier to render at the bottom of the preview using a struct you create that conforms to the UIViewRepresentable protocol, as I'm guessing this would make those UIViews actually become visible. 3.2.1. Also, if you head down this route, you might manage to figure out a workaround for the bug itself that causes the on-screen keyboard to be invisible whilst open in the Live Preview in the Canvas in Xcode, in such a way that you could make the actual on-screen keyboard become visible in such previews. However I _did_ head down this route a little while ago, and found no success myself at making the on-screen keyboard's keys become visible. Although, I did manage to make the region of the on-screen keyboard display a solid color, by setting the `backgroundColor` of the `UIView`'s to a `UIColor`. Also, for me at least, I've found that I'm unable to use my Mac's physical keyboard to type into Text-Input-Views in the Live Preview in the Canvas in Xcode, even when the on-screen keyboard is open, despite the fact that in the Simulator app, I have the "Connect Hardware Keyboard" Menu Item checked, which is a Menu Item found under the I/O -> Keyboard Sub-Menu in the Menu Bar for the Simulator app. Obviously, all of this would be a lot of work to do, so if you can bare just typing in gibberish when typing into Text-Input-Views in the preview, and you manage to get the on-screen keyboard to open but it remains invisible for you, I recommend you just randomly click in the region in which it would normally be visible, to type random characters into the Text-Input-View.