SPM - "swift-sdk" causes package name conflicts

[mrtnrst]

Overview

The way SPM imports happen uses the "repo name." Because of this, anyone importing this package, at any point, will conflict with other similarly named packages. Unsure of the correct course of action here, as this package is undoubtedly included in plenty of different projects.

I've also created this issue in optimizely/swift-sdk#450

Example Project

I haven't made an example project, but you can recreate this issue by creating a blank project and adding both this SDK and the Optimizely/swift-sdk SDK.

Workarounds

Currently, the only workaround I have found is forking the package in a separate repo to rename the repo and going from swift-sdk to iterable-swift-sdk.

[tapashmajumder]

@mrtnrst We will take a look at this soon.Thanks for bringing this to our notice.

[mrtnrst]

@tapashmajumder this issue is resolved in Xcode 13.3 with version 2 file format of SPM. I'm going to close this issue, thanks!

[mrtnrst]

Actually will need to re-open, I spoke too soon here. After cleaning the local cache and resetting, I'm getting the same error again:

[tapashmajumder]

OK. We will be taking a look at this. Please give us a week or two to release a new version.

[Mturner005]

@mrtnrst
Hello Martin. After reviewing this further it appears that this isa bug in Xcode. Xcode is supposed to be using the full url or package name as a reference to distinguish between different packages.

One thing that we've been discussing internally for some time now is to actually rename our repos. However, this is not something that we'd be able to commit to doing hastily as there are many other things that could be affected by that change. But, again, it is something that we are looking into.

While we completely understand the issue that this causes you we were wondering if it would be possible for you to do either one of two work arounds for now:

1. Use the xcframework files that we embed in our Github release. This would probably be easiest. Please note that we haven't embedded xcframework files for the latest release. We will be releasing 6.4.2 shortly and that will have attached xcframework file in the Github release.
2. Use Cocoapods or Carthage.

Of course the third scenario that could happen is that Apple releases a version of Xcode that fixes this bug, and we've filed a bug ticket with Apple on your behalf, but please let us know if either of these work arounds would work for you in the mean time.

[mrtnrst]

@mrtnrst Hello Martin. After reviewing this further it appears that this isa bug in Xcode. Xcode is supposed to be using the full url or package name as a reference to distinguish between different packages.

One thing that we've been discussing internally for some time now is to actually rename our repos. However, this is not something that we'd be able to commit to doing hastily as there are many other things that could be affected by that change. But, again, it is something that we are looking into.

While we completely understand the issue that this causes you we were wondering if it would be possible for you to do either one of two work arounds for now:

1. Use the xcframework files that we embed in our Github release. This would probably be easiest. Please note that we haven't embedded xcframework files for the latest release. We will be releasing 6.4.2 shortly and that will have attached xcframework file in the Github release.
2. Use Cocoapods or Carthage.

Of course the third scenario that could happen is that Apple releases a version of Xcode that fixes this bug, and we've filed a bug ticket with Apple on your behalf, but please let us know if either of these work arounds would work for you in the mean time.

100% understandable it can't be an overnight thing to change. Our team is using SPM so a forked repo that we kept synced in Github helps get around this for now.

[roninopf]

I'll be closing this issue due to the problem being identified as a part of Xcode, as well as workarounds available. Thanks for reporting! I know this has started discussions on how we want to properly identify our repos and package naming, which I definitely will acknowledge as not consistent, at the moment.