XCUITest text entry drops characters on physical iOS 27 devices since Xcode 27 GA (FB24932647)

Developer Tools & Services Xcode
abc_123_456 OP
Created
Replies 1
Boosts 3
Views 245
Participants 2

Since Xcode 27 GA, text entry from a UI test on a physical iOS 27 device delivers only the first 3–4 characters and then stops, while the call still returns success. Taps and scrolls are fine. The same tests pass on Xcode 27 beta 1. Filed as FB24932647.

Broken: Xcode 27.0 (27A266a), 27.1 beta (27A9269), 27.2 beta 2 (27B5028f) Works: Xcode 27 beta 1 (27A5194q) Device: iPhone, iOS 27.0 (24A437)

Repro. We drive it through WebDriverAgent. The failing step is XCTest's own event synthesis in testmanagerd, which is the same path XCUIElement.typeText goes through.

  1. Xcode 27.2 beta 2, run sudo xcodebuild -runFirstLaunch, reboot the device.
  2. Type subjectline into a plain UITextField.
  3. Read the field's value back.

Expected subjectline. Actual sub or subj, in every one of 16 attempts. In a recipient-style field the fragment appears and is then erased, so nothing survives. 0 of 32 attempts completed.

Device log, all within one second:

testmanagerd   Failed to load displays from CADisplay
testmanagerd   Failed to resolve displays. Defaulting to generic keyboard sender.
testmanagerd   Recap event action playback initiated
UIKitCore      hardwareKeyboardAttached = YES
UIKitCore      Moving from placement OnScreen to OffScreenDown
UIKitCore      Change to input view set: (empty)
testmanagerd   Recap event action playback completed

testmanagerd can't resolve a display, so it falls back to a generic keyboard sender that registers a virtual HID keyboard. iOS then treats that as a hardware keyboard and dismisses the software keyboard while the text is still being typed.

What changed. Comparing testmanagerd in the two DeveloperDiskImages: beta 1 derived the display from the app's identity (Computed display ID … from embeddedApplicationIdentifier … bundleID). GA removed that and added CADisplay enumeration with the generic fallback. That code is unchanged through 27.2 beta 2.

This is not 181945323, which is marked fixed in 27.2 beta 2. That one needs Device Hub and clears on its own.

  • Is anyone else seeing this on device?
  • Is there a supported way to type on device under Xcode 27 GA, other than staying on beta 1?
Replies  1
Boosts 3
Views  245
Participants  2
espressif OP

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.