Testing
macOS AppKit applications are tested with XCTest, Apple's first-party testing framework. Unlike iOS testing where UIKit is the focus, macOS AppKit has some unique characteristics—NSDocument architecture, menu bar integration, window management—that require specific testing approaches. This guide covers unit testing AppKit apps with XCTest, including model
Swift
watchOS apps have the same Xcode testing infrastructure as iOS — XCTest, the test report, and CI integration all work. What's different is the platform: the Watch screen is tiny, UI testing has significant constraints, and the simulator behaves differently from a physical device. This guide covers what works,
Swift
tvOS apps run on Apple TV, where the primary input is a Siri Remote rather than a touchscreen. Testing a tvOS app means verifying that focus moves correctly between elements, that button presses trigger the right actions, and that your layout works on a 1080p or 4K screen. XCTest supports
Swift
XCTest includes a built-in performance testing API that lets you measure how long a block of code takes and compare it against a stored baseline. When performance regresses, the test fails — giving you an early warning before slow code ships to users. The measure Block The simplest performance test wraps
Swift
Instruments is Apple's performance analysis tool included with Xcode. It attaches to a running process — including your test target — and records CPU usage, memory allocations, and retain cycles. When tests run slowly or your app leaks memory during a test run, Instruments shows you exactly where the time
Swift
visionOS is Apple's operating system for Apple Vision Pro. It runs SwiftUI apps in an immersive spatial environment alongside traditional window-based apps. Testing visionOS presents unique challenges: RealityKit entities exist in 3D space, gesture detection involves eye gaze and hand gestures, and the full immersive experience cannot run
iOS
Apple's swift-testing framework (available in Xcode 16, Swift 6) replaces XCTest's 20-year-old Objective-C heritage with a modern, macro-based API. Instead of XCTAssertEqual, you write #expect(a == b). Instead of func testSomething(), you write @Test func something(). Parameterized tests, parallel execution, and expressive failure messages are built
iOS
Realm's object graph persistence is tightly coupled to its runtime — you can't just pass in a mock dictionary. Testing Realm-backed iOS code requires either an in-memory Realm configuration (fast, isolated, no file cleanup) or a purpose-built mock layer. This guide covers both approaches, plus migration testing,
iOS
Combine's asynchronous, declarative model makes testing tricky — pipelines emit values over time, operators transform them, and errors can cancel the stream. This guide covers two approaches: the built-in XCTestExpectation pattern for simple cases, and the CombineExpectations library for ergonomic, readable publisher assertions. You'll write tests for
iOS
XCUITest runs your app in a simulator — it's slow, flaky, and gives no introspection into SwiftUI internals. ViewInspector lets you unit test SwiftUI views directly: inspect the view hierarchy, find subviews by type, trigger bindings, simulate button taps, and assert on text values — all without launching a simulator.
Testing
VoiceOver is the primary screen reader on iOS, and testing it manually doesn't scale. XCTest's accessibility audit APIs let you catch labeling gaps, broken focus order, and trait mismatches in CI before they reach real users. This guide covers the full automation stack from XCUIAccessibility queries
Testing
visionOS introduces entirely new UI paradigms — volumetric windows, immersive spaces, eye tracking, and spatial audio — that existing iOS testing patterns don't cover. This guide walks through XCTest for visionOS, RealityKit entity hierarchy testing, SwiftUI volume and immersive space testing, eye tracking simulation in Simulator, and render budget verification.