🐛 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.

[ZComwiz]

@priteshrnandgaonkar — looks like @Arkkeeper made a PR :)

@mikehardy —what would be the next step(s) to see that added into RN 0.67.2? Can we make a fast patch release of RN that includes this fix?

[mikehardy]

If I understand correctly

First everything needs to be merged on main branches and working fir flipper

Then flipper does a release and you test with a local change to use that version and that should be enough to unblock

Then react native gets a PR to bump flipper version

Then you use the commitly release from that react native merge, then it's in the next react native version

I think since you can specify flipper version it doesn't need to wait for a react native release

[ZComwiz]

@mikehardy, it looks like @priteshrnandgaonkar is MIA. As the most central member to the RN community, do you want to host a new Flipper Double Conversion that incorporates @Arkkeeper's changes and offer a PR to the Flipper project itself? Let's not sleep on this now that it appears fixed.

[kelset]

Can anyone give me a quick overview of the status of the open PRs/fixes to solve this? I feel a bit lost atm. Are the PRs to get this address open/merged or some things still need to be worked on?

[mikehardy]

@kelset this is really thorny unfortunately.

The proposed solution just above of me forking + publishing a new Flipper-DoubleConversion (and Flipper-Glog) based on @priteshrnandgaonkar work but including the work here to add maccatalyst slices to the vendored xcframework is a bad idea.

Using more precise technical language: it would be spending dev time on a compile-time optimization that was made in the form of a 3rd-party personal fork of a major library by making another 3rd-party personal fork of the major library and having this major project then switch dependency from one personal fork to another. That's a bad idea right?

Here's the technical analysis of where we are

So React Native needs Flipper, and Flipper needs the Flipper-DoubleConversion library. It pulls it in here:

flipper/iOS/Podspecs/Flipper-Folly.podspec

Line 18 in fbd3212

spec.dependency 'Flipper-DoubleConversion'

which is just a reference to a specific version of a specific pod that is out-of-tree and live on cocoapods.org and happens to be named "Flipper-Something" but is not actually controlled by facebook/meta or this repo:
https://cocoapods.org/pods/Flipper-DoubleConversion

Which is/was just a one-time publish of a personal repo from @priteshrnandgaonkar :
https://github.com/CocoaPods/Specs/blob/master/Specs/3/3/c/Flipper-DoubleConversion/3.1.7/Flipper-DoubleConversion.podspec.json

That personal repo is a point in time / unupdated fork of the google/doubleconversion project, but with a pre-compiled xcframework included, you can see the work to do so in commit history
https://github.com/priteshrnandgaonkar/double-conversion/commits/v3.1.7

