🐛 MacCatalyst Does not Build on RN above 64 because of RCT-Folly (1/2 Fix Included Here!)

[ZComwiz]

🐛 Bug Report

FLIPPER FOLLY MAC CATALYST SUPPORT BROKE AFTER SWITCHING TO XCFRAMEWORK. HERE IS WHAT HAPPENED:
There are two bugs when building RN 65+ targeted to MacCatalyst located in Flipper:

1. Time.h redefinition. There is a hack in here in Time.h in RCT which I was able to consistently fix by adding a TARGET_OS_MACCATALYST flag on line 31. See my comment on the quick, robust, fix here.

2. DoubleConversion Not Found when building:
When Flipper/Folly switched to xcFrameworks from the precompiled .a file, it seems they did not include a slice for MacCatalyst. I will include some helpful references here which the team at Flipper who is more familiar with the archiving process of the xcframework can use to quickly rectify this support regression:

a) Mike Hardy's awesome script which may help compile the DoubleConversion Library properly

b) A simple guide to building MacCatalyst slices when using an xcFrameworks

To Reproduce

Try building any react-native on any version 65 or greater with Mac as the target destination (MacCatalyst). You can do that by selecting iPad, then Mac in the General settings of the template HelloWorld Xcode Project. Switch Build Target to Mac at the top.

Recommend using the template in this branch of a release candidate of 67 which adds some robust fixes that will be integrated soon (but you can try on the latest RN 66 build).

Environment

Intel and M1 Macs alike: targeting MacCatalsyt. XCode Version 13.0 (13A233). Any version of React Native above 64, but you can use 66 or the release candidate mention above.

[mikehardy]

Wow, that took a while to find.
It's here and needs attention from @priteshrnandgaonkar

https://github.com/priteshrnandgaonkar/double-conversion/blob/master/archive-xcframework.sh

Pritesh, you need to include a macCatalyst slice, easy to build but needs a very very careful re-arrangement of built artifacts after build, before packaging:

# Do not be tempted to use "-sdk macosx" instead of the "destination" argument. It switches you to AppKit from UIKit
# https://developer.apple.com/forums/thread/120542?answerId=374124022#374124022
echo "Archiving for Mac Catalyst"
xcodebuild archive -workspace "./${FRAMEWORK_NAME}.xcworkspace" -scheme ${BUILD_SCHEME} -configuration Release \
  -destination='platform=macOS,arch=x86_64,variant=Mac Catalyst' -archivePath "${CATALYST_ARCHIVE_PATH}" \
  SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES | xcpretty -k

echo "Packaging archives into ${FRAMEWORK_NAME}.xcframework bundle"
xcodebuild -create-xcframework \
  -framework "${SIMULATOR_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework" \
  -framework "${IOS_DEVICE_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework" \
  -framework "${CATALYST_ARCHIVE_PATH}/Products/Library/Frameworks/${FRAMEWORK_NAME}.framework" \
  -output "${FRAMEWORK_PATH}" | xcpretty


# Catalyst framework directory structure flattening step 1:
# - Copy the framework in a specific way: de-referencing symbolic links on purpose
echo "Installing framework into packages/react-native submodule"
rm -rf "${OUTPUT_FOLDER}/${FRAMEWORK_NAME}.xcframework" && \
  cp -rp "${FRAMEWORK_PATH}" "${OUTPUT_FOLDER}"

# Catalyst framework directory structure flattening step 2:
# - Remove the catalyst framework "Versions" directory structure after symbolic link de-reference
rm -rf "${OUTPUT_FOLDER}/${FRAMEWORK_NAME}.xcframework/ios-arm64_x86_64-maccatalyst/${FRAMEWORK_NAME}.framework/Versions"

[lblasa]

@mikehardy thanks for reporting this and finding the problem. I will provide a fix and update once ready.

[mikehardy]

Fantastic! As someone that does not generally like workarounds (I love to PR upstream and just fix things...) I was surprised by the need to do that catalyst slice repack but please understand I tested that super carefully back and forth and that strategy was the only way I successfully built for catalyst in a published pod, painful reference:
invertase/notifee#55
invertase/react-native-notifee#162 (comment)

(that was from when Notifee was proprietary, thus this was needed, it's open source now but this was so hard to figure out...)

[ZComwiz]

@mikehardy I am so glad we got this the attention it needs! I am giving you a virtual high five 🙌

[mikehardy]

In classic "hey, while you're in there..." fashion I'll mention that the tvOS and watchOS folks will be after you next. I had work in that area but didn't have time to merge it in Notifee. The natural extensions on the pbxproj and build framework script did work as expected though, I had a valid xcframework with it

https://github.com/invertase/notifee/pull/56/files#diff-5bdb27f5710cdebde3c248e0e983ee16d5e5c1173cfe0cc8b31011f56505d5f1
https://github.com/invertase/notifee/pull/56/files#diff-0dc5ff7bb16a87c5622e00d8564b828cf33258c54005107f0916460b7e3ae601

It's still on my todo list to actually make a github repo and blog about this so anyone doing xcframeworks just has a script that works and we can all maintain just one...

[ZComwiz]

@lblasa — do you have any progress update on this?

[Arkkeeper]

It seems that the problem is deeper than just 2 fixes. I've forked Flipper-DoubleConversion repo and patched xcframework creation script (https://github.com/Arkkeeper/double-conversion). I've also modified react-native/scripts/react_native_pods.rb in order to fetch Flipper-DoubleConversion from that fork, so now it includes a necessary slice for Mac Catalyst. But that's not enough for successful builds. Now I keep getting errors during linking stage about duplicate symbols between Flipper-Folly and RCT-Folly. We need a hint on how this duplication is being avoided when building for iOS or iOS Simulator.

[exotexot]

Ah I was sort of hoping that this issue was fixed with the 0.67 release. So it still persists? :/
Hm, then my euphoria for 0.67 is fading :(

[Arkkeeper]

Nope, I was too pessimistic :) Everything seems to be ok after fixing Flipper-DoubleConversion slices.

"Duplicate symbols" error is caused by absence of DEAD_CODE_STRIPPING = YES in project.pbxproj, it was discussed here facebook/react-native#32333 (comment), but there is no necessary fix in RN 0.67.
After adding DEAD_CODE_STRIPPING = YES my app compiles successfully.

But... the happy end is still far, because Flipper still can't connect to Catalyst app and debug it. First I thought that it's related to idb, but that's not true.

[mikehardy]

Hey @Arkkeeper - I don't see a PR for your maccatalyst xcframework fix - you should PR that! It looked good to me. I had to flatten the slice from it's structure when I did the same for Notifee but there is nothing like proof, and if you have it definitely working then you should PR and get those slices published for next release hopefully

[Arkkeeper]

Our team is doing some additional research now, if everything is ok, I'll certainly publish that patch as a PR tomorrow.