Apple silicon support

[hsavit1]

Introduction

Will react native be supported by apple silicon?

Details

• Homebrew and cocoapods have some known issues on apple silicon
• Flipper does not currently work

Discussion points

1. will apps run properly on apple silicon machines?
2. will I be able to build my react native app?

UPDATE there may be some hiccups with getting cocoapods working, but overall seems to work well, as either a catalyst app or a iOS / android simulator app. Flipper does not seem to work, currently

UPDATE 2 Flipper version 75.1 mostly seems to fix M1 builds. see this comment https://stackoverflow.com/a/66071245/11721286

[gwmccull]

The M1 is in the same class of processors as the A-series chips used in iPhones and iPads so I don't think it should be a problem. They already said the M1 computers will be able to run all iPhone apps natively

[hsavit1]

how about building react native projects on apple silicon machines?

[gwmccull]

I don't have access to one of the new machines so I haven't tried but Xcode works on them so you'd think it'd work. At worst, you might have to run an older version of Xcode in emulated mode

edit: I just saw in the Infinite Red slack channel that someone tried it and Xcode was not working for them. Sounds like a possible issue with Xcode itself though so maybe not an issue w/ RN

[kelset]

I think it's quite too early to discuss this - let's wait until the laptops have been out for at least a few weeks before trying to figure out what is going to be needed to work. As @gwmccull points out correctly, it's most likely that first Android Studio and Xcode will have to properly work and then we can investigate if there are going to be React Native specific issues.

[billycastelli]

Using Rosetta, I was able to install Homebrew and the necessary requirements to set up a working React Native environment according to the setup guide: https://reactnative.dev/docs/environment-setup.

On my first attempt, I was receiving this error:

checking whether the C compiler works... no
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'Path' in SDK 'iphoneos'
/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing: Unknown `--is-lightweight' option
Try `/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
configure: error: in `/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6':
configure: error: C compiler cannot create executables
See `config.log' for more details

I fixed this error by opening Xcode > Preferences > Locations and selecting Xcode 12.2 from the Command Line Tools dropdown.

After selecting this, I was able to go through the install and build process smoothly.

Note: According to the activity monitor, Node and Watchman are using the Intel architecture (x86 through Rosetta)

while the iOS simulator is using Apple's ARM architecture (and running very smoothly).

Hope this helps!

[diegolmello]

I wonder if whole Android stuff (build, emulator, etc) works properly as well.

[darrylyoung]

Thanks for sharing, @billycastelli. That's helpful. 👍

[terrysahaidak]

Seems like not everything is going well: https://twitter.com/ericlewis/status/1329420283288096770

[ericlewis]

There is a lot of workarounds involved with getting this to even remotely run, I attempted to build the RNTester app & was running into problems repeatedly. I will try to help, but it is unlikely I have the time.

[gwmccull]

I've gotten that ffi error on Catalina as well. I had to gem install pristine ffi (or something like that) to fix

[phatlaunchdeck]

Hey guys, thanks for opening up the discussion about this matter, I actually received an email from Apple notifying me about my app using Core Location and it might not work well since Mac does not have it. Any idea how to fix/adjust this? Thanks!

[hsavit1]

Update here - I have been able to successfully use react native on my M1, additionally have had few problems with using the catalyst simulator, I think if you follow the steps with cocoapods you should generally be ok

[darrylyoung]

I can confirm that I'm also working with React Native on an M1 Mac and, to be honest, things are going way better than I thought they would. I installed CocoaPods using sudo gem install cocoapods and haven't had any issues there.

Not that it's directly related to React Native but I duplicated iTerm, called one iTerm x86 and set that to run with Rosetta. For Homebrew, managing all dependencies, and for the Metro bundler that's what's used and it's been just fine. It's all very fast, too, and I came from a 16" i9 MacBook Pro.

[RETFU]

Hey @darrylyoung do you have a quick benchmark for compilation time on iOS on your previous mac vs M1 ?

[jamesloper]

I've been developing on Apple Silicon for a few days now and it's not bad. In fact the performance of the cli apps is the least of the concerns. What's different is that doing any pod work requires you to enter a Rosetta 2 shell with arch -x86_64 /bin/zsh (a dependency called ffi which is a gem has not been updated yet, possible a host of other packages too) and then everything works smoothly. I can even run expo, using expo start ios and it will open the simulator albeit with the ironic twist that the app process is Intel. To get around this, I tried exporting the IPA file with Archive from Xcode and opening it with Apple's brand new feature of running iOS apps within MacOS. Surprisingly it freaking works out of the box, of course no hot reloading capability though as it has production flags. I also had to exclude arm64 to get some of my code to compile.

