Any plans on renaming "Sharing" so it won't conflict with Apple's private Sharing.framework?

[BlameMatt]

It is a real pain having to deal with this and it is causing crashes when the private framework is being auto-detected when expecting to access your library code. It was a pretty bold move to name it "Sharing" and directly violates the Apple Guidelines for Creating Frameworks (https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/CreationGuidelines.html) which suggest:

You should try to choose names that clearly associate each symbol with your framework. For example, consider adding a short prefix to all external symbol names. Prefixes help differentiate the symbols in your framework from those in other frameworks and libraries. They also make it clear to other developers which framework is being used. Typical prefixes include the first couple of letters or an acronym of your framework name. For example, functions in the Core Graphics framework use the prefix “CG”.

[jshier]

That is an archived article that only applies to Objective-C.

[mbrandonw]

Hi @BlameMatt, as Jon mentioned, that article is only relevant to Objective-C and not Swift.

Can you back up a bit and explain the root problem you are actually having? We are not aware of any crashes that our library can cause.

[BlameMatt]

The library itself isn't causing a crash, it's the way that Apple chooses to link frameworks. We are trying to build our project structure using the Tuist tooling and I am running into issues with the auto-linker that is fairly aggressive in insisting that it choose Apple's private frameworks first, which is resulting in a crash. There's some discussion of this issue on your forums already: #51

Essentially someone on your team named this framework a very generic name that someone at Apple also chose. This has been causing me (and apparently several others) many-many hours trying to work around. Is there some reason a simple rename is not being considered since you are clashing with Apple's frameworks?

[mbrandonw]

We are trying to build our project structure using the Tuist tooling and I am running into issues with the auto-linker that is fairly aggressive in insisting that it choose Apple's private frameworks first, which is resulting in a crash.

So then it seems like you should open an issue with Tuist and see if it can be fixed on their side?

There's some discussion of this issue on your forums already: #51

I'm aware of that discussion, but so far no one has been able to share a reproduction of the problem. If you can provide a non-Tuist project that shows the crash, we will definitely look into it more.

Also, if you read the discussion you will see that the author points out that Tuist has a workaround:

I've solved this with the steps described in https://community.tuist.dev/t/sharing-framework-symbol-not-found/279/9. For vanilla SPM or Xcode projects this can probably also be fixed by using moduleAlias in SPM or alternatively in other swift flags -module-alias Sharing=PFSharing. The PRODUCT_NAME build setting maybe also has to be changed.

Did you try that? There is also another discussion here with more information on workarounds in Tuist.

Is there some reason a simple rename is not being considered since you are clashing with Apple's frameworks?

Yes, that would be hugely disruptive to our ecosystem of libraries, requiring major version releases of multiple libraries and forcing tens of thousands of developers to update their codebases. And we would be doing that without someone providing proof that this is truly a problem that we should be solving.

It's certainly something we will consider if this problem is shown to be insurmountable, but so far it seems to only affect Tuist projects, and it seems that module aliases work just fine to workaround the problem.