Xcode UI recording turns a short manual simulator pass into starter XCUIAutomation source. It fits a bounded login, onboarding, purchase, or settings path where the first draft can come from a known-good manual pass.
The recorder writes taps, typing, swipes, and other UI interactions into the XCTest UI test method that has the insertion point. Keep the first recording narrow, because the generated code is meant to be reviewed rather than kept as an untouched capture of every exploratory tap.
A recorded UI test should not be kept until the generated queries are reviewed and at least one XCTest assertion proves the screen state that matters. Stable accessibility identifiers usually make recorded actions less fragile than visible labels that can change with copy, localization, or dynamic content.
Related: How to run XCUITest tests locally
import XCTest final class LoginUITests: XCTestCase { func testLoginFlow() throws { let app = XCUIApplication() app.launch() } }
The recording target must be a UI test method in a UI testing bundle, not a unit test method.
Related: How to add an XCUITest UI testing target
func testLoginFlow() throws { let app = XCUIApplication() app.launch() app.buttons["loginButton"].tap() app.textFields["emailField"].tap() app.textFields["emailField"].typeText("user@example.com") app.secureTextFields["passwordField"].tap() app.secureTextFields["passwordField"].typeText("example-password") app.buttons["submitButton"].tap() }
Use app-specific identifiers such as loginButton and emailField only when those identifiers exist in the app code.
Related: How to query UI elements in XCUITest
XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))