Simulator orchestration has five distinct checkpoints: discover, boot, install, launch and capture. A process identifier after launch does not prove the screen you requested is visible.
- 1Find available device
- 2Boot runtime
- 3Install and launch
- 4Capture intended state
Work through the example
Use the recorded Reading List baseline to distinguish installation from visual readiness. Capture again if the first image still shows the home screen.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
Evidence Contract
Every runtime tool should return structured data suitable for workflow branching:
{
"status": "passed",
"device": {
"name": "iPhone 17 Pro",
"udid": "SIMULATOR-UDID",
"runtime": "iOS 27.0"
},
"app": {
"bundle_id": "com.example.App",
"configuration": "Debug"
},
"artifacts": {
"screenshot": "artifacts/screens/home.png",
"video": "artifacts/videos/flow.mov",
"logs": "artifacts/logs/app.log"
},
"summary": "Launched app and captured home screen."
}
For failure results, include the failing command, exit code, stderr, and the nearest useful artifact. A failed build with no artifact is still useful evidence; a visual claim with no artifact is not.
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Find available device | Confirm the input and environment | Preserve the failure and return to this step |
| Boot runtime | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Install and launch | Run the focused check | Preserve the failure and return to this step |
| Capture intended state | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
A real baseline build, installation, launch and screenshot are recorded; this is not a newly generated to-do app.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Recorded sample check
On Xcode 26.6 with an iOS 26.5 simulator, the Reading List verification script passed 3 unit tests and 2 UI tests. It exported six screenshots. This image is one of those outputs, not an AI-generated mockup. The sample uses JSON persistence and does not establish all-client app generation or a complete accessibility audit.
Related reading
- Five checks for an AI-built SwiftUI app
Use persistence, search and accessible states to make “it works” a testable claim.
What to do next
Next: What to do when the build fails: reading Xcode errors with an agent