(note, Flipper-Glog is doing something similar, pointing directly here: https://github.com/CocoaPods/Specs/blob/master/Specs/2/7/2/Flipper-Glog/0.3.9/Flipper-Glog.podspec.json)

...which is named Flipper-Glog but is just a one-time publish of an unupdated fork from Pritesh that has a pre-compiled xcframework.

Here is quick list of pain points

So there are a few things going on here:

• relying on these personal github repos that were one-time published to cocoapods seems like a bad practice
• the vendored frameworks are just a compile-time optimization (PR [iOS]Update glog and doubleconversion which uses xcframework #2153), this is best handled with a compiler cache, not pre-compile + artifact distribution infrastruction (trust me! I use ccache, maintain buildcache-action, and also maintain a pre-compile+artifact distribution thing at github.com/invertase/firestore-ios-sdk-frameworks - compile cache beats pre-compile + distribution
• the vendored xcframeworks build a very incomplete set of the slices necessary for crossplatform dev, they do "ios" and "ios simulator", but no maccatalyst, no tvos etc etc https://github.com/priteshrnandgaonkar/double-conversion/blob/v3.1.7/archive-xcframework.sh - and this stuff is hard, as I mention above 🐛 MacCatalyst Does not Build on RN above 64 because of RCT-Folly (1/2 Fix Included Here!) #3117 (comment)
• the repos themselves are now static, they've missed a year of releases from the upstream doubleconversion and glog projects, plus whatever infra updates were needed here with regard to building external libraries as Flipper-NNNN pods (like rsocket and fmt and boost etc do)

here's what I think needs to happen

1- the compile optimizations introduced in #2153 by including pre-compiled DoubleConversion and Glog should be reverted and the local build/podspec stuff here related to those two libraries needs to be brought up to date with the whatever the local peer pods from 3rd party native libraries are doing so it's in tune again

That may be enough to solve this issue by itself now, Maccatalyst will likely work at that point

Someone needs to do this, I do not have time. Clone Flipper repo, look at what #2153 changed, manually revert the change so doubleconversion and glog are built again (using the same versions/tags in use now though) and see if Flipper works. PR that. Do a follow-on PR that brings them up to current versions if possible. See if maccatalyst builds for react-native if you depend on that new local flipper, should work?

2- if speed optimizations are desired, in CI here the workflows should enable and use ccache-action (react-native-firebase does this to good effect, as do all my work projects)

3- an audit should be made of dependencies that are spidering out to Pritesh's personal repos, and they should be internalized. A firm policy should be made to never do that again as it makes maintaining the web of dependencies here and moving the project forward impossible when dependencies spider out to personal repos with single maintainers

There quite a few at the moment - it's a bit of a rabbit hole but not quite the abyss yet:

mike@osxvm:~/work/react-random/flipper (main) % grep -r priteshrnandgaonkar *
android/third-party/native.gradle:    src 'https://github.com/priteshrnandgaonkar/rsocket-cpp/archive/0.10.7.tar.gz'
iOS/Podspecs/Flipper-Boost-iOSX.podspec:    s.homepage     = "https://github.com/priteshrnandgaonkar/boost-iosx"
iOS/Podspecs/Flipper-Boost-iOSX.podspec:    s.source       = { :git => "https://github.com/priteshrnandgaonkar/Flipper-Boost-iOSX.git", :tag => "1.76.0.1.11" }
iOS/Podspecs/Flipper-Fmt.podspec:    spec.source   = { :git => "https://github.com/priteshrnandgaonkar/fmt.git",
iOS/Podspecs/Flipper-PeerTalk.podspec:    spec.source   = { :git => "https://github.com/priteshrnandgaonkar/peertalk.git",

[lblasa]

Sorry for the late reply, I will be looking into this very shortly and hopefully will have an update soon.

[lblasa]

First of all, thanks everybody for the discussion!

I've just released new versions of Double-Conversion and Glog which catch up with the upstream repositories and contain slices for Mac Catalyst.
https://cocoapods.org/pods/Flipper-Glog
https://cocoapods.org/pods/Flipper-DoubleConversion

I'm now the owner of all Flipper-* pods so I should be able to make any necessary updates and adjustments in the future.

Unfortunately, right now, I don't have the capacity to make our dependency consumption better. Having said that, valid points were said and we will definitely look into making things better in future releases.

[mikehardy]

I am all for incremental progress :-), changing dependency consumption is not the easiest, no, but at least now we're all aware. Having the catalyst slice in the new pods will be great - it appears to me that the Flipper-Glog and Flipper-DoubleConversion pods are both specified inside Flipper-Folly without version constraints, so simply by publishing them, catalyst builds may start working for people if they pod update --repo-update ? Just a guess - I need to test, but people may be unblocked right now, by that publish action on cocoapods...

Edited: just tested, I see the new pods but pod update does not access them and rm -f Podfile.lock && pod install does not either, so the versions are pinned somewhere.

So if my tests are valid and I understand correctly, I think there will need to be a Flipper release process in order to ingest this work before catalyst will work for people.

pod outdated output after attempting tests - new pods visible, but they are pinned

- Flipper 0.125.0 -> 0.125.0 (latest version 0.135.0)
- Flipper-DoubleConversion 3.1.7 -> 3.1.7 (latest version 3.2.0)
- Flipper-Glog 0.3.9 -> 0.3.9 (latest version 0.5.0.3)

[ZComwiz]

@mikehardy @lblasa @kelset — hey all. We are so close on this issue. Let's not drop the ball on it now.

[lblasa]

I’ll check on this early next week, sorry about the delay!

[lblasa]

I found we had pinned some versions in our ReactNativeExample and this was fixed here:
017bb77

After the change, I had a look at what versions were being pulled for our iOS Sample and ReactNativeExample and they all seem to point to the right versions.

[mikehardy]

Ah ha

The difference is that your use_flipper line in flipper's react-native example is specifying versions. So you were able to access them. Great that works!

So, for anyone suffering from this problem right now you may specify the same versions in that commit and you will have a working catalyst build.

However in the empty / default use_flipper! case where versions are not specified manually - used by majority of react-native users - this is not working. Why not? It took me a little bit, but I found the version pin!

https://github.com/facebook/react-native/blob/325be429fd33bd79234bb4c79523a0b476121645/scripts/react_native_pods.rb#L138-L146

Those versions need a change - @lblasa what versions should we put in there? Last person to do it was @cortinico in facebook/react-native#32923 and it appears we need to pick versions carefully. Should we just update the ones you touched?

Assuming answer is yes - update only the ones updated here - I've posted a PR that attempts to do it, we'll see how CI likes it...

facebook/react-native#33406

[mikehardy]

@Pajn I finally got a chance to try this on an M1 machine, I have it fully scripted and working on x86_64, but on M1 this morning, I got the same error you received. Are you on an M1 machine?

dyld[88732]: Library not loaded: @rpath/double-conversion.framework/Versions/A/double-conversion
  Referenced from: /Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-maccatalyst/rnfbdemo.app/Contents/MacOS/rnfbdemo
  Reason: tried: '/Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-maccatalyst/double-conversion.framework/Versions/A/double-conversion' (no such file), '/usr/lib/swift/double-conversion.framework/Versions/A/double-conversion' (no such file), '/Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-maccatalyst/rnfbdemo.app/Contents/MacOS/../Frameworks/double-conversion.framework/Versions/A/double-conversion' (no such file), '/Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-maccatalyst/rnfbdemo.app/Contents/MacOS/Frameworks/double-conversion.framework/Versions/A/double-conversion' (no such file), '/usr/lib/swift/double-conversion.framework/Versions/A/double-conversion' (no such file), '/Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-maccatalyst/rnfbdemo.app/Contents/MacOS/../Frameworks/double-conversion.framework/Versions/A/double-conversion' (no such file), '/Users/mike/Library/Developer/Xcode/DerivedData/rnfbdemo-dwlryiowautyphccrrwxfbsrbwxk/Build/Products/Debug-maccatalyst/rnfbdemo.app/Contents/MacOS/Frameworks/double-conversion.framework/Versions/A/double-conversion' (no such file), '/System/Library/Frameworks/double-conversion.framework/Versions/A/double-conversion' (no such file)
(lldb) 

[Pajn]

@mikehardy yes, I am. Forgot to say that, sorry;

[mikehardy]

Okay - for anyone else following along, @Pajn and I have gotten to this point on an M1 machine for catalyst (it works for x86_64):

• the build works, but the app fails, unable to load the dylib for Flipper-DoubleConversion because it is in the root of the slice for the framework, not a Versions/A/ sub-directory. Why is this important for macCatalyst on M1 but not x86_64? No idea
• if you manually copy the double-conversion binary bit of the arm64 macCatalyst slice into Versions/A then you have a codesigning issue as mentioned above. Adding no dylib verification to my entitlements did not work. Using a post install Podfile hook to ad-hoc sign all targets (not just resources) did not seem to work?

And that is where I am stuck right now 🤷 - I hit the end of my timebox on this for a while so I may not be able to look again for some time.

macCatalyst +flipper works for x86_64, stuck on arm64 until someone can bust through the block here.

[cyberdude]

Do we have an update on this ?

[mikehardy]

@cyberdude Please read this and reflect: https://hackernoon.com/i-thought-i-understood-open-source-i-was-wrong-cf54999c097b

There are no secret updates, I can say that. Catalyst works great everywhere now except M1 mac, but you could be the person to move that forward based on comments above in this issue

[Arkkeeper]

@mikehardy Finally I've got some time for experiments. I've edited archive-xcframework.sh inside Flipper-Glog and Flipper-DoubleConversion in this manner:

And I can confirm that now everything is ok on my M1 Mac with Catalyst (even with the new architecture enabled on RN 0.68.1).

In order to try this on Intel Mac, one can patch node_modules/react-native/scripts/react_native_pods.rb and replace corresponding lines inside use_flipper! to:

pod 'Flipper-DoubleConversion', :git => 'https://github.com/Arkkeeper/double-conversion.git', :branch => 'flipper-v3.2.0', :configurations => configurations
pod 'Flipper-Glog', :git => 'https://github.com/Arkkeeper/glog.git', :branch => 'flipper-v0.5.0.1', :configurations => configurations

Then delete ios/Pods and ios/Podfile.lock and do pod install or RCT_NEW_ARCH_ENABLED=1 pod install.

[mikehardy]

@Arkkeeper excellent!
I think you could propose PRs to these two repositories as they are the source of published pods currently and then hopefully @lblasa could help integrate + release?

https://github.com/lblasa/double-conversion
https://github.com/lblasa/glog

[Arkkeeper]

I have tested new xcframework on Intel Mac by myself, it works as expected. My PRs are published to @lblasa forks.

[lblasa]

Hi @Arkkeeper thanks for the PRs and sorry about the late reply. I will be integrating these changes very soon and will push a new pod version for both dependencies :)

[lblasa]

Just a very quick follow-up. I've published new versions for both libraries based of @Arkkeeper PR's.

@Arkkeeper I think is good for a re-test. If it does work, then I believe we could close this long-standing issue.

[mikehardy]

Confirmed fixed! Oh my $deity!! Finally able to close this one I think. I'm PR'ing version bumps to react-native now. Fantastic!

[Arkkeeper]

I've also tested the new versions by setting
use_flipper!({'Flipper-DoubleConversion' => '3.2.0.1', 'Flipper-Glog' => '0.5.0.5'})
in Podfile, everything is ok, thanks!

There's one more bug with Flipper-Folly that prevents RN 0.68.x from being completely compatible with MacCatalyst, but it's another story.

[kelset]

There's one more bug with Flipper-Folly that prevents RN 0.68.x from being completely compatible with MacCatalyst, but it's another story.

just to ensure we won't forget about this: does an issue in a repo (either this one or the folly one or the rn one) track this separate issue?

[exotexot]

There's one more bug with Flipper-Folly that prevents RN 0.68.x from being completely compatible with MacCatalyst, but it's another story.

Could you please elaborate? I'm just about to update my RN app to the latest rn versions and I do need MacCatalyst support here. Which issues are still pending, preventing one to fully work, develop, build, and/or publish in App Store?

[Arkkeeper]

It was mentioned here realm/realm-js#4488 along with my temporary dirty fix.

Today I'm going to test it thoroughly on RN 0.69-rc1. If it persists, I'll publish details to the 0.69 discussion.

[mikehardy]

Very interesting @Arkkeeper - just deep linking the actual comment since I am here anyway and have it handy, appears to be based on some sort of SharedMutex divergence between FlipperFolly and RCT-Folly realm/realm-js#4488 (comment)

[Arkkeeper]

@mikehardy Fortunately, I can confirm that the mentioned issue isn't relevant for 0.69-rc1 because of newer versions of RCT-Folly and Flipper-Folly. As for now, everything seems ok. I've got this on 0.69-rc1 too 😞

Anyway, I'm going to PR some fixes for 0.69, so it would work with MacCatalyst out of the box.

[mikehardy]

I think the cocoapods version updates are already in process for cherry-picking to 0.69, if that's what you mean but if it's something else, you'll obviously know better :-)

Here's what I see in the pick list for 0.69.0-rc.2, the first one is the pod version bump commit

Picks for 0.69.0-rc.2
https://github.com/facebook/react-native/commit/d493f45bd9e39de5f60fa2ee20e229afe5a64159

Bump Hermes (https://github.com/facebook/hermes/commit/5244f819b2f3949ca94a3a1bf75d54a8ed59d94a)

[Arkkeeper]

Could you please elaborate? I'm just about to update my RN app to the latest rn versions and I do need MacCatalyst support here. Which issues are still pending, preventing one to fully work, develop, build, and/or publish in App Store?

I've described the details here reactwg/react-native-releases#21 (comment)

@kelset two issues about Flipper-Folly in Release scheme already exist facebook/react-native#33764, facebook/react-native#33753, they are duplicates

I'm sorry to say that I've got this errors even on RN 0.69-rc1, trying the fresh new project.