We can confirm this behaviour on a physical iPhone running iOS 27.0.1 with Xcode 27.0 (27A266a), driving the app through XCUITest-based automation (Appium / WebDriverAgent). The first one or two characters of a typed string are delivered, the characters typed while the software keyboard dismisses are lost, and the tail arrives once the keyboard reappears. The typing call still reports success. Device logs match the description above on every text entry: testmanagerd: Failed to load displays from CADisplay testmanagerd: Failed to resolve displays. Defaulting to generic keyboard sender. UIKitCore: hardwareKeyboardAttached = YES In our environment the fault is in the developer disk image on the device: on iOS 27.0.1 the DDI is mounted from an on-device system asset (build 27A266a) and cannot be replaced with the Xcode 27 beta 1 image, so no host-side Xcode, Appium or WebDriverAgent version changes the outcome. A device reboot gives roughly 10 to 25 minutes of correct typing before the fault returns. Typing rate, screen lock/unlock and runner restarts have no effect. Workaround that holds for us: on the Mac that hosts the automation, open QuickTime Player, choose File > New Movie Recording, and select the iPhone as the camera source so the device screen is mirrored for sometime and close the Recording but keep the QuickTime Player instance open. With the instance open, testmanagerd resolves a display, the generic keyboard sender is not used, and text entry is complete for the whole run. Opening the mirror mid-run also recovers a device that has already started dropping characters. This is a stopgap, not a fix; the behaviour needs a corrected DDI asset.