Q&A: Building Embrace’s open source iOS SDK on OTel

A: Besides integrating with the OpenTelemetry Swift SDK and getting familiar with that codebase on a deeper level — I would say the biggest challenge the team faced was converting existing Embrace features into something that is represented by OTel Primitives.

Some telemetry we capture already has semantic conventions in OTel. Implementing those semantics came easily, but it was tedious verifying that existing Embrace features still passed tests.

For Embrace features that didn’t have an existing semantic convention (yet), we had to provide an initial implementation. This means we have to step back and think how we should model this data so it is not Embrace specific. Once we’ve proven the modeling convention we can propose these additions to the Client Side SIG for further evaluation.

A: Absolutely! We’ve already had contributions where a developer was using the SDK in ways that we don’t test often. The developer ran into some conditional logic that occurs only on macOS and they were nice enough to propose a change via a Pull Request.

When the team reviewed this PR, we realized the implementation they provided worked on every Apple platform. We could remove the conditional and use their implementation always. This type of refinement allows the code to be easier to read and more consistent for all users.

That said, even if a contribution isn’t made to the project, being able to discuss the code openly will increase the feedback we receive. Github Issues is a great place to start a discussion about the project. The ability for clients/prospects to see our code will also help answer a lot of questions that people have about our technology. Instead of asking “how does this work?”, someone can step through and read the logic first hand.

A: It’s tough to say — I’m not anticipating or expecting any contributions to come in, but when they have come in it absolutely makes my day. We’re all trying our best to make something for the community. When PRs do come in it is a sign to us that somebody out there is thinking, “this is useful and I want to help make it better.” It’s an artifact that the community is growing and that feels great.

In terms of integrating contributions; we’re going to try our best to respond to any Issues or PRs that come in. The response will vary depending on the change being requested and our process will evolve over time as we learn from it. To start we have our CONTRIBUTING.md file to give the basics. We actively monitor the GitHub repository and hope to be as transparent as possible in any discussions that go on.

A: There are two main benefits I’m looking forward to.

The first is our ability, when designing interfaces, to provide power to our users. There is a different mindset that you can take as a developer when there is a looming rebuttal of “well they can fork it and enable that thing anyway.” It prevents us from unnecessarily hiding some abstraction because we don’t think an external developer needs the complexity. My thought process has had to change to “why not let someone do that?”.

A good example of this is how we implement our automatic instrumentation. These “Capture Service” objects are public (open in Swift) and we expect people to create their own to fill in any gaps they need. For the instrumentation we include out of the box we get to use the same public interface to create Traces or Logs! We don’t need a layer to differentiate “what we collect” vs “what the app developer collects.” Everything can be treated the same which means we get to maintain a single pipeline instead of two parallel ones.

The second benefit is our ability to streamline the process when diagnosing issues with someone. It’ll be much easier for people to point out where in our SDK some assumption is incorrect for their situation. I’m hopeful that Issues will have more context. If there are more questions about what is causing the issue, our team can hop on a call and step through both app and SDK in order to find the root cause. Being open source removes the black box from the process and I hope it will make the SDK’s behavior (correct or incorrect) visible to everyone.

A: We currently attend a couple SIG meetings a week. Android, Swift, and the Client-Side meetings are each weekly check-ins for anyone interested in these projects. At Embrace, we have quarterly goals to contribute to these projects where we can.

Besides participating in the necessary maintenance of a software project, we also want to contribute the ideas we have around modeling telemetry we collect and formalizing these into semantic conventions. The client-side space is still finding its footing; we want to cooperate with others and discuss how best OpenTelemetry can solve the problems that everyone faces.

A: For the embrace-apple-sdk, the team was given a great opportunity. It wasn’t just that we were able to open source our codebase and update it to work with the opentelemetry-swift project. We had the opportunity to re-write the entire project from the ground up, in Swift, with all of our learnings from the 5.X series.

This allowed us to re-think a lot of the existing features to find common patterns. It allowed us to simplify our data model to fit into the well known Open Telemetry primitives. It also allowed us to rethink our persistence layer and implement it using SQLite via GRDB. I can’t stress enough that 6.X is a major change that we are incredibly excited about.

To me, what is really rewarding about this is the company has confidence in the team to set goals and deliver on them. They saw the opportunity and trusted us when we said, “We can make this better.” I appreciate that a lot.

A: Do it! It will let you think a lot more freely and you’ll get much better feedback from anyone that tries it out. Do not ever think, “no one will care about this.” If nothing else, your GitHub profile page won’t be as empty.

We’re all out here trying to build something useful. For developers, seeing how something is built is just as useful as using whatever it was that was built.

So put it out there! It will inspire others!

A: The SIGs are great. People who regularly join come from many different observability vendors and we have the opportunity to cooperate together and share ideas.

Observability is a really competitive space, but at these SIG meetings we get a better understanding of the problems that others are trying to solve. We get to work on those problems together! Whether it’s new additions to the OpenTelemetry Spec (Events API I’m looking at you), or updates to semantic conventions (Crash Reports anyone?) I’m excited to know that these will apply across the industry.

If you are even a little bit interested in joining a meeting please checkout the public OpenTelemetry Calendar. We’d really appreciate your company. You can find me at the Swift SIG or Client-Side SIG meetings most weeks.

Embrace’s open-source iOS SDK is the next step in mobile app observability.

Our platform is fully enterprise supported and built to seamlessly fit into complex data ecosystems, delivering the missing pieces of mobile context for true end-to-end visibility.

Learn more about Embrace’s OTel SDKs here, or get started with the iOS OTel exporter here.