XCUIElementQuery: The Blueprint for Finding UI Elements
An XCUIElementQuery is a recipe for finding UI, not the element itself. It describes a search that runs only when you interact with the result. Use it in XCUITest to locate views for automated tests. The footgun: thinking a query finds an element on creation.
Why it exists
UI testing requires a reliable way to find and interact with on-screen elements. Hardcoding view references is brittle and fails with dynamic UIs. XCUIElementQuery provides a flexible, descriptive way to locate elements at runtime, even as the UI changes.
The mental model
An XCUIElementQuery is like a database query, not the result set. It's a plan for how to find something. app.buttons["Submit"] doesn't give you the button; it gives you an object that knows how to find a button with the accessibility identifier "Submit" when you need it. The actual search happens later.
How it works
You start from the root XCUIApplication object and chain queries to narrow your search. For example, app.tables.cells.containing(.staticText, identifier:"Profile").buttons["Edit"] builds a complex search path. The query is only resolved—meaning the UI tree is actually traversed—when you perform an action (.tap(), .swipeUp()) or check a property (.exists, .isHittable). If no element is found at that moment, the test fails.
When to use it
Use XCUIElementQuery for all UI element location in your XCUITest suites. It is the fundamental tool for writing UI tests. You'll use it to find elements to tap, type text into, swipe, or assert their existence.
When not to use it
Do not use XCUIElementQuery in your main application code. It is strictly part of the XCUITest framework and is not available for production logic. For finding views within your app, you'd use mechanisms like viewWithTag(_:) or direct property outlets.
One canonical example
A common task is tapping a login button. First, you create the query: let loginButton = app.buttons["Login"]. This line does not find the button and does not fail if it's not on screen. The test only interacts with the UI when you call the action: loginButton.tap(). The test will wait for the element to appear for a short timeout period at the moment .tap() is called. If it's not found then, the test fails.
Interview question
When does an XCUIElementQuery typically execute its search to find a UI element?
- a.As soon as the query object is initialized.
- b.When the application under test first launches and loads its initial UI.
- c.During the setup phase of the XCUITest case, before any test steps run.
- d.When an interaction method (e.g., .tap()) or a property (e.g., .exists) is called on it.Correct
Why? this is the answer
An XCUIElementQuery is a blueprint, not the element itself. The actual search for the UI element only occurs when an action (like .tap()) is performed or a property (like .exists) is accessed on the query. Option A is a common misconception, as the query's creation merely defines the search criteria, not executes it.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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