DEV Community

Cover image for XCUITest Device Testing: Testing iPhone and iPad Screen Sizes with Confidence
QAPulse by SK
QAPulse by SK

Posted on Originally published at skakarh.com

XCUITest Device Testing: Testing iPhone and iPad Screen Sizes with Confidence

#iosuitesting #ipadtesting #iphonetesting #mobileautomation

XCUITest device testing is essential for validating iOS applications across different iPhone and iPad screen sizes, orientations, resolutions, and UI layouts. A UI that works perfectly on one simulator can expose clipping, overlapping, scrolling, or accessibility problems on another device. For SDETs, device coverage should therefore be treated as a deliberate automation strategy rather than simply running the same tests on more simulators.

Definition

XCUITest device testing is the process of executing XCUITest UI automation across different iPhone and iPad configurations to validate application behavior, layout, navigation, interactions, accessibility, and responsive UI behavior.

The objective is not to create a separate test for every device.

The objective is to verify that the same functional test remains reliable across supported device configurations.

Key Points

  • Test representative iPhone and iPad configurations.
  • Validate portrait and landscape orientations.
  • Avoid coordinate-based automation.
  • Prefer accessibility identifiers and semantic queries.
  • Verify scrolling on different screen dimensions.
  • Test dynamic content and long text.
  • Validate split-screen and multitasking where supported.
  • Keep device-specific behavior separate from functional logic.
  • Use test plans to organize device coverage.
  • Run broader device coverage in CI or scheduled regression jobs.

Why Device Size Matters in iOS Automation

Different Apple devices provide different:

  • Screen dimensions
  • Aspect ratios
  • Safe areas
  • Orientation behavior
  • Layout characteristics
  • Available content space
  • Keyboard presentation behavior
  • Navigation behavior

Consider a login screen:

iPhone
┌───────────────────┐
│       Logo        │
│                   │
│ Email             │
│ Password          │
│                   │
│     Login         │
└───────────────────┘
Enter fullscreen mode Exit fullscreen mode

On a larger iPad layout:

┌──────────────────────────────────────┐
│                                      │
│             Login Form               │
│                                      │
│      Email                           │
│      Password                        │
│                                      │
│             Login                    │
│                                      │
└──────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The functional workflow is identical, but the UI hierarchy and available space may differ.

A strong XCUITest device testing strategy validates the behavior without unnecessarily coupling tests to a particular screen coordinate or device.

iPhone vs iPad Testing

The test strategy should cover both functional behavior and device-specific presentation behavior.

6 Core Pillars of XCUITest Device Testing

1. Device Coverage

Select representative supported iPhone and iPad configurations.

2. Orientation Coverage

Validate important workflows in portrait and landscape.

3. Responsive UI Validation

Verify that controls remain visible, accessible, and interactable.

4. Device-Independent Locators

Use accessibility identifiers and semantic queries instead of coordinates.

5. Layout-Aware Assertions

Validate meaningful UI state rather than pixel positions.

6. CI Device Strategy

Separate fast PR validation from broader device regression coverage.

Device Coverage Strategy

Testing every available Apple device is rarely practical.

A representative matrix is more useful:

The exact matrix should match the application’s supported-device policy.

Device Selection Should Be Risk-Based

Not every feature requires every device.

For example:

Login
 ↓
iPhone + iPad

Checkout
 ↓
iPhone + iPad + Landscape

Dashboard
 ↓
iPhone + iPad + Landscape + Split View
Enter fullscreen mode Exit fullscreen mode

This reduces unnecessary execution time while preserving meaningful coverage.

Avoid Coordinate-Based Testing

This is fragile:

app.coordinate(
    withNormalizedOffset: CGVector(
        dx: 0.5,
        dy: 0.8
    )
).tap()
Enter fullscreen mode Exit fullscreen mode

The coordinate represents a physical location rather than the UI element’s meaning.

A different screen size can change that location.

Prefer:

app.buttons["loginButton"].tap()
Enter fullscreen mode Exit fullscreen mode

The automation identifies the control semantically rather than geometrically.

This is one of the most important principles in XCUITest device testing.

Accessibility Identifiers

Application developers should expose stable identifiers:

loginButton.accessibilityIdentifier = "loginButton"
emailField.accessibilityIdentifier = "emailField"
passwordField.accessibilityIdentifier = "passwordField"
Enter fullscreen mode Exit fullscreen mode

The test can then use:

let loginButton = app.buttons["loginButton"]

XCTAssertTrue(
    loginButton.waitForExistence(timeout: 10)
)

loginButton.tap()
Enter fullscreen mode Exit fullscreen mode

The same test can operate across multiple device sizes because the locator does not depend on screen coordinates.

Device-Independent Queries

Useful queries include:

app.buttons["loginButton"]
app.textFields["emailField"]
app.secureTextFields["passwordField"]
app.staticTexts["Welcome"]
Enter fullscreen mode Exit fullscreen mode

You can also use predicates for more complex UI:

👉 Continue reading the full article on skakarh.com →

Originally published at skakarh.com/xcuitest-device-testing.
Subscribe to QA Pulse by SK —
weekly signal for QA, Test Automation and AI in Software Engineering.

Top comments (0)