Sentry • Phil Niedertscheider • Feb 9, 2026

Building Type-Safe Metrics API in Swift Part I

Article Summary

Phil Niedertscheider from Sentry reveals why designing a public API took longer than building the actual feature. His deep dive into Swift's type system shows how the right language features can make or break developer experience.

Sentry just shipped an experimental Metrics API in their Cocoa SDK v9.4.0, joining their Python, JavaScript, and Flutter SDKs. This first part of a two-part series breaks down the Swift engineering decisions behind a type-safe metrics collection API that developers will use daily and can't easily be changed post-release.

Key Takeaways

Protocol extensions enable default parameter values that Swift protocols don't natively support
Enums with associated values balance type safety with custom unit flexibility
ExpressibleByStringLiteral eliminates boilerplate for generic metric units
Counter metrics use UInt (never negative), while gauges use Double for precision

Critical Insight

The proof of concept took weeks, but most engineering effort went into API design decisions using protocol extensions, associated enum values, and compiler protocols to create a clean, type-safe interface.

Part II tackles the harder problem: accepting multiple attribute value types (String, Int, Bool, Array) without resorting to type-erased Any and navigating Swift compiler limitations.

About This Article

Problem

Swift protocols don't support default parameter values natively, which caused build-time errors when Sentry tried to make the counter metric's value parameter optional with a default of 1.

Solution

Phil Niedertscheider's team added protocol extensions with convenience overloads. This lets callers skip optional parameters, and the extension passes the call to the required protocol method.

Impact

Developers can now write count(key: "my-key") without providing a value. This cuts down on boilerplate code while keeping type safety intact across the Cocoa SDK's metrics API.