Support .xcframework dependency type

[kwridan]

Is your feature request related to a problem? Please describe.

.xcframeworks are the new binary frameworks supported by Xcode 11.

Describe the solution you'd like

A few options:

1. Add a new .xcframework dependency type

e.g.

    Target(
            name: "App",
            platform: .iOS,
            product: .app,
            bundleId: "io.tuist.App",
            infoPlist: "Config/App-Info.plist",
            sources: "Sources/**",
            dependencies: [
                .project(target: "Framework1", path: "../Framework1"),
                .xcframework(path: "Frameworks/MyFramework.xcframework")
            ]
        )

2. Enhance the existing .framework type

The existing .framework dependency type could be enhanced to to detect the framework extension and apply the appropriate rules (e.g. if it's an .xcframework, simply include it in the appropriate phases without needing to call tuist embed for it)

Additional context

Starting an issue for us to collect what's needed to support this feature. This will help us decide on which option to pursue.

Status

• Support xcframework dependency type #757: Add XCFrameworkNode
• Introduce a xcframework dependency type #769: Introduce XCFramework dependency (for dynamic XCFrameworks)
• Support xcframework containing static libs #821: Add support for static XCFrameworks

[pepicrft]

Like the suggested approach @kwridan. So .xcframeworks don't need to be embedded?

[kwridan]

Still figuring out the details - from my limited testing, looks like Xcode will take care of the embed for you provided it's in the correct build phase (i.e. we wouldn't need to call tuist embed to manually copy / sign frameworks - like we need to for the ones built by Carthage)

[pepicrft]

Awesome! That simplifies the things a bit.

[lakpa]

I am running a thought as if taking @kwridan first approach would be better as xcframework has new Bundle OS Type code which is XFWK and representing it with its new dependency type appears suitable enough to avoid messing with existing framework dependency type. Besides its configuration info.plist is different than static/dynamic framework types which as follows

Any feedback @kwridan @pepibumur?

[pepicrft]

I am running a thought as if taking @kwridan first approach would be better as xcframework has new Bundle OS Type code which is XFWK and representing it with its new dependency type appears suitable enough to avoid messing with existing framework dependency type.

Agree. I'd define a new dependency type instead of messing the existing .framework.

[lakpa]

@kwridan can we close this?

[kwridan]

Indeed we can, thanks for all your hard work on this @lakpa 👍