Of course the full arm64 suite is a ways away but if we could just do a build of a development IPA file with hot-reloads and open it up it directly in MacOS it would really close the loop on the Apple Silicon transition from a practical viewpoint.

[AdamGerthel]

I've gotten in up and running without the need to use Rosetta at all. The only caveat is that I can't use Flipper (yet). My setup is available here: https://github.com/facebook/react-native/issues/29984#issuecomment-743746829

@RETFU no benchmarks yet, but it's fast.

[darrylyoung]

Hey @darrylyoung do you have a quick benchmark for compilation time on iOS on your previous mac vs M1 ?

Hi, @RETFU. Unfortunately not, no. I sold my 16" Pro when I got the M1 Air so didn't have chance to do side-by-side testing but after working on the 16" all year, I can say that the Air feels fast. Really fast. It obviously doesn't have the same 32 GB RAM as the 16" Pro but I haven't run into any issues yet doing daily development work. The best thing of all is how the Air clearly outperforms the 16" Pro but manages to do it completely silently and while barely warm to the touch, even when under the highest loads. It's impressive and I'm glad I'm able to continue working on my React Native project on this as there's no going back now.

[andreialecu]

Regarding compilation times on the M1:

I used to have a 2017 MacBook Pro with an i7 CPU and 16GB of RAM. I replaced it with an 8GB Mac Mini M1 because that was the only one in stock, but I will be replacing it with the 16GB model as soon as it is available.

The compilation times, using fastlane to produce a binary ready for upload to the App Store were as follows:

• 781 seconds on the 2017 Macbook Pro
• 145 seconds on the Mac Mini M1 (!)

(this includes both compiling via xcode and producing the js bundle)

I'm running nodejs 15.3.0 compiled to arm64. With nodejs 14 and xcode running via rosetta2 the compilation time was 225 seconds, so still extremely good.

Additionally, my main work PC was a Desktop i7 7700k@4.7GHz with 32GB of RAM and an M.2 SSD (running Windows) and I benchmarked compiling the same Angular app in production mode on it vs the M1.

• 7700k: 65 seconds
• M1: 40 seconds (!)

So, switched to the M1 full time.

Even with just 8GB of RAM it still outperforms the Desktop i7 by a huge margin which I didn't expect.

The SSD on the M1 is fast enough so that swapping is instant so the fact it has just 8GB of RAM isn't a huge deal breaker. I will still be upgrading to 16GB just because Chrome is super memory hungry and I noticed that having a ton of tabs open does degrade performance a tiny bit, so I need to be more mindful about that.

[raienko]

I hope you'll find better way.. But this one worked for me:

Environment: macOS Big Sur 11.1 xcode 12.3 xcode -> preferences -> locations -> command line tools 12.3 "react-native": "^0.63.4"

Issues and fixes:

1. Homebrew installation fails Fix in 2 steps: /bin/bash -c "$(curl -fsSL https://gist.githubusercontent.com/nrubin29/bea5aa83e8dfa91370fe83b62dad6dfa/raw/48f48f7fef21abb308e129a80b3214c2538fc611/homebrew_m1.sh)

source .zshrc

2. /Library/Ruby/Gems/2.6.0/gems/ffi-1... Fix: sudo arch -x86_64 gem install ffi

3. Pods installation still fails with arm64 related errors Fix: arch -x86_64 pod install

4. Pods installed but build fails. Errors related to "arm64" or "C libs" Fix: Applications -> xcode -> get info -> Open using rosetta

[asterisx]

Regarding compilation times on the M1:

I used to have a 2017 MacBook Pro with an i7 CPU and 16GB of RAM. I replaced it with an 8GB Mac Mini M1 because that was the only one in stock, but I will be replacing it with the 16GB model as soon as it is available.

The compilation times, using fastlane to produce a binary ready for upload to the App Store were as follows:

• 781 seconds on the 2017 Macbook Pro
• 145 seconds on the Mac Mini M1 (!)

(this includes both compiling via xcode and producing the js bundle)

I'm running nodejs 15.3.0 compiled to arm64. With nodejs 14 and xcode running via rosetta2 the compilation time was 225 seconds, so still extremely good.

Additionally, my main work PC was a Desktop i7 7700k@4.7GHz with 32GB of RAM and an M.2 SSD (running Windows) and I benchmarked compiling the same Angular app in production mode on it vs the M1.

