XCUITest Page Object Model: Tame Your UI Tests
The Page Object Model treats each app screen as an object, separating test logic from UI interaction. In XCUITest, this creates stable tests for complex apps. The biggest footgun is forgetting synchronization—always wait for views to load before interacting.
Why it exists
UI tests often become brittle and hard to maintain. A small change to a button's ID can break dozens of tests that all contain the same fragile UI lookup logic. The Page Object Model was created to decouple test logic from the specific implementation of the UI, making tests more resilient to change.
The mental model
Think of each screen or major view in your iOS app as a 'page.' The Page Object is a Swift class that models this page, providing a clean API for your tests to use. Instead of your test code directly searching for XCUIElements, it calls high-level methods on the Page Object like login(username:, password:) or navigateToSettings(). The Page Object handles the messy details of finding and interacting with the UI elements under the hood.
How it works
Each main view gets its own class (the Page Object). This class contains properties for the UI elements on that screen and functions for actions a user can perform. A key pattern is that functions triggering navigation return an instance of the next page's object. For example, tapLoginButton() would wait for the home screen to appear and return a HomePageObject. This creates a fluent, chainable API for your tests. Reusable UI, like a custom alert, can be modeled as PageComponent classes, and repeated items, like table cells, as PageComponentCollections.
When to use it
Use POM for any non-trivial XCUITest suite. It is the industry standard for building scalable and maintainable UI automation. It is especially valuable in team environments where UI changes are frequent, as updates only need to be made in one place (the Page Object) instead of every test that touches that UI.
When not to use it
For very simple apps with only one or two screens, or for quick, throwaway test scripts, the initial overhead of setting up the POM structure might not be worth it. However, most production projects quickly outgrow this level of simplicity.
One canonical example
Robust synchronization is the lynchpin of a stable POM. Your test must not try to interact with an element before it's ready. A common implementation uses a protocol like SynchronizedView. Each Page Object implements a checkViewCriteria() function that instantly returns nil if the view is fully loaded, or an error string if not. A waitForView() method then polls checkViewCriteria() repeatedly for a set timeout (e.g., 20 seconds). If the criteria are not met in time, the test fails immediately with a clear message explaining why the view failed to load, preventing flaky tests and race conditions.
Interview question
Which aspect is most crucial for maintaining stability and preventing flakiness in an XCUITest Page Object Model implementation?
- a.Implementing comprehensive synchronization to ensure UI elements are ready before interaction.Correct
- b.Ensuring a strict one-to-one correspondence between every UI screen and its dedicated Page Object.
- c.Encapsulating all UI element lookups within Page Objects, never exposing them directly to tests.
- d.Designing Page Objects to return instances of subsequent Page Objects for fluent chaining.
Why? this is the answer
The card explicitly states that "Robust synchronization is the lynchpin of a stable POM" and that forgetting it is the "biggest footgun." While other options describe good practices for POM, robust synchronization directly addresses the primary cause of flaky UI tests.
Just read this? Test yourself on what you have been reading.
Read the original → engineering.rei.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles