Dev Conversations #16: Moritz Lang
👍 0
Dev Conversations is a monthly series where Swift Toolkit features members of Swift work groups, content creators, and people who contribute to the Swift community, focused on tooling, developer experience and Server Side Swift.
In these talks, we discuss open source projects, tips for professional growth, and many other valuable insights and perspectives from other developers.
Moritz Lang is a software engineer based in Berlin who works across iOS and server-side Swift, with a strong focus on observability. After starting out in 2013 with typical full‑stack web development, he quickly gravitated to Swift when it was announced in 2014 and has been combining client and server work ever since.
A university project about microservices and observability led Moritz to Google Summer of Code, where he worked on the Swift Distributed Tracing library — the missing link alongside SwiftLog and SwiftMetrics to complete the three observability pillars.
His work helped making observability more practical for production systems, by using distributed tracing with spans that can be linked together across microservices. Leveraging Swift Concurrency, task locals, and the OpenTelemetry standard, Swift OTel matured and reached its 1.0 release: the package can export Swift’s logs, metrics, and traces to any OpenTelemetry‑compatible backend. In October 2025, he presented a talk on the Server Side Swift Conference about the fresh from the oven Swift OTel 1.0.
In this episode, Moritz joins us to talk about Swift OTel’s journey, what observability means in practice for systems of any size, and how future tools like Swift Configuration could make observability setups, and Server Side Swift in general, even smoother.
You can also find the written interview and the podcast links after the video in case you prefer reading or listening, and the relevant links at the end of this page.
Also available in your favorite podcast player 
Swift Toolkit
Hey Moritz, how's it going?
Moritz
Hey, good to see you — I'm doing well, thanks for having me.
Swift Toolkit
You recently announced Swift OTel 1.0, and I loved the talk you gave about observability in server-side Swift.
Before we get into the details, tell me a bit about how you got into programming and how Swift — and later Swift on the server — entered the picture.
Moritz
I started programming around 2013 after my sister introduced me to it. Before that I was mostly into music and football, and my first steps were the usual full‑stack web stack — JavaScript on the front end, PHP on the back end.
When Swift was announced in 2014 it suddenly made iOS development feel much more approachable than Objective‑C, which had scared me off at first. From then on I worked as an iOS developer, both as a freelancer and full‑time, but I always wanted to combine it with server‑side Swift.
If my day job was mostly iOS, I’d play with server‑side Swift on the side, and if I was doing more server work I’d still keep iOS in the mix — I’ve always liked having both in my life.
Swift Toolkit
At some point that interest turned into observability work and Google Summer of Code. How did that happen?
Moritz
In 2017 I moved to Berlin to study software engineering, and in one semester we built a microservice‑based system. That’s when I first really worked with observability tooling and saw how important tracing is once you go beyond a single service.
Around the same time OpenTelemetry was emerging, and later I applied to Google Summer of Code with a project to build the Swift Distributed Tracing library. Swift has been part of GSoC for a while, and the timing was perfect for me — I got accepted, had a great experience, and that work became the Swift Distributed Tracing library.
Swift Toolkit
For people who haven’t watched your talk yet, could you briefly explain the three pillars of observability and how Swift fits into that picture?
Most iOS and Swift developers are familiar with logging, but metrics and tracing — especially distributed tracing — can feel more abstract.
Moritz
Observability is usually described in terms of logs, metrics, and traces. Logs are the textual events we’re all used to; metrics are numbers like counters and gauges; and traces describe how a request flows through your system and where time is spent.
In Swift we already had API packages for logs and metrics — SwiftLog and SwiftMetrics — but nothing for distributed tracing, so Swift Distributed Tracing filled that gap. These APIs intentionally don’t know where data is sent; they define a standard interface for libraries and applications.
Swift OTel then implements the OpenTelemetry protocol on top of that, exporting spans (and later metrics and logs) from your Swift code to any backend that supports OpenTelemetry.
Swift Toolkit
Swift OTel has been in the works for several years and only recently hit 1.0.
What did the early versions look like, and what needed to happen — both in OpenTelemetry and in Swift — before you felt ready to call it 1.0?
Moritz
Swift OTel started as an example implementation for Swift Distributed Tracing — basically “let’s show this API working for real” by exporting spans via OpenTelemetry. When I began, the OpenTelemetry standard itself was also still evolving; tracing was the first signal to be standardized and even that wasn’t fully stable yet.
Over time OTel added metrics and logs, and the Swift community started using Swift OTel in real projects and asking for support for all three pillars. Contributors like Si Beaumont played a huge role, especially on the metrics side.
On top of that, Swift itself changed a lot: Swift Concurrency arrived, service lifecycle switched to async, and I had to do big refactors to move from EventLoopFuture‑based APIs to async/await. All of that, plus refining the public API and configuration model, took time — I was doing this next to a full‑time iOS job — but it led to the 1.0 we have today.
Swift Toolkit
Why should teams care about observability, even if they’re not operating at massive scale?
Moritz
No matter the size of your system, things will go wrong in production. You really don’t want to discover issues only through user bug reports or failed payments.
Observability is the combination of practices and tooling that lets you see what’s happening in your system at runtime so you can be the first to notice when something breaks, ideally before users are heavily impacted.
Swift Toolkit
Let’s zoom in on distributed tracing itself. You mentioned spans and traces in your talk, and you used microservices as an example.
How would you explain what a span is, and how traces get stitched together across multiple services?
Moritz
A span represents a named operation that takes some amount of time — for example, “authenticate user” or “persist favorite programming language”. When you start the first span for a request, you create a root span and a new trace ID; any additional spans for that request become children in the same trace.
Historically, propagating that context through your code and libraries meant manually passing identifiers everywhere, which was brittle and invasive. With Swift Concurrency and task locals, Swift Distributed Tracing can now keep that context in a task local so that even functions deep in your call stack can create spans that automatically link to the current trace.
To go truly distributed, you copy that context into HTTP headers or gRPC metadata at service boundaries using OpenTelemetry’s standard header format. On the receiving side, another service — whether written in Swift, Go, or something else — extracts that context and continues the trace so your observability backend can reconstruct the full cross‑service request.
Swift Toolkit
You’ve also integrated Swift OTel into real production systems.
What did that look like, and what did you learn from those early adoptions?
Moritz
After GSoC I joined Broken Hands, Tim Condon’s agency behind Vapor, and worked on several server‑side Swift projects there. One of them was a great playground for observability: we integrated the then‑new Swift Distributed Tracing library and Swift OTel into a production system.
Early on we didn’t have task locals yet, so we had to manually thread context through the entire stack and even fork dependencies just to pass tracing information along. It was painful but gave us a lot of insight into what the API needed to look like, and later Swift Concurrency made that story much nicer.
Swift Toolkit
By 1.0 you’d significantly simplified setup.
How does the bootstrap story look today compared to those early days?
Moritz
In early versions you had to wire together a lot of individual pieces and really understand Swift OTel’s internals to get a full setup — exporters, processors, samplers, and so on. It was powerful but intimidating, especially for people just wanting to try it out.
Now you can essentially say “bootstrap observability” with a single line, and you get logs, metrics, and traces exported by default. It’s still configurable for advanced use cases, but the barrier to entry is much lower, which I’m really happy about.
Swift Toolkit
You also mentioned that Swift OTel can be configured almost entirely via environment variables, and that Swift Configuration might play a role in the future.
How does configuration work today, and what are you excited about there?
Moritz
A lot of configuration comes directly from the OpenTelemetry specification — for example, environment variables for where to send telemetry, which protocol to use, and how to sample so you don’t export 100% of events if that’s too expensive.
Today you can often stick with the one‑line bootstrap and just provide environment variables, and Swift OTel will pick them up. Looking ahead, I’m excited about Swift Configuration because it would let you describe configuration in something like a YAML file and have providers translate that into concrete settings for libraries like Swift OTel.
Swift Toolkit
Zooming out, how do you see the state of server‑side Swift and observability right now?
Which libraries already have observability baked in, and where would you still like to see progress?
Moritz
Attending the recent Server‑Side Swift conference, it really felt like the ecosystem has matured: in the early days we were missing libraries for almost everything, and now it’s more of an exception when something doesn’t exist yet.
On the observability side, frameworks like Hummingbird and Vapor, as well as projects like Valkey and the new Temporal SDK, already have built‑in support. There are still important pieces like PostgresNIO that don’t yet have full observability integration, and the more libraries adopt it, the less work end users have to do to get good visibility.
Swift Toolkit
And what’s next for you and Swift OTel specifically?
Moritz
For Swift OTel I’m excited to keep refining the APIs, making configuration smoother, and adding more integrations so people can plug it into their systems with minimal effort.
More broadly, I’m happy to see observability becoming a natural part of how people design Swift services instead of something bolted on at the end.
Swift Toolkit
To wrap up, where can people follow your work and learn more about what you’re doing with Swift and observability?
Moritz
I’m on Mastodon and GitHub as
slashmo - I got luck with that username!Thanks a lot for having me!