• 7700k: 65 seconds
• M1: 40 seconds (!)

So, switched to the M1 full time.

Even with just 8GB of RAM it still outperforms the Desktop i7 by a huge margin which I didn't expect.

The SSD on the M1 is fast enough so that swapping is instant so the fact it has just 8GB of RAM isn't a huge deal breaker. I will still be upgrading to 16GB just because Chrome is super memory hungry and I noticed that having a ton of tabs open does degrade performance a tiny bit, so I need to be more mindful about that.

Does using external monitors affect memory usage? I would be using 2 4k monitors with the 8gb ram and I am quite worried between webstorm, one simulator, couple of tabs in safari I might slow down the M1 Mac mini.

[andreialecu]

Does using external monitors affect memory usage? I would be using 2 4k monitors with the 8gb ram and I am quite worried between webstorm, one simulator, couple of tabs in safari I might slow down the M1 Mac mini.

I'm also using 2 4k monitors. I don't have anything to compare it with, but I don't notice any glaring issues.

I usually have a simulator and couple of VSCode windows open, and probably 10-20 Chrome tabs open. Like mentioned previously, it seems like the biggest memory hog is the web browser, and I definitely need to manage my tabs better vs my previous i7 with 32GB of RAM.

So I'll definitely be looking to upgrade to the 16GB model. However, besides the occasional 1-2 second mini stutters while it is swapping it's not a huge problem. I didn't run into any complete blockers because of the limited ram.

Here's how the memory tab in Activity monitor looks like with:

• 3 x VSCode on three big monorepos
• 3 x nodejs apps running (react native, angular, nestjs)
• Chrome with 16 tabs + 1 DevTools window open
• MongoDB Compass
• Microsoft Outlook
• Microsoft Word
• Slack
• Discord

A bit extreme on the swap usage, but hardly any performance degradation.

[asterisx]

Does using external monitors affect memory usage? I would be using 2 4k monitors with the 8gb ram and I am quite worried between webstorm, one simulator, couple of tabs in safari I might slow down the M1 Mac mini.

I'm also using 2 4k monitors. I don't have anything to compare it with, but I don't notice any glaring issues.

I usually have a simulator and couple of VSCode windows open, and probably 10-20 Chrome tabs open. Like mentioned previously, it seems like the biggest memory hog is the web browser, and I definitely need to manage my tabs better vs my previous i7 with 32GB of RAM.

So I'll definitely be looking to upgrade to the 16GB model. However, besides the occasional 1-2 second mini stutters while it is swapping it's not a huge problem. I didn't run into any complete blockers because of the limited ram.

Here's how the memory tab in Activity monitor looks like with:

• 3 x VSCode on three big monorepos
• 3 x nodejs apps running (react native, angular, nestjs)
• Chrome with 16 tabs + 1 DevTools window open
• MongoDB Compass
• Microsoft Outlook
• Microsoft Word
• Slack
• Discord

A bit extreme on the swap usage, but hardly any performance degradation.

Ohh nice. Thanks mate for the ram usage screenshot. Yeah the swap usage is high. There is a concern among people that this will trash the SSD but honestly for people like me who are heavy users and wish to keep the machine for 1-2 years it’s not that much of a problem. I am getting a really sick deal on a used m1 Mac mini 8gig version and I will just grab that one. If I were buying a new one though I would definitely buy the 16gigs version, just to make it last a bit longer.

[ecekoprucu]

I still have issues. After spending hours to make Cocoapods to work, now my build keeps failing with error code 65. I tried every solution suggested (Pod install, changing build settings, using Rosetta etc.) still no luck.

Any help is appreciated from anyone who experienced the same and managed to solve this issue.

[OKNoah]

I'm a little confused about whether people are saying they got things working natively or with Rosetta. Cause folks make it sound like they got things going arm64 style, but then. people are posting guides on how to just retreat to x86_64. So it's weird. Folks are also saying they can do just make a fresh React Native project and it works out of the box (minus Flipper). It seems like there's something I'm missing.

[andreialecu]

I'm definitely using arm64 end to end with real complex apps.

Based on my experience: I recommend compiling node 15 for arm (nvm install 15), and running via xcode instead of react-native run-ios. Also flipper won't work so it needs to be disabled in the pod file.

If you use vscode and the terminals inside it, make sure to use the insiders version that is compiled for arm64, otherwise the terminals will run under Rosetta.

