Driving app state via launch arguments in XCUITest

What's really being asked

The interviewer wants to see that you separate the scenario under test from the setup required to reach it, and that you know the launch-time channels XCUITest provides for injecting state.

The full answer

XCUIApplication exposes launchArguments, an array, and launchEnvironment, a dictionary, both set before calling launch(). The app inspects ProcessInfo at startup and branches accordingly: an argument like -isLoggedIn YES seeds a fake authenticated session, an environment value selects which feature flags are on, and another can point networking at a stub server or load fixture data. This means a test for the logged-in dashboard never touches the login screen. Centralize the wiring in a base XCTestCase or a builder so tests declare intent, for example launchLoggedIn(features: [.newCheckout]).

The mistakes people make

Automating the real login flow through taps in every test, which is slow, depends on the auth UI, and breaks dozens of unrelated tests when login changes. Hard-coding a backend so flags cannot vary. Leaving setup state to persist between tests, causing order dependence.

What usually comes next

How do you keep test-only branches out of the production binary or ensure they are inert in release? How do you reset state between tests? How would you stub the network alongside this state injection?

A concrete example

In the test: let app = XCUIApplication(); app.launchArguments += ["-uitest-loggedIn"]; app.launchEnvironment["FEATURE_NEW_CHECKOUT"] = "1"; app.launch(). In the app's startup code, guarded so it only activates under test, it checks ProcessInfo.processInfo.arguments.contains("-uitest-loggedIn") to install a stub session and reads the environment dictionary to flip the checkout flag. The dashboard test launches straight into an authenticated, feature-enabled state in milliseconds, with no login taps and no coupling to the sign-in screen.