How Sentry Builds Type-Safe Metrics API in Swift Part I
Original post 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
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.
Continue reading
What This Article Covers
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.
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.
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.
This page summarizes “Building Type-Safe Metrics API in Swift Part I” by Sentry, published Feb 9, 2026. All credit for the original work goes to the authors.