[AdamGerthel]

Same for me. I'm running 100% silicon in my project. I'm using node v15 (which supports silicon). The only problem I had was installing pods, which failed because of a Flipper dependency. I removed it and got everything working.

[radko93]

I can also confirm that I'm running on Apple Silicon (without Flipper), also Android Emulator now works in the preview https://github.com/google/android-emulator-m1-preview/issues. I have another project with Firebase which is more problematic as there are some issues on that end.

[stanwolverine]

Hi @hsavit1 @gwmccull and everyone. I have got an opportunity as a react native developer. So, I have to purchase a macbook, Air with M1 chip would be best fit but I am worried about the problems with m1 chip. Will I be able to do react native development after fixing some known issues? I am on a tight budget and currently I don't have any machine for react native development. Please Help.

[OKNoah]

Hi @hsavit1 @gwmccull and everyone. I have got an opportunity as a react native developer. So, I have to purchase a macbook, Air with M1 chip would be best fit but I am worried about the problems with m1 chip. Will I be able to do react native development after fixing some known issues? I am on a tight budget and currently I don't have any machine for react native development. Please Help.

According to the developers of ffi, a part of cocoapods, no. Apple's Ruby is a universal binary that thinks it's always running in x86_64. I've tried using rbenv to change the version of Ruby, but it doesn't help.

However, yes, you can run it all in Rosetta. You just won't get the full speed benefits.

Then again, a number of people in this thread insist they have it running without Rosetta, which is a mystery to me. I'm going to read through them to try see what's up.

[OKNoah]

I'm definitely using arm64 end to end with real complex apps.

Based on my experience: I recommend compiling node 15 for arm (nvm install 15), and running via xcode instead of react-native run-ios. Also flipper won't work so it needs to be disabled in the pod file.

If you use vscode and the terminals inside it, make sure to use the insiders version that is compiled for arm64, otherwise the terminals will run under Rosetta.

How did you do pod install? What version of Ruby? Did you install ffi?

[andreialecu]

$ file `which ruby`      
/usr/bin/ruby: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/ruby (for architecture x86_64):        Mach-O 64-bit executable x86_64
/usr/bin/ruby (for architecture arm64e):        Mach-O 64-bit executable arm64e

$ ruby -v            
ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.arm64e-darwin20]

I remember issues about ffi, but forgot what I did about it. pod install simply works on my end:

➜ arch            
arm64

➜ pod install            
Auto-linking React Native modules for target `App`: BVLinearGradient, CountlyReactNative, RNBootSplash, RNCAsyncStorage, RNCClipboard, RNCMaskedView, RNDeviceInfo, RNFastImage, RNGestureHandler, RNLocalize, RNPermissions, RNReanimated, RNScreens, RNSentry, RNVectorIcons, ReactNativeAutogrowTextinput, react-native-config, react-native-geolocation-service, react-native-netinfo, react-native-safe-area-context, react-native-selectable-text, and react-native-webview
Analyzing dependencies
Downloading dependencies
Generating Pods project
Integrating client project
Pod installation complete! There are 51 dependencies from the Podfile and 55 total pods installed.

It's possible cocoapods might be running under Rosetta somehow, but I'm not sure how to check.

[andreialecu]

Hi @hsavit1 @gwmccull and everyone. I have got an opportunity as a react native developer. So, I have to purchase a macbook, Air with M1 chip would be best fit but I am worried about the problems with m1 chip. Will I be able to do react native development after fixing some known issues? I am on a tight budget and currently I don't have any machine for react native development. Please Help.

