fix: build xcframeworks to fix linking issue in Playground App

[okwasniewski]

Describe the change

This PR fixes RNTA linking issues for newer versions of CMake, this PR is still a draft as I needed to patch-package the react-native-test-app. I need to make sure this is the correct solution to solve this issue and contribute the fix back to RNTA.

Screenshots

If applicable, add screenshots to help explain your change. Consider using tools like Giphy Capture or ScreenToGif to capture animated gifs. If you are using physical devices rather than emulators/simulators, consider using tools like Vysor or scrcpy to project your device's display to your dev machine to allow for screen capture.

Documentation

Have you updated the documentation to reflect your changes? (Yes or N/A)

Testing

Have you tested the final iteration of your changes? (Yes or N/A or I need help testing on [Android|iOS|Windows])

[okwasniewski]

Hey, I've opened a PR to RNTA to add support for this feature: microsoft/react-native-test-app#2204

[CedricGuillemet]

I'm working on fixing the build so we can continue testing this PR. #657

[CedricGuillemet]

@okwasniewski I just merged the build fix PR. You should be able to update your PR and kick a new build. I'll check its progress

[okwasniewski]

I'm still encountering some issues with react-native-permissions when launching the app. Im going to go back to this tomorrow, so let's wait with merging 🙏 (At least the app is now properly built)

[okwasniewski]

Okay, so I got this to work on the simulator, there was an issue with react-native-permssions caused by peer dependency resolution but it should be fine now.

The only thing left is that the Playground is still not building properly for real device (same issue as before). Going to focus on this one now.

[okwasniewski]

Hey @CedricGuillemet @ryantrem

I've made it work with xcframeworks.

So here #658, I've mentioned building a single .xcframework to fix the issue, but unfortunately, this wasn't a viable option.

I wanted to merge all of the static libs that Babylon currently builds into one and then build an xcframework for each platform and architecture, but there were bunch of linking issues resulting from the merge.

So I decided to create multiple XCFrameworks for all of our static libraries.

I've integrated it into gulpfile.js and run it on postinstall of RNTA. (This can be further expanded to build on the CI, but for the sake of keeping things simple in the first iteration I created a local script).

So now when you run npm install we build all of the xcframeworks and link them to RNTA using vendored_frameworks.

So currently, we build for ios-arm64, ios-simulator-arm64 (M1 mac) and ios-simulator-x86 (Intel mac).

This can be easily expanded for other platforms like macOS and visionOS later.

It would be great if you could test out the script locally and let me know what you think.

"Build from source" stays as an option but only for CMake < 3.24 (as stated in README)

[okwasniewski]

Also to address any performance concerns, dynamic linking of xcframeworks add some overhead to the app startup, but for frameworks that only ship static .a libraries (our case) Cocoapods just copy the proper slice from the framework.

There is an additional build script being executed "[CP] Copy XCFrameworks" that copies proper static libraries for current build and only they end up in app binary

[okwasniewski]

Hey @ryantrem @CedricGuillemet @bghgary

I wanted to check in and ask if you are okay with this approach?

The build is still failing but I want to ensure I'm on the right track before I spend time fixing it.

I think that we need to build the XCFrameworks only when BabylonNative version is updated. This should significantly speed up the CI builds

[CedricGuillemet]

This looks fine to me. So, building the xcrframework means doing the same thing as createXCFrameworks function when a new BN PR is merged? And then publishing it to cocoapods?

[okwasniewski]

This looks fine to me. So, building the xcrframework means doing the same thing as createXCFrameworks function when a new BN PR is merged? And then publishing it to cocoapods?

We can call createXCFrameworks on the CI to cache it / upload it as an artifact. We don't need to re-run this every PR because it only builds BabylonNative so we can cache it until BabylonNative version is bumped.

When it comes to building locally, you can run the createXCFrameworks once and have it cached to speed up the builds. (I've been working on #659 like this).

Regarding publishing @babylonjs/react-native package, we can ship xcframeworks as is to NPM (same as .a binaries were shipped before) or publish it to cocoapods but I don't think there is a big difference there. Shipping to NPM is easier

However, I didn't plan to change the publish scripts in this PR as my goal is to get RNTA working, and publishing can be addressed in upcoming PRs

[okwasniewski]

Hey, @ryantrem @CedricGuillemet I've stripped almost everything from the PR except build and linking of XCFrameworks.

Let me provide a bit more detail of what is actually happening in createXCFrameworks function:

1. We map over platforms and create static libraries (.a) for each platform

const buildCommand = `xcodebuild -sdk ${platform} -arch ${arch} -configuration Release -project ReactNativeBabylon.xcodeproj -scheme BabylonNative build CODE_SIGNING_ALLOWED=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES`;

2. Once we have all static libraries we merge multi-architecture ones (iphonesimulator-arm64 and iphonesimulator-x86) This allows users to use both Intel and Apple Sillicon Macs
3. We iterate over merged build outputs and create XCFrameworks for each one of our libraries so we get (libastc-encoder.xcframework, libBabylonNative.xcframework, libbgfx.xcframework etc.)
4. Copy xcframeworks to @babylonjs/react-native-iosandroid/ios/libs/
5. Link xcframeworks using vendored_frameworks in Podfile

[okwasniewski]

Hey @ryantrem @CedricGuillemet @bghgary

I've applied the changes we talked about yesterday. Let me know if I should address something else

[ryantrem]

Looks good to me!