Code Coverage in Swift: How to Measure and Improve Quality

Code Coverage in Swift: From "Just Tests" to Real Confidence

Have you ever deleted "dead" code, only to have the build fail a week later? Or boasted about 90% coverage, only to have bugs still appear in production? If so, this article is for you. Code coverage in Swift is not just a checkbox for CI/CD. It's your personal radar: it shows which parts of your code are actually being tested and which are living on "borrowed time."

We won't talk about the fact that you need to write tests — that's obvious. Instead, we'll break down: how to make Xcode calculate coverage correctly, which metrics really matter (spoiler: not just the percentage), and why 100% coverage is often a trap. Let's go!

1. Why Measure Code Coverage in Swift?

Imagine you are a ship captain, and tests are your navigators. Code coverage is a map that marks "explored" areas. If the map is blank, you're sailing blind. If it's 100% filled in but without considering edge cases, you still risk running aground.

The main reasons to implement code coverage Swift:

• Finding "gray areas" — you immediately see which code is never executed in tests (e.g., error handlers).
• Refactoring without fear — a high coverage metric gives you the green light to rewrite modules.
• Documenting requirements — tests become living documentation, and coverage shows how complete that documentation is.
• Quality control in CI — you can block merges if coverage drops below a threshold (e.g., 80%).

But remember the main thing: code coverage in Swift is a metric, not a goal. Chasing a number for the sake of the number is a path to useless tests that check getters and setters.

2. Tools for Measuring Coverage in Swift: From Xcode to Third-Party Utilities

The Swift ecosystem offers several ways to get those coveted percentages. Let's look at three main ones: built-in Xcode, the slather utility, and CI services (e.g., Codecov).

2.1. Built-in Xcode Code Coverage

The simplest and most accessible tool. All you need to do is enable the Gather coverage data option in your build scheme (Product → Scheme → Edit Scheme → Test → Options). After running your tests, open the Report Navigator (Cmd+9) and select the Coverage tab.

Pros: no installation required, integration with Xcode, shows coverage in real time.

Cons: cannot merge results from multiple targets, difficult to export to CI.

Example setup for a project:

// In the build scheme (Test → Options), check "Code Coverage"// After running tests (Cmd+U), view the report in the Report Navigator.// For each file, you see a line with the coverage percentage and highlighted lines:// green — executed, red — not executed.

2.2. Slather — A Flexible Report Generator

Slather is an open-source utility that parses .profdata files (Xcode coverage results) and generates beautiful HTML reports, XML (Cobertura), or even JSON. It is especially useful if you use CI and want to maintain a coverage history.

Installation via CocoaPods or Homebrew:

# Homebrewbrew install slather

# CocoaPods (in Podfile)pod 'slather'

Example .slather.yml configuration:

# .slather.ymlcoverage_service: cobertura_xmlxcodeproj: MyApp.xcodeprojscheme: MyAppsource_directory: MyApp/Sourcesoutput_directory: reportsignore:  - MyAppTests/*  - Pods/*

Running it:

slather coverage -s --scheme MyApp MyApp.xcodeproj

Pros: flexibility, support for different formats, integration with CI.

Cons: