[Discussion] XCFrameworks Support

[Lcsmarcal]

Hey peeps.
Last week I was taking a look at support XCFramework on Buck, for both build and project commands.

XCFrameworks is a new bundle type that contains a framework per platform, so you can have a framework for iPhoneOS, WatchOS, MacOS, and their respective simulators in the same XCFramework bundle. And now XCFramework is becoming the main way to distribute binaries.
In the last version of the Xcode when using the old framework bundle you already get this kind of error:

Building for iOS Simulator, but the linked and embedded framework 'FirebaseCore.framework' was built for iOS + iOS Simulator.

So I needed to take a look at how Buck can support this new framework bundle. And I came to this solution (#2593), which I'm not very happy with and it's still a kinda "hacky" solution.

It's working both for Buck and Xcode, but here are the topics that I'm not very comfortable with that solution:

• don't know if the PrebuildAppleFramework.java is the right place to do this kind of logic.
• PrebuiltAppleFramework does not have the CxxPlatform set on the buildTarget property which is used to search for the right framework path inside the XCFramework bundle. So I needed to write this workaround and it's only working because, luckily, the getTransitiveCxxPreprocessorInput function is called before the getSourcePathToOutput.
• If it's the right decision to extend the PrebuiltAppleFramework rule instead of creating a new one like PrebuiltAppleXCFramework. I had chosen following with the existing one because creating a new one led me to create a lot of code duplication on the project generation step because XCFrameworks and Frameworks are treated the same on Xcode.

[Lcsmarcal]

cc @milend @rajyengi

[narlei]

+1

[rafabertholdo]

any news related into merging this? Apple is not selling x64 macs anymore, people who use carthage to build their frameworks depends on xcframework.