SwiftUI previews, tests, accessibility, and performance
No single SwiftUI test surface proves the interface. Previews accelerate inspection, unit tests prove rules, UI tests prove wiring, and device measurements prove hardware behavior.
Preview states, not one ideal record
#Preview("Load failure") { NoteListView(model: .fixture(state: .failed("Disk unavailable")))}
#Preview("Large text") { NoteEditor(draft: .fixture) .environment(\.dynamicTypeSize, .accessibility5)}Useful fixtures cover loading, empty, populated, error, long localization, right-to-left layout, large text, dark appearance, and permission denial. A preview is interactive inspection, not automated passing evidence.
Test rules below the view
import Testing
@Test("Blank titles are rejected")func blankTitle() { let draft = NoteDraft(title: " ", body: "Observed near creek") #expect(draft.titleError == "Enter a title.") #expect(!draft.canSave)}Formatting, validation, filtering, route parsing, and cancellation policy run faster and fail more clearly outside rendered views.
Keep UI journeys narrow
func testCreateNote() { let app = XCUIApplication() app.launchArguments = ["--ui-testing", "--store", "in-memory"] app.launch()
app.buttons["New Note"].tap() app.textFields["Title"].typeText("Creek crossing") app.buttons["Save"].tap() XCTAssertTrue(app.staticTexts["Creek crossing"].waitForExistence(timeout: 2))}Launch arguments select deterministic local data. UI automation proves the create flow is wired through controls, navigation, and storage. It does not need every validation combination already covered by unit tests.
Audit accessibility beyond identifiers
Automation identifiers help tests find elements. They do not prove useful VoiceOver order, labels, values, actions, Dynamic Type layout, contrast, reduced motion, keyboard access, Voice Control, or localization. Record those checks separately.
Measure a budget
Define a user outcome first: launch to usable notes, scroll a seeded collection, open an editor, or save an attachment. Record destination, data size, release configuration, metric, and variance. Simulator timing does not become device performance evidence.
Validation boundary
The examples did not run under Xcode. Preview rendering, Swift Testing in an app target, XCUITest, accessibility audits, Instruments, Simulator, and device performance remain Not verified.
Series navigation
- Previous: Part 42: SwiftUI scenes, windows, navigation, and commands
- Next: Part 44: SwiftUI Field Notes capstone
- Series index: Zero to iOS Hero
References
- Previewing your app’s interface in Xcode covers previews.
- Swift Testing covers native Swift behavior tests.
- Testing your apps in Xcode covers plans, UI tests, and results.