Why We Keep Avoiding Tests in iOS—And What the Tools Should Do About It

Let’s be honest—many of us avoid writing tests for our iOS apps. Not because we don’t care about quality, but because the current tooling often feels like it’s working against us rather than with us. The problem isn’t laziness; it’s practicality.

The Testing Paradox in iOS Development

iOS is fundamentally a UI-first platform. Yet our testing ecosystem remains largely focused on backend-style logic testing. This disconnect creates a situation where we end up testing the stuff that rarely breaks (business logic) while avoiding tests for the stuff that breaks all the time (UI and interactions).
In my experience, the majority of bugs don’t come from business logic errors. They come from UI issues, state management mistakes, and incorrect component connections.
Yet where do we spend most of our testing effort? You guessed it—on business logic, the area that’s least likely to cause problems in production.

Apple’s Role in the Testing Ecosystem

Let’s address the elephant in the room: Apple has consistently prioritized developer tooling that makes building apps easier, but testing remains something of an afterthought.
SwiftUI is a prime example. It revolutionized how we build UIs, but the testing story was minimal at launch and remains incomplete years later. While UIKit had its issues, at least we could inspect the view hierarchy and access individual elements.
Apple’s reluctance to provide first-party testing solutions for UI behavior verification suggests they either don’t consider it a priority or don’t fully understand the day-to-day testing challenges developers face.

The Pain Points That Drive Us Away

Let’s not sugarcoat it—most iOS tests suck to write and maintain. The common complaints:

• Flaky: They fail randomly and shake our trust.
• Brittle: A small UI tweak breaks five unrelated tests.
• Slow: Especially with UI and integration tests on CI.

This creates a vicious cycle: devs don’t trust tests → they stop writing tests → bugs increase → testing gets blamed → nothing improves. We’ve all seen it.

The State of iOS Testing Tools: What Works and What Doesn’t

XCTest: Still Solid for Unit Testing

XCTest remains the foundation for unit testing in iOS. It’s:

• Fast and reliable for testing business logic
• Well-integrated with Xcode
• Recently improved with parameterized tests and async/await support

For testing pure functions, services, and view models, it gets the job done—but it’s not designed for testing UI behavior.
What we actually need is the ability to run UI behavior tests within the XCTest framework that would execute quickly and reliably.

Swift Testing: The New Kid on the Block

Swift Testing represents Apple’s vision for the future of testing. It focuses on:

• Clarity and readability
• Predictable behavior
• Developer ergonomics

The improvements are welcome, but the fundamental issues with UI testing remain unaddressed.

XCUITest: The Double-Edged Sword

This one hurts the most. In theory, XCUITest should be amazing. It lets you drive your app like a user, tap buttons, type text, scroll through lists, and verify the results. In practice, though:

• Tests take forever to run
• Tests break when UI elements move or change
• Tests frequently fail due to timing issues or animations
• Maintenance becomes a nightmare

UI tests that pass locally will often fail on CI for reasons like timing issues, animations, or just randomness. You end up adding sleep calls or retry logic just to get through a test run. And because it’s so expensive to run these tests, we mostly stick to happy path coverage—”Can a user log in?”—and not much else. So yeah, technically covered. But not actually protected.

The SwiftUI Testing Conundrum

SwiftUI changes the way we write UIs—but not the way we test them, at least not with Apple’s tooling. There’s still no official support for inspecting views, simulating bindings, or asserting visual hierarchy. You’re stuck either testing your view models or reaching for hacks..
SwiftUI is essentially a black box—unlike UIKit where you could inspect view controllers and their subviews.
What we need is the ability to:

1. Mount SwiftUI views in an isolated test environment
2. Inspect the resulting view hierarchy
3. Interact with it programmatically
4. Make assertions about state and appearance

Community Solutions: Filling the Gaps

The iOS community hasn’t been sitting idle while waiting for Apple to improve testing tools. Several notable community-driven solutions have emerged:

ViewInspector: Promising but Limited

ViewInspector provides XCTest integration for SwiftUI views with decent performance (4/5 on speed). It lets you:

• Inspect the presence of views
• Check some state properties
• Trigger basic interactions

    import ViewInspector
    
    @MainActor
    func test_categoryRow_when_appear_then_category_title_visible() async throws {
        // ---- GIVEN ----
        let category =  Category.electronics
        
        // ---- WHEN ----
        let sut = CategoryRow(category: category)
        
        // ---- THEN ----
        _ = try sut.inspect().find(text: category.title)
    }

But it’s “hacky” under the hood and breaks frequently with SwiftUI updates. It also can’t inspect many important states like button enablement or trigger NavigationLinks in a NavigationStack.

Snapshot Testing: Good for Regression, Bad for TDD

Snapshot testing tools like Point-Free’s SnapshotTesting offer visual regression testing. They’re great for:

• Detecting layout changes
• Verifying theming/appearance updates
• Ensuring UI consistency

When you run a snapshot test for the first time, you will have to take the snapshot and store it in your test target. These files can quickly add up in storage. You can also imaging that the images can vary strongly by device type:

⠀But they’re also:

• Brittle and extremely sensitive to minor changes
• Difficult to use in CI pipelines
• Not suitable for test-driven development
• Slow compared to unit tests

⠀My recommendation: Use sparingly and only when nothing else works.

What We Actually Need: The Requirements

For SwiftUI testing to really work in the long run, we need tools that provide:

1. Speed: Tests should run quickly (under 100ms per test)
2. Stability: No flakiness, no random failures
3. Feedback: Clear information about what’s rendered and what state it’s in
4. Direct Assertions: Ability to make precise assertions against views and state
5. Interaction: Programmatically interact with views like a user would
6. Maintainability: Tests that clearly show intent and what broke

In my next blog post, I’ll show you how we can start building a better testing experience for SwiftUI apps. I’ll introduce a pattern that:

• Uses XCTest/Swift Testing for speed
• Mounts SwiftUI views in isolation
• Provides direct feedback on rendered state
• Allows for stable assertions and interactions
• Remains maintainable as your app evolves

Read about it here 📋 Discovering PreferenceKeys How I Accidentally Unlocked SwiftUI’s Secret Testing API

Conclusion: Don’t Blame Yourself—Blame the Toolbox (a Little)

Testing iOS apps isn’t inherently painful. It’s just that the tools often don’t align with the realities of frontend development. If you’ve felt that frustration—you’re not alone. It’s not that you’re doing it wrong. It’s that the toolbox still needs work.
Thankfully, change is happening. If Apple can double down on testability in SwiftUI and close the gap on tooling, we might finally get to a place where tests are as delightful as the apps we build.

What patterns have you found effective for testing your SwiftUI apps? Let me know in the comments, and stay tuned for the next post where I’ll dive into practical solutions.