E2E Testing of Swift Applications: From XCUITest to Real-World Cases

Why E2E Tests Are the "God Mode" for iOS Developers?

Imagine: you wrote perfect Swift code, everything compiles, unit tests are green. You release the build — and within an hour bugs start flying in: the "Buy" button doesn't work on iPhone 14 Pro, and on iPad Mini the login screen looks like abstract art. Sound familiar? This is exactly where E2E testing Swift comes into play — the only way to be sure your application works like clockwork in a real user's hands.

End-to-End (E2E) tests simulate a complete user scenario: from launching the application to completing the target action (purchase, registration, form submission). In this article, we'll break down how to set up XCUITest Swift so your tests don't fail over trivial issues, and your CI/CD pipeline doesn't turn into a nightmare.

What you will learn:

\n
• How to write stable UI tests with XCUITest
\n
• Page Object Model for Swift — a real example
\n
• Handling asynchronous operations and expectations
\n
• Integrating E2E tests into CI/CD (GitHub Actions + Fastlane)
\n
• Top 3 mistakes beginners make and how to avoid them
\n

Toolkit: What We Need

For test automation Swift, we rely on three pillars:

\n
1. XCUITest — Apple's framework, built into XCTest. Allows emulating gestures and checking the state of UI elements.
\n
2. Xcode Test Plan — for configuring test schemes (different languages, orientations, data).
\n
3. Fastlane + GitHub Actions — for running tests on CI.
\n

The basic syntax of XCUITest is simple: you access the application via XCUIApplication(), find elements using buttons["Login"] or textFields["email"], and emulate actions.

Writing Your First E2E Test: Login Scenario

Let's say we have a login screen with Email and Password fields and a "Sign In" button. The goal: verify that upon entering valid credentials, the user navigates to the main screen.

import XCTest\n\nclass LoginE2ETests: XCTestCase {\n    \n    let app = XCUIApplication()\n    \n    override func setUpWithError() throws {\n        continueAfterFailure = false\n        app.launch()\n    }\n    \n    func testSuccessfulLogin() throws {\n        // 1. Find elements\n        let emailField = app.textFields["emailTextField"]\n        let passwordField = app.secureTextFields["passwordTextField"]\n        let loginButton = app.buttons["signInButton"]\n        \n        // 2. User actions\n        emailField.tap()\n        emailField.typeText("user@example.com")\n        \n        passwordField.tap()\n        passwordField.typeText("ValidPassword123")\n        \n        loginButton.tap()\n        \n        // 3. Verify the result\n        let dashboard = app.staticTexts["dashboardTitle"]\n        XCTAssertTrue(dashboard.waitForExistence(timeout: 5))\n    }\n}

Important point: use waitForExistence(timeout:) — without this, the test may fail if an animation or network request is delayed. This is the foundation of E2E testing Swift.

Why might this code fail?

\n
• The input field might not be the first responder — add .tap() before typeText.
\n
• The button might be obscured by the keyboard — use app.keyboards.buttons["Return"].tap().
\n
• Text labels may differ depending on localization — always use Accessibility Identifier.
\n

Page Object Model (POM) for Swift: Making Tests Clean

When the application grows, tests turn into a mess. The solution is Page Object Model. We create separate classes for each screen, encapsulating the logic for finding elements and performing actions.

Example for the login screen:

// Lo