For XCFramework support, Parse need to rename the Parse class

[JoeSzymanski]

One of the major limitations of the BUILD_LIBRARY_FOR_DISTRIBUTION flag that is required for generation of XCFRameworks when using Swift code is that there cannot be any top-level object with the same name as the library itself.

In order for Parse to support building for XCFramework usage, the Parse class will need to be renamed (or less likely, the library name will need to change).

This limitation applies to other frameworks that have any public reference to Parse classes, which is blocking our work to move to XCFrameworks.

[drdaz]

Have you got references for this issue?

One of the major limitations of the BUILD_LIBRARY_FOR_DISTRIBUTION flag that is required for generation of XCFRameworks when using Swift code is that there cannot be any top-level object with the same name as the library itself.

I'd love to understand the wisdom behind such a limitation.

[JoeSzymanski]

This appears to be the primary issue: https://forums.swift.org/t/frameworkname-is-not-a-member-type-of-frameworkname-errors-inside-swiftinterface/28962/2

[JoeSzymanski]

To be more specific, Swift has a limitation where if a module and a type have the same name, as usage is assumed to be the type first. That leams to issues in the Swift Interface that's generated where any type that matches the name of the module causes the interface to fail to compile.

This happens even when Parse isn't Swift, because it is hit if any Parse type is exposed in a Swift interface. To avoid this, we would have to remove Parse from our public interface, which I'm not sure is possible without trying to remove usage of Parse entirely.

[drdaz]

To avoid this, we would have to remove Parse from our public interface

Why would you need to have Parse in your public interface?

I'm not sure what you're up to, but you might want to look at a facade or something similar to expose the relevant Parse functionality to your consumers. It might not be fun, but it's probably the right way; your library is Parse's consumer, not your user's app.

[JoeSzymanski]

We have multiple modules and currently expose Parse backed objects. The interface is generally between the modules, rather than directly to the host apps (though the general idea of that particular module is that a host app could generate a new UI on top of the data provided by that module).

That being said, I am looking into the feasibility of removing all references to Parse from the public interface of that module.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide

[JoeSzymanski]

This is still an issue if Parse ever wants to support XCFramework, which may be an issues with M1 support. We have worked around it for our own issues, but I'm not sure if there's still a more general issue here.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide

[mtrezza]

Parse iOS SDK supports xcframeworks via carthage, it builds successfully, except for the ParseFacebookUtils, which require some dynamic Parse dependency.

[mtrezza]

Closing as release 2.0.0 supports import via Swift Package Manager.

[yasirmturk]

Hi @mtrezza I need ParseFacebookUtils.xcframework I am unable to compile it from carthage or the build script