I haven't yet been able to run the Android Emulator FWIW, but I haven't checked lately on progress in that area. Last time I tried, it was starting, but RN apps would crash on startup (via https://github.com/google/android-emulator-m1-preview)

Note: Debugging on a real, connected, android device probably works, but I haven't tried that yet either.

[andreialecu]

@OKNoah Regarding the ffi issue, not sure if this is relevant:

$ file /Library/Ruby/Gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle 
/Library/Ruby/Gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [arm64e:Mach-O 64-bit bundle arm64e]
/Library/Ruby/Gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle (for architecture x86_64):    Mach-O 64-bit bundle x86_64
/Library/Ruby/Gems/2.6.0/gems/ffi-1.13.1/lib/ffi_c.bundle (for architecture arm64e):    Mach-O 64-bit bundle arm64e

Seems to have both architectures.

Edit: I may have used homebrew to build it from sources, see https://github.com/Homebrew/brew/issues/7857 (it's marked as supported in the list)

[OKNoah]

Edit: I may have used homebrew to build it from sources, see Homebrew/brew#7857 (it's marked as supported in the list)

Hmm, cocoapods is listed as "!" now with an ffi error as the comment.

[andreialecu]

https://github.com/ffi/ffi#requirements

You can probably install libffi manually and use the --enable-system-libffi flag. Unfortunately I don't remember what I did to fix this, but those flags look kind of familiar.

---

I just added

puts `arch`

To the top of my Podfile and it prints arm64. This confirms it's not running under Rosetta

[OKNoah]

https://github.com/ffi/ffi#requirements

You can probably install libffi manually and use the --enable-system-libffi flag. Unfortunately I don't remember what I did to fix this, but those flags look kind of familiar.

Yeah, I did that too. Unfortunately I suspect these things must be done in a certain order, and I've just got them littered all over the place so now even doing things right doesn't make a difference.

[scriptyvijay]

https://github.com/ffi/ffi#requirements

You can probably install libffi manually and use the --enable-system-libffi flag. Unfortunately I don't remember what I did to fix this, but those flags look kind of familiar.

I just added

puts `arch`

To the top of my Podfile and it prints arm64. This confirms it's not running under Rosetta

Are you able to run react-native and simulator after doing all fixes?

[stefanoeb]

Other than the cocoapods / ffi issue mentioned above I was able to run react-native projects in M1 as well.

I'd like to add two tips on what I had to do to have a good/fast experience:

⚠️ Using the native Terminal app grinds the whole system to a halt, multiple freezes when trying to open a few tabs on the Terminal. Install iTerm and problem is gone

😱 Metro bundler was taking around 45 minutes to build with --reset-cache! I think it was a problem with the node version (I was on 12.18.2), so I removed nvm and installed node 14.15.4 directly from the website and metro bundler got normal again

[alradadi]

I was able to get a fresh project working on M1 without Rosetta at all. Here are the steps i took:

Xcode is v12.3 node is v15.5.1 pod is v1.10.0

create a new project using npx react-native init RN064 --version 0.64.0-rc.2

Update your post install script in Podfile

post_install do |installer|
  react_native_post_install(installer)
  installer.pods_project.build_configurations.each do |config|
    config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"
  end
end

Add arm64 to the Excluded Architectures under Build Settings.

Then install pods and run the project:

sudo gem install ffi
pod install
yarn ios

[raaidkh-tsa]

Using Rosetta, I was able to install Homebrew and the necessary requirements to set up a working React Native environment according to the setup guide: https://reactnative.dev/docs/environment-setup.

On my first attempt, I was receiving this error:

checking whether the C compiler works... no
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'Path' in SDK 'iphoneos'
/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing: Unknown `--is-lightweight' option
Try `/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
configure: error: in `/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6':
configure: error: C compiler cannot create executables
See `config.log' for more details

I fixed this error by opening Xcode > Preferences > Locations and selecting Xcode 12.2 from the Command Line Tools dropdown.

After selecting this, I was able to go through the install and build process smoothly.

Note: According to the activity monitor, Node and Watchman are using the Intel architecture (x86 through Rosetta)

while the iOS simulator is using Apple's ARM architecture (and running very smoothly).

Hope this helps!

Can You Guide me

[Fa1th7]

I am thinking of buying the MBA m1 for my work. It's a big investment for me. My current project is related to react native cli and firebase. Not sure it will work smoothly or not. I am beginner so just need an advice, should I buy the m1 or Intel one for my work? Thanks in advance. 🙏

[OKNoah]

I was able to get a fresh project working on M1 without Rosetta at all. Here are the steps i took:

Xcode is v12.3 node is v15.5.1 pod is v1.10.0

create a new project using npx react-native init RN064 --version 0.64.0-rc.2

Update your post install script in Podfile

post_install do |installer|
  react_native_post_install(installer)
  installer.pods_project.build_configurations.each do |config|
    config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"
  end
end

Add arm64 to the Excluded Architectures under Build Settings.

Then install pods and run the project:

sudo gem install ffi
pod install
yarn ios

This means you're using Rosetta.

[OKNoah]

I thought I uninstalled just about everything, started over with Home-brew, then rbenv, then ffi and cocoa pods, but same result...

[andreialecu]

@OKNoah the last command in my terminal history related to ffi is indeed:

arch -x86_64 sudo gem install ffi

So it might be possible that just ffi is somehow running in x86 mode, but like mentioned previously, ruby itself reports arm64. I don't think there's any issue resulting from this.

Add arm64 to the Excluded Architectures under Build Settings.

Note that this will result in issues with scrolling, and it is likely that you're running under Rosetta by doing it, see below.

In my setup I did not exclude arm64 from the iPhone simulator slice. You're essentially only keeping the x86_64 slice which intuitively doesn't seem right. It also results in bugs such as: https://developer.apple.com/forums/thread/668488 (which do not exist when compiled to native arm64).

So to reiterate, I've been running react native apps as native arm64 on the simulator, with excellent performance.

[alradadi]

running pod update produces the follwing error

LoadError - dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle, 0x0009): missing compatible arch in /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle - /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle

