Conflicting package/module names with upstream OpenTelemetry.

[dibeakshay]

Describe the bug

Hi DataDog team 👋,

We're facing an issue integrating opentelemetry-swift-packages alongside the upstream OpenTelemetry Swift SDK due to conflicting package and module names.

In your Package.swift, the following logic determines which package to pull based on an environment variable:

 let useOTelSwiftPackage = ProcessInfo.processInfo.environment["OTEL_SWIFT"] != nil 
let opentelemetry = useOTelSwiftPackage ? (name: "opentelemetry-swift", url: "https://github.com/open-telemetry/opentelemetry-swift.git", version: Version("1.13.0")) 
: (name: "opentelemetry-swift-packages", url: "https://github.com/DataDog/opentelemetry-swift-packages.git", version: Version("1.13.1")) 

While this setup is flexible, we are unable to reliably set the OTEL_SWIFT environment variable in our current build system, which prevents us from controlling which variant is used. This issue was already reported in #30.

The problem arises because both your lightweight fork and the upstream SDK use the same:

• Package name: opentelemetry-swift
• Module names: OpenTelemetryApi

This causes Swift Package Manager to fail when trying to include both in a single project.

Proposed Solution: To allow both variants to coexist, we propose the following:

• Rename the package exposed in your fork to something unique (e.g., opentelemetry-datadog).
• Rename the top-level module names to avoid clashing with the upstream SDK, e.g., OpenTelemetryDatadogApi

This would eliminate the name collision and allow consumers to explicitly include both packages when needed, without relying on build-time environment switching.

We’d be happy to collaborate or submit a PR if this is something you’re open to.

Reproduction steps

Try to add Datadog and complete opentelemtry in a single project.

SDK logs

No response

Expected behavior

We should be able to add datadog and complete opentelemetry in a single project

Affected SDK versions

2.26.0

Latest working SDK version

2.26.0

Did you confirm if the latest SDK version fixes the bug?

Yes

Integration Methods

SPM

Xcode Version

Xcode 16

Swift Version

5.9

MacOS Version

No response

Deployment Target

No response

Device Information

No response

Other relevant information

No response

[ncreated]

Hi @dibeakshay 👋

Thanks for the detailed write-up and the thoughtful proposal.

You're absolutely right in identifying the conflict between our fork of opentelemetry-swift and the upstream SDK. The root of the issue lies in the current structure of the upstream opentelemetry-swift repository, which historically bundled both the API and SDK together. This prevented us (and other vendors) from depending solely on the API without also pulling in the full SDK and its transitive dependencies.

To mitigate this, we created and adopted our own fork (opentelemetry-swift-packages) that isolates just the API. We recognize that this workaround has its downsides, especially in cases like yours where both the upstream SDK and our fork are needed in the same project.

The good news is that we’ve been in ongoing discussions with the OpenTelemetry Swift maintainers, and recent progress has been made toward resolving this. A formal effort to split the API and SDK into separate packages is already underway on their side:

👉 https://github.com/open-telemetry/opentelemetry-swift/pull/885

Given this movement, we don’t plan to introduce additional changes (like renaming packages or modules) to our fork. Our intention is to migrate away from the fork entirely and depend directly on the official OpenTelemetry API package once the upstream split is completed.

Thanks again for raising this - your feedback highlights exactly why this separation is important, and we're hopeful the upcoming changes in the upstream repo will make integration smoother for everyone.

[dibeakshay]

Hi @ncreated ,

Thanks for the detailed context and for sharing the upstream plans.

In one of our feature integrations, we’re currently blocked from proceeding due to this conflict. This is impacting our delivery timelines, so we’re looking for the quickest path forward. Is there any temporary workaround you’d recommend so we can proceed in the interim? Also, is there an estimated timeline for when the upstream API/SDK split will be available so we can plan our release accordingly?

[maxep]

Hey @dibeakshay,

There is no ETA from the opentelemetry-swift team at this point. The quickest way would be to use the OTEL_SWIFT environment variable each time you interact with Xcode.

• To open Xcode: open --env OTEL_SWIFT YourProkect.xcodeproj
• To run build: OTEL_SWIFT=1 xcodebuild ...

But that will be a painful devx. I would recommend instead that you fork our project and update the Package.swift to always depend on the official opentelemetry-swift. That would be a temporary measure and as soon as the otel swift project is splitted, we will make the change on our side.

I hope this helps!

[oliver-perez]

@ncreated I saw that https://github.com/open-telemetry/opentelemetry-swift/pull/885 has already been closed. Do you have any updates on this issue? I’m experiencing the same problem

[cameroncooke]

We can't even build our app now in Xcode 26 because this is blocking. We're now considering removing Datadog. This has to be a priority.

[cameroncooke]

@ncreated I saw that open-telemetry/opentelemetry-swift#885 has already been merged. Do you have any updates on this issue? I’m experiencing the same problem

Doesn't actually look like it was merged; it was closed with unmerged commits. Looks like they have abandoned that particular approach.

[maxep]

Hey @cameroncooke 👋 Looks like they abandoned the otel-swift vs. otel-swift-contrib, but they have split with otel-swift-core and otel-swift. We now need to follow up on this.

Regarding Xcode 26, could you share your issue? because I don't see how this can block builds on iOS 26, it might deserve a seperate issue.

[cameroncooke]

Hey @cameroncooke 👋 Looks like they abandoned the otel-swift vs. otel-swift-contrib, but they have split with otel-swift-core and otel-swift. We now need to follow up on this.

Regarding Xcode 26, could you share your issue? because I don't see how this can block builds on iOS 26, it might deserve a seperate issue.

The specific error we're seeing in Xcode 26, which we're not seeing in Xcode 16.4, is:

multiple packages ('opentelemetry-swift', 'opentelemetry-swift-packages') declare targets with a conflicting name: 'OpenTelemetryApi’; target names need to be unique across the package graph

We have a dependency on AWS Amplify, which brings in the following transient dependencies aws-sdk-swift, which is dependent on smithy-swift, which is dependent on OpenTelemetryApi.

When we resolve packages using Xcode 16 toolchain, we get no errors, Xcode 26 complains, and we can't therefore build our project.

[maxep]

Thanks, @cameroncooke !

I see now, not sure how this builds with Xcode 16.. Even if we upgrade to the latest 2.x version of open-telemetry, the smithy-swift will still depend on the 1.x and SPM won't be able to resolve.

We will follow up the open-telemetry update. But for your specific use-case, the best would be to fork our repo and update these lines to only depend on the official otel-swift. This is not ideal but that should unblock you while we and smithy-swift make the necessary changes.

I hope this helps.