However, as soon as I add source 'https://github.com/CocoaPods/Specs.git' at the top of my Podfile, the issue goes away.

I don't understand why. Isn't the CocoaPods source included by default?

[AdamGerthel]

running pod update produces the follwing error

LoadError - dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle, 0x0009): missing compatible arch in /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle - /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle

However, as soon as I add source 'https://github.com/CocoaPods/Specs.git' at the top of my Podfile, the issue goes away.

I don't understand why. Isn't the CocoaPods source included by default?

I don't remember the steps I did in detail anymore, but I'm running a version of ruby that I installed via homebrew. I also installed libffi via homebrew. Note that my homebrew installation is also running without Rosetta, so everything I've installed via homebrew runs without Rosetta. Some of my setup and details are documented here: https://github.com/facebook/react-native/issues/29984#issuecomment-743746829

[OKNoah]

I. probably should have posted this output of running Cocoapods under Ruby 2.7.2 here. My bad, I'm tracking like a dozen threads on this while trying the steps over and over with small permutations. Again, confounding that some report not problems and no one has a clear guide (beside Rosetta everything) or guarantee of success after a month and 5 days.

I'm a month behind launching a product and this just sucks.

[andreialecu]

I have some interesting findings regarding the libffi issue. Suddenly while working on a legacy RN project I started seeing similar issues reported by @OKNoah here.

Running pod install on that project would fail, but others were fine. I tracked it down to this particular dependency that was being used in that project: "react-native-image-crop-picker": "^0.28.0",

Without that dependency, pod install runs fine, as soon as it's added, it fails:

### Error

LoadError - dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle, 0x0009): missing compatible arch in /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle - /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle

Seems cocoapods might be going a different route when downloading certain dependencies.

If I add that particular dep to another project that otherwise installs fine, I can reproduce the error.

So it appears my ffi/libffi isn't working properly either, but it isn't necessary except for certain pods.

Based on the stack trace, it seems that the failure happens while cocoapods tries to download something via https://github.com/typhoeus/typhoeus, which is only triggered for that specific pod. I haven't yet looked into the specific circumstances. Out of about 30 pods in the project only that one is affected though.

[OKNoah]

I don't remember the steps I did in detail anymore

running pod update produces the follwing error

LoadError - dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle, 0x0009): missing compatible arch in /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle - /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle

However, as soon as I add source 'https://github.com/CocoaPods/Specs.git' at the top of my Podfile, the issue goes away.

I don't understand why. Isn't the CocoaPods source included by default?

I have some interesting findings regarding the libffi issue. Suddenly while working on a legacy RN project I started seeing similar issues reported by @OKNoah here.

Running pod install on that project would fail, but others were fine. I tracked it down to this particular dependency that was being used in that project: "react-native-image-crop-picker": "^0.28.0",

Without that dependency, pod install runs fine, as soon as it's added, it fails:

### Error

LoadError - dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle, 0x0009): missing compatible arch in /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle - /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle

Seems cocoapods might be going a different route when downloading certain dependencies.

If I add that particular dep to another project that otherwise installs fine, I can reproduce the error.

So it appears my ffi/libffi isn't working properly either, but it isn't necessary except for certain pods.

Based on the stack trace, it seems that the failure happens while cocoapods tries to download something via https://github.com/typhoeus/typhoeus, which is only triggered for that specific pod. I haven't yet looked into the specific circumstances. Out of about 30 pods in the project only that one is affected though.

Are you talking about the post directly above yours? https://github.com/react-native-community/discussions-and-proposals/issues/295#issuecomment-761474871 (this one within it)? The error is the same?

[OKNoah]

Found solution (workaround if you prefer), will publish guide ASAP.

EDIT: My Ghost + Gatsby CI is broken, so I will have to fix tomorrow.