facebook / react-native

Hey folks 👋

This issue wants to help everyone working from an M1 powered machine successfully be able to build their RN apps.

The points below have been written by @mikehardy (and only lightly edited for readability), so huge props to him for his work on this problem space 👏👏

All testing is done with this script and variations on it https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh - so that testing is reproducible.

Main fix

For Apple Silicon to work at all you need to address a linker problem with react-native and Swift libraries.

You know you have this problem if you see something like

ld: warning: Could not find or use auto-linked library 'swiftCoreFoundation'

...as described in facebookarchive/react-native-fbsdk#755

Many people recommend adding an empty Swift file with a bridging header, but it's not ideal: it is a manual thing that requires GUI manipulation in Xcode = hard to document, not automatic and it is only done for the side effect it has of changing up library paths.

This solution directly has the desired effect, added in your local Podfile's post_install section (aka "stanza"):

    installer.aggregate_targets.each do |aggregate_target|
      aggregate_target.user_project.native_targets.each do |target|
        target.build_configurations.each do |config|
          config.build_settings['LIBRARY_SEARCH_PATHS'] = ['$(SDKROOT)/usr/lib/swift', '$(inherited)']
        end
      end
      aggregate_target.user_project.save
    end

Hermes + iOS

For Apple Silicon to successfully use Hermes for iOS you should use react-native 0.65. It is maybe possible with react-native 0.64 but it requires the updated Hermes dependency used in react-native 0.65 (v0.8.1), and trying to qualify that on react-native 0.64 is not something generally supportable. Hermes + iOS + Apple Silicon? Please update to react-native 0.65.

3rd party packages PSA

Many React Native third party libraries, like the ones @mikehardy is involved in react-native-google-signin and react-native-fbsdk-next are not ready for Apple Silicon yet. They both need forward ports to wrap the updated breaking-change versions of the underlying native SDKs, and that's work in need of your effort.

Check the issue section of those repositories that error out on M1s, there's probably already an ongoing effort to add support - help out if you can.

Anecdotally, Mike says that

I currently check in my podfile to edit out those dependencies for my Apple Silicon colleagues and prohibit release builds there. The arch command is useful in these cases, you may use it either in package.json scripts or your Podfile to detect if you are on x86_64 or arm64 and behave programmatically (removing dependencies perhaps) as needed

VSCode Terminal issues

tl;dr: do not run install / compile commands from a Terminal in VS Code unless your VS Code is up to date

If you program using VSCode and use Terminal inside VSCode for commands, like run pod install, you should be aware that as of this typing VSCode Terminal runs under Rosetta 2, and your pod install will do things you do not want based on mis-diagnosing your arch as x86_64 (via Rosetta 2), resulting in undefined behavior and pod install / compile errors. See microsoft/vscode#116763 for more details.

[edited: vscode current versions work great on arm64, even if it's a remote-ssh connection]

If none of the above helped you, and you can reproduce your issue consistently - even on a freshly init'd project, then post a comment below with how to repro so that this can be investigated further.

@kelset, I cannot edit the issue, so I will post a comment here, then please / with my blessing take anything useful and chop it up / paste it whereever seems good

1- all testing is done with this script and variations on it https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh - so that testing is reproducible

2- For Apple Silicon to work at all you need to work around a linker problem with react-native and Swift libraries.

You know you have this problem if you see something like

ld: warning: Could not find or use auto-linked library 'swiftCoreFoundation'

...as described in facebookarchive/react-native-fbsdk#755

Many people recommend adding an empty Swift file with a bridging header, but I find this distasteful personally as:

it is a manual thing that requires GUI manipulation in Xcode (hard to document, not automatic and
it is only done for the side effect it has of changing up library paths.
it did not even work for me all the time!

I prefer this solution which directly has the desired effect, added in Podfile post_install stanza:
configuration change to the post_install stanza in your Podfile. If you do not, you will get errors that look like:

The stanza looks like this inside post_install

    installer.aggregate_targets.each do |aggregate_target|
      aggregate_target.user_project.native_targets.each do |target|
        target.build_configurations.each do |config|
          config.build_settings['LIBRARY_SEARCH_PATHS'] = ['$(SDKROOT)/usr/lib/swift', '$(inherited)']
        end
      end
      aggregate_target.user_project.save
    end

Hermes + iOS: For Apple Silicon to successfully use Hermes for iOS you should use react-native 0.65. It is maybe possible with react-native 0.64 but it requires the updated hermes dependency used in react-native 0.65, and trying to qualify that on react-native 0.64 is not something generally supportable. Hermes + iOS + Apple Silicon? Use react-native 0.65.
3rd party package notes: I am involved in other popular repositories like react-native-google-signin and react-native-fbsdk-next and those are not ready for Apple Silicon yet. They both need forward ports to wrap the updated breaking-change versions of the underlying native SDKs, and that's work in need of your effort. See those repositories to help out. I currently use check in my podfile to edit out those dependencies for my Apple Silicon colleagues and prohibit release builds there. The arch command is useful in these cases, you may use it either in package.json scripts or your Podfile to detect if you are on x86_64 or arm64 and behave programmatically (removing dependencies perhaps) as needed
VSCode Terminal issues: If you program using VS Code and use Terminal inside VS Code to do things, like run pod install, you should be aware that as of this typing VS Code Terminal runs under Rosetta 2, and your pod install will do things you do not want based on mis-diagnosing your arch as x86_64 (via Rosetta 2), resulting in undefined behavior and pod install / compile errors. microsoft/vscode#116763 - do not run install / compile commands from a Terminal in VS Code.

This is great! My app now builds. I have tried several fixes. Thanks and great work @kelset

Yup, this solution works on M1's.

...and it is so much tidier than an empty swift file and bridging header isn't it? Discovering the one stack overflow comment on one of the posts about this that held the clue about putting the swift path in first and having that pass testing was a very happy moment, I had a really hard time solving this one

both on my work project, the react-native "AwesomeProject", and on that "make-demo.sh" project, I get the same errors.
looks like this

I can then go in /ios and do arch -x86_64 pod install and it installs the right (??) packages I guess.
but running npx react-native run-ios shows a similar error

any ideas on how to fix this?

Please post text, enclosed in triple-backticks if possible, of the actual errors. For instance the first image you posted is incredibly difficult to read on mobile, and does not contain the actual error. So I'm not sure what is going on there.

No arch commands should be necessary to use react-native 0.65.0-rc.3 on Apple Silicon.

Your second error about swift libraries not being found appears to related to the error that this exact post_install hook above is supposed to fix, so that is surprising. I have that workaround in use on both intel and apple silicon macs and do not see your error.

https://stackoverflow.com/help/minimal-reproducible-example is critical here, but my make-demo.sh script does not reproduce it for me, so I'm not sure what's going on in your environment.

@mikehardy you're right. I'll prepare a better representation of the problem shortly so you can have the full picture.

the steps I take

go to empty dir in /tmp/react-native-test
run the make-demo script ( https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh )
let it end. ends with error :

Adding basic iOS integration - AppDelegate import and config call
Adding basic java integration - gradle plugin dependency and call
Adding upstream SDK overrides for precise version control
Copying in Firebase android json and iOS plist app definition files downloaded from console
cp: ../GoogleService-Info.plist: No such file or directory

I go in the rnfbdemo directory it created
I run npx react-native run-ios
( it starts with this line in the logs error Could not find the following native modules: RNFBApp. Did you forget to run "pod install" ? )
it pops up the simulator and the terminal with metro
it says "building" for quite some time
it fails with those logs --> https://pastebin.com/raw/QVh1W0zB

am I supposed to have that GoogleService-Info.plist file?
or should I run pod install first?

I've never set up a react-native app on a macbook before, so no idea what's the right steps.

Thank you.

My script (make-demo.sh) was originally intended for a "How do I integrate react-native-firebase" demonstration so it requires you to have firebase project files (the two files it fails on - GoogleService-Info.plist, google-services.json) in order to work successfully.

Using it for a "how do I get react-native to work on Apple Silicon" requires a slightly different script that removes the react-native-firebase parts.

I've done that on a branch, you may have more success with this: https://github.com/mikehardy/rnfbdemo/blob/rn65demo/make-demo.sh - you should retry with that

As an aside, it is basically always safe to run pod install on apple machines, and it is strictly required after doing any sort of Podfile modification or installing anything that touches native code

@mikehardy
ah ok, I see.

I got your script, and tried again.
the output is here : https://pastebin.com/raw/80ReM6M4
Any idea why it fails?

Quite odd, it appears that everything should be working and yet you are apparently suffering from exactly the error that the Podfile post_install library path tweak is supposed to fix. I can't explain it, sorry

not very hopeful 😂
any way we can debug it? Any ideas at all?

trial and error with adding empty swift file + bridging header approach documented elsewhere, with other swift items in the library path, on other machines perhaps. All pretty vague but it's really just methodical testing of one approach after another until you find something that works, then continued trial and error examining why that solution worked, with the goal to reduce it to it's simplest possible application (and ideally to something that may be done in a post_install hook

which is what I thought I had accomplished :-), but clearly not.

I couldnt build react-native stripe package because of these swift errors.

After adding 'post_install' part, it resolved! Now I can build finally :))

Thanks for your efforts and sharing it!

If anyone has time to test the post_install with the two entries reversed - that is inherited first, then the swift libraries, I would really really really like to hear a report on if it still works after pod install / rebuild.

Why? There is an upstream patch going into react-native that is implementing something similar, but they have the entries reversed. Does it work? We need to know!

Thanks in advance

I am getting the following issue while running pod install. The error occurs while installing the glog (0.3.5) pod.
As you can see, I am emulating the x86_64 architecture in my terminal:

➜  ios git:(develop) arch
i386

And have also tried pod install with and without prefixing arch -x86_64.
This problem occurs on several different RN projects, with react native versions: 0.64.2 & 0.64.5.

...
Installing boost-for-react-native (1.63.0)
Installing glog (0.3.5)
[!] /bin/bash -c 
set -e
#!/bin/bash
# Copyright (c) Facebook, Inc. and its affiliates.
#
# This source code is licensed under the MIT license found in the
# LICENSE file in the root directory of this source tree.

set -e

PLATFORM_NAME="${PLATFORM_NAME:-iphoneos}"
CURRENT_ARCH="${CURRENT_ARCH}"

if [ -z "$CURRENT_ARCH" ] || [ "$CURRENT_ARCH" == "undefined_arch" ]; then
    # Xcode 10 beta sets CURRENT_ARCH to "undefined_arch", this leads to incorrect linker arg.
    # it's better to rely on platform name as fallback because architecture differs between simulator and device

    if [[ "$PLATFORM_NAME" == *"simulator"* ]]; then
        CURRENT_ARCH="x86_64"
    else
        CURRENT_ARCH="armv7"
    fi
fi

export CC="$(xcrun -find -sdk $PLATFORM_NAME cc) -arch $CURRENT_ARCH -isysroot $(xcrun -sdk $PLATFORM_NAME --show-sdk-path)"
export CXX="$CC"

# Remove automake symlink if it exists
if [ -h "test-driver" ]; then
    rm test-driver
fi

./configure --host arm-apple-darwin

cat << EOF >> src/config.h
/* Add in so we have Apple Target Conditionals */
#ifdef __APPLE__
#include <TargetConditionals.h>
#include <Availability.h>
#endif

/* Special configuration for ucontext */
#undef HAVE_UCONTEXT_H
#undef PC_FROM_UCONTEXT
#if defined(__x86_64__)
#define PC_FROM_UCONTEXT uc_mcontext->__ss.__rip
#elif defined(__i386__)
#define PC_FROM_UCONTEXT uc_mcontext->__ss.__eip
#endif
EOF

# Prepare exported header include
EXPORTED_INCLUDE_DIR="exported/glog"
mkdir -p exported/glog
cp -f src/glog/log_severity.h "$EXPORTED_INCLUDE_DIR/"
cp -f src/glog/logging.h "$EXPORTED_INCLUDE_DIR/"
cp -f src/glog/raw_logging.h "$EXPORTED_INCLUDE_DIR/"
cp -f src/glog/stl_logging.h "$EXPORTED_INCLUDE_DIR/"
cp -f src/glog/vlog_is_on.h "$EXPORTED_INCLUDE_DIR/"

checking for a BSD-compatible install... /opt/homebrew/opt/coreutils/libexec/gnubin/install -c
checking whether build environment is sane... yes
checking for arm-apple-darwin-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /opt/homebrew/opt/coreutils/libexec/gnubin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-apple-darwin-gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk accepts -g... yes
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk option to accept ISO C89... none needed
checking whether /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk... gcc3
checking how to run the C preprocessor... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk -E
checking whether we are using the GNU C++ compiler... yes
checking whether /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk accepts -g... yes
checking dependency style of /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.5.sdk... gcc3
checking build system type... 
/Users/milly/Library/Caches/CocoaPods/Pods/External/glog/2263bd123499e5b93b5efe24871be317-73c24/missing: Unknown `--is-lightweight' option
Try `/Users/milly/Library/Caches/CocoaPods/Pods/External/glog/2263bd123499e5b93b5efe24871be317-73c24/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
Invalid configuration `arm64-apple-darwin20.3.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin20.3.0 failed

Stack

   CocoaPods : 1.10.2
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin20]
    RubyGems : 3.0.3
        Host : macOS 11.2.3 (20D91)
       Xcode : 12.5.1 (12E507)
         Git : git version 2.31.1
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : trunk - CDN - https://cdn.cocoapods.org/

Installation Source

Executable Path: /usr/local/bin/pod

As for initialising a react native project with the latest react native version I fail at the following step:

> $ npx react-native init rnfbdemo
✔ Downloading template
✔ Copying template
✔ Processing template
✖ Installing CocoaPods dependencies (this may take a few minutes)
✖ Installing CocoaPods dependencies (this may take a few minutes)
error Error: Failed to install CocoaPods dependencies for iOS project, which is required by this template.
Please try again manually: "cd ./rnfbdemo/ios && pod install".
CocoaPods documentation: https://cocoapods.org/

🤷‍♂️

Looks like a network issue. If your doing Rosetta2 you need none of this. This issue is for Apple silicon / arch am64 native.

I tried all these any many others, still getting errors. On a brand new machine
MacOS Big Sur 11.5.2
Node 15.9
using Bash so Xcode finds node at 15.9 which was told is needed to compile too
tried npx, tried npm, did the pod wipe and install with and without the post installer script, tried with and without rosetta, tried the exclude arm64 arch in code build settings, all just move the error somewhere else down the line.

Does no one have a contact at appl to just go wtf mang is with this architecture make it work apple is suppose to just work.

ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/jameserwilk/Sites/hm-mobile-react-native/HiMama/ios/Pods/hermes-engine/destroot/Library/Frameworks/iphoneos/hermes.framework/hermes' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I tried to upgrade react native but that broke the rest of NPM with dependency tree shaking :/

I run npm i react-native to get 0.65.1 but package json still says ^0.64.2

@jerw-git why are you using an unstable version of node? An LTS might be safer.

All my testing versions are converged via a script that pegs these versions at the moment - tested + working, on macOS 11.5.2

XCODE_WANTED_VERSION="Xcode 12"
XCODE_WANTED_VERSION_COMPLETE="${XCODE_WANTED_VERSION}.5.1"
BREW_WANTED_VERSION="3.2.9" # https://github.com/Homebrew/brew/releases
NVM_VERSION="0.38.0" # https://github.com/nvm-sh/nvm/releases
NODE_CURRENT_VERSION="v14.17.5" # https://nodejs.org/download/release/latest-v14.x/
YARN_VERSION="1.22.11" # https://github.com/yarnpkg/yarn/releases
JDK_VERSION_WANTED="11" # https://adoptopenjdk.net/archive.html
RVM_VERSION_WANTED="1.29.12" # https://github.com/rvm/rvm/releases
RUBY_VERSION_WANTED="ruby-3.0.2" # https://www.ruby-lang.org/en/downloads/
FASTLANE_VERSION_WANTED="2.191.0" # https://github.com/fastlane/fastlane/releases
COCOAPODS_VERSION_WANTED="1.10.2" # https://github.com/CocoaPods/CocoaPods/releases

I run npm i react-native to get 0.65.1 but package json still says ^0.64.2

So bump it in package.json to make sure and/or check package-lock.json ?

react-native 0.65 brings in it's own set of subtle compile issues but is worth it (to me) to get iOS+Hermes working on Apple Silicon

Here's my full set of workarounds there

 post_install do |installer|
    react_native_post_install(installer)

    # Apple Silicon builds require a library path tweak for Swift library discovery or "symbol not found" for swift things
    installer.aggregate_targets.each do |aggregate_target| 
      aggregate_target.user_project.native_targets.each do |target|
        target.build_configurations.each do |config|
          config.build_settings['LIBRARY_SEARCH_PATHS'] = ['$(SDKROOT)/usr/lib/swift', '$(inherited)']
        end
      end
      aggregate_target.user_project.save
    end

     # Flipper requires a crude patch to bump up iOS deployment target, or "error: thread-local storage is not supported for the current target"
    # I'm not aware of any other way to fix this one other than bumping iOS deployment target to match react-native (iOS 11 now)
    installer.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
        config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '11.0'
       end
    end

    # ...but if you bump iOS deployment target, Flipper barfs again "Time.h:52:17: error: typedef redefinition with different types"
    # We need to make one crude patch to RCT-Folly - set `__IPHONE_10_0` to our iOS target + 1
    # https://github.com/facebook/flipper/issues/834 - 84 comments and still going...
    `sed -i -e  $'s/__IPHONE_10_0/__IPHONE_12_0/' Pods/RCT-Folly/folly/portability/Time.h`
  end

Does no one have a contact at appl to just go wtf mang is with this architecture make it work apple is suppose to just work.

I don't even know what this means. If you want it just work use nothing but Rosetta, they wrote a translation layer. This is simply not a constructive comment though, when it's really down to all the (non-Apple / not-apple-controlled) tooling working through compatibility 🤷

Using the versions above, this test script seems to work for me (it integrates all the above hacks) and it's a pretty involved setup... https://github.com/mikehardy/rnfbdemo/blob/master/make-demo.sh

Looks like a network issue. If your doing Rosetta2 you need none of this. This issue is for Apple silicon / arch am64 native.

My issue was actually caused due to homeBrew coreUtils which replaces some of the native libExecs with a GNU-based version causing strange behaviour while running configure on unknown archs (such as apple silicon).

The fix was to uninstall coreUtils from homeBrew.

Finally got the rn-tester package running on my m1 mac mini! Nice! 💯

Just an update at least for the packages mentioned above:

Many React Native third party libraries, like the ones @mikehardy is involved in react-native-google-signin and react-native-fbsdk-next are not ready for Apple Silicon yet.

These work! I have my app successfully through a TestFlight build with react-native 0.65.1, the post_install hacks I posted above, Hermes enabled, Flutter enabled (although obviously not for release), google sign in via the current alpha version, and facebook sign in via the current stable version.

Other than the post_install section noted above and needing a google sign in alpha (for a moment, while it's testing), the M1 story is getting pretty solid for react-native.

More good news - this library lookup ordering thing is solved on react-native now, and should be in 0.66.0 react-native-community/releases#246 (comment) - really excited, I think 0.66 will work out of the box on all apple machines without any workarounds needed

FYI, I and @mikehardy have been verifying v0.66.0-rc.* in M1 machine on Xcode 12.5.* and Xcode 13. So far, it seems like all M1 related issues have been resolved in 0.66 release candidates.

All problems with ios release build compilation via xcode on M1 which was fixed in stable versions 0.66.x, returned back in 0.67.0-rc.0 and rc.1. Maybe not all but problem with "error: thread-local storage is not supported for the current target" returned back for me :(

@lubomyr We'll be picking this into the 0.67-rc.2: 03a0907

You can follow progress here: reactwg/react-native-releases#1

Oh no! I was hoping the hacks could go away for good with the real fix. That thing is a 🧟 - as long as it's in and people can build though 🤞

I actually tried to reproduce the M1 build in response to your post @lubomyr and got completely stuck on something not-react-native-related I think the old YogaKit.modulemap not found thing. Apple development is so touchy.

@lunaleaps, This problem resolved in 0.67-rc.2. Thanks

I actually tried to reproduce the M1 build in response to your post @lubomyr and got completely stuck on something not-react-native-related I think the old YogaKit.modulemap not found thing. Apple development is so touchy.

@mikehardy Ah, yeah. I've seen that YogaKit.modulemap not found issue come back recently. It seems pretty random when it does, too. Like you said, all this is so touchy!

Does anyone know definitively what the current state is regarding these common M1-related issues? I see some people say they're gone in 0.66, some say they're back in 0.67, and others saying they're resolved in 0.67.

I'm running an ejected/bare Expo project and recently upgraded to SDK 43 which sets React Native to 0.64.2. My problem there is that I want Hermes but I'm on an M1 Mac so, as far as I can tell, I can't build a Hermes app for the Simulator unless I upgrade to React Native 0.65. Doing that, though, I get the following error, which I see many others are having:

Typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs 'enum clockid_t')

According to other threads, this is fixed with React Native 0.66 so I figured I'm already off the recommended version for Expo so why not go to the latest and get the supposed M1-related fixes. I did that and I'm still getting the issue. Now, though, I see people say it's related to iOS deployment version and to set that to 11 (I have 12 and have had that for a year now). Doing that, though, breaks Expo as something related to the SDK 43 changes requires a minimum version of 12. That completes the loop and leaves me stuck.

I thought the changes brought with __apply_Xcode_12_5_M1_post_install_workaround(installer) fixed the issue but I'm still seeing it both with Flipper enabled (with no versions pinned or with versions pinned) and with it removed completely (I've never actually used it so tried just removing it from the Podfile). Same issue.

For context, here's my Podfile after upgrading to React Native 0.66:

require File.join(File.dirname(`node --print "require.resolve('expo/package.json')"`), "scripts/autolinking")
require File.join(File.dirname(`node --print "require.resolve('react-native/package.json')"`), "scripts/react_native_pods")
require File.join(File.dirname(`node --print "require.resolve('@react-native-community/cli-platform-ios/package.json')"`), "native_modules")

platform :ios, '12.0'

require 'json'
podfile_properties = JSON.parse(File.read('./Podfile.properties.json')) rescue {}

target 'xxx' do
  use_expo_modules!
  config = use_native_modules!

  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => podfile_properties['expo.jsEngine'] == 'hermes'
  )

  post_install do |installer|
    react_native_post_install(installer)
    __apply_Xcode_12_5_M1_post_install_workaround(installer)
  end
end

I know it's a complicated issue and that people are working to fix things like this but it's particularly frustrating when things seem to be so temperamental. Builds seem to work one minute and not then next. There are a bunch of hacks in various threads that supposedly fix these common issues but looking at responses, they work for some and not for others. It'd be great to have an official M1 Mac setup guide or something like that. I started gathering the initial development environment setup information from people so I could piece together a how-to but even with that stuff set up, I can't find a way around these other M1-related issues.

Thanks to everyone who's working to figure out all this stuff, though. It's very much appreciated.

M1 issues were mostly fixed in 0.66.x with my workaround baked into that podfile method call. They came back briefly in 0.67rc0 because there was an underlying real fix we had high hopes for. It did not work completely so the workaround was cherry picked back in for 0.67rc1+

M1 should be working for non Expo out of the box from template

For Expo if you need iOS deployment version 12 take special note if the code inside the workaround. Part of it is a hack that depends on ios deployment version and you may need to modify it, as it blindly assumes with no verification that 11 is the goal version to match the template just like an awful hack should

@mikehardy Thank you, Mike. Since changing the version in the hack, I no longer see that error. Much appreciated.

Perhaps the time-redefinition-avoidance part of the Podfile compile hack - since it appears it will live longer then I/we thought it would could use a little refresh where it either takes a parameter of your ios deployment version, or attempts to dynamically detect it so that it is not quite so brittle. The assumption that target deployment version is 11 does fit most people, but if Expo is 12 there will be a huge percentage of users like yourself that are bitten by this

I have added this to the RN67 release planning discussion - PRs welcome as ever 🙌 - it takes all of us in order for this to work on the M1 :) reactwg/react-native-releases#1 (comment)

I'm a bit confused about the Android JDK version to use
I cannot find any arm64 builds on homebrew for the recommended JDK (adoptopenjdk8)

Hey @Yonom 👋 - I'm getting close to merging+releasing your react-native-firebase patch, thanks again for that - I would definitely use JDK11 at this point, the android default toolchain has moved to JDK11 as their standard with the latest release of Android Studio a few months back (so compatibility issues in the ecosystem here should be ironed out)

Also JDK11 required to avoid compilation issues when you start targetting sdkVersion 31 (see https://issuetracker.google.com/issues/190734097 and #32540 (comment))

This is not official guidance yet per react-native docs but it really should be at this point. I'll see about doing a PR for that to the docs site unless you beat me to it

Also not sure if there is an arm64 build of JDK11 (as discussed on a separate comment - I think without Rosetta2 installed life will be difficult), but this at least answers your JDK version question. (Edited to add: looks like the CI infrastructure just got moved to JDK11 so this is getting close to being officially recognized - it already works for regular app but it also has to work for Buck, CI etc etc before it is officially sanctioned #32186))

@Yonom Hi I use Azul’s Zulu JDK and it works perfect on m1, they support m1(arm).

Hello, there are some questions.
Use @react-native-community/cli to create a project and it runs normally, but if you add jpush-react-native, you will get an error.
There is no problem with the Inter platform, but Apple’s M1 will have problems, only iOS has problems, and the Android development model is good.
What's the problem?
More information -> jpush/jpush-react-native#860

@onlyling they're packaging their library incorrectly and it doesn't have the necessary slices. Nothing to do with the build here at all. I posted this link there https://onesignal.com/blog/xcframeworks-guide/ - it's the solution for that library.

I've tried the above steps and even tried some others, but still get Command PhaseScriptExecution failed with a nonzero exit code for FBReactNativeSpec:

These two seem to be where it fails consistently:

CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'EXLinearGradient' from project 'Pods')

CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'EXLinearGradient' from project 'Pods')

Attempts to resolve

I've tried the following and perhaps a bit more:

removed nvm
confirmed that all my yarn/pod installs were not made within VSCode and not within opt/__/bin (x86) - to my understanding
drilled into my Pods connection to determine if there was a linking error
re-integrated Pods
wiped out my .xcworkspace and recreated with pod install
deleted my Podfile.lock and ran pod install

I've considered wiping the data transfer for the 2021 MacBook I got and rebuilding my dev environment as my colleagues (w/ M1 macs) aren't having the same issue with the project. However, I'm certainly open to suggestions on how I might debug this effectively. I keep hitting dead ends.

Env

OS: OSX Monterey 12.0.1
Chip: Apple M1
XCode: 13.1 (13A1030d)

Project

standalone - with some EXPO modules baked in use_expo_modules!
Build Target: iOS 12.0
React Native: 0.66.5

@darrylyoung

I know it's a complicated issue and that people are working to fix things like this but it's particularly frustrating when things seem to be so temperamental. Builds seem to work one minute and not then next.
react-native: 0.66.4

Have got "YogaKit.modulemap not found" error on M1 chip. Running with rosetta solves the issue, but it's been quite annoying...

The modulemap thing is usually that podfile min iOS deployment version and xcode app info iOS minimum deployment don't agree

@thexdd just had a report from the react-native-fbsdk-next repo that YogaKit.modulemap may also happen if you have an old .pbxproj without current settings, and bitcode is disabled. User reported successful M1 build after enabling bitcode.

We were running into many issues with the M1 version.
We resolved the majority by first making sure we were running the latest Xcode Version 13.2 (13C90)
Followed by this
1.npx react-native-clean-project.
2. Go inside the ios folder and make sure the Podfile.lock and Pods/are removed.

If you need a sample Podfile. Feel free to use this SampleFile

Then go back to the main folder and run `npx pod-install'

If the problem persists, go into the ios folder and run pods using the old architecture

arch -x86_64 pod install --repo-update

Hope this helps!

Yarn version:
1.22.17

Node version:
14.8.0

Platform:
darwin x64

System:
macOS 12.1

Trace:
Error: https://registry.npmmirror.com/node-notifier/download/node-notifier-5.4.5.tgz: incorrect data check
at Zlib.zlibOnError [as onerror] (zlib.js:180:17)

npm manifest:
{
"name": "react-native-baidu-map-zj",
"version": "1.4.3",
"description": "Baidu Map SDK modules and view for React Native(Android & IOS), support react native 0.57+. 百度地图 React Native 模块，支持 react native 0.57+，已更新到最新的百度地图SDK版本。",
"main": "index.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"repository": {
"type": "git",
"url": "git+https://github.com/eafy/react-native-baidu-map-zj.git"
},
"keywords": [
"Baidu Map",
"React Native"
],
"author": "Eafy",
"license": "MIT",
"bugs": {
"url": "https://github.com/eafy/react-native-baidu-map-zj/issues"
},
"homepage": "https://github.com/eafy/react-native-baidu-map-zj#readme",
"devDependencies": {
"react": "16.13.1",
"react-native": "^0.63.2"
}
}

yarn manifest:
No manifest

Lockfile:
No lockfile

Error:
error An unexpected error occurred: "https://registry.yarnpkg.com/node-notifier/-/node-notifier-5.4.5.tgz: incorrect data check".
info If you think this is a bug, please open a bug report with the information provided in "/Users/lzj/Desktop/Git/react-native-baidu-map-zj/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Yarn version: 1.22.17

Node version: 14.8.0

Platform: darwin x64

System: macOS 12.1

Trace: Error: https://registry.npmmirror.com/node-notifier/download/node-notifier-5.4.5.tgz: incorrect data check at Zlib.zlibOnError [as onerror] (zlib.js:180:17)

npm manifest: { "name": "react-native-baidu-map-zj", "version": "1.4.3", "description": "Baidu Map SDK modules and view for React Native(Android & IOS), support react native 0.57+. 百度地图 React Native 模块，支持 react native 0.57+，已更新到最新的百度地图SDK版本。", "main": "index.js", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "repository": { "type": "git", "url": "git+https://github.com/eafy/react-native-baidu-map-zj.git" }, "keywords": [ "Baidu Map", "React Native" ], "author": "Eafy", "license": "MIT", "bugs": { "url": "https://github.com/eafy/react-native-baidu-map-zj/issues" }, "homepage": "https://github.com/eafy/react-native-baidu-map-zj#readme", "devDependencies": { "react": "16.13.1", "react-native": "^0.63.2" } }

yarn manifest: No manifest

Lockfile: No lockfile

Error: error An unexpected error occurred: "https://registry.yarnpkg.com/node-notifier/-/node-notifier-5.4.5.tgz: incorrect data check". info If you think this is a bug, please open a bug report with the information provided in "/Users/lzj/Desktop/Git/react-native-baidu-map-zj/yarn-error.log". info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Node.js upgrade from v14 to v16 has solved this problem.

We were running into many issues with the M1 version. We resolved the majority by first making sure we were running the latest Xcode Version 13.2 (13C90) Followed by this 1.npx react-native-clean-project. 2. Go inside the ios folder and make sure the Podfile.lock and Pods/are removed.

If you need a sample Podfile. Feel free to use this SampleFile

Then go back to the main folder and run `npx pod-install'

If the problem persists, go into the ios folder and run pods using the old architecture
arch -x86_64 pod install --repo-update

Hope this helps!

When I run my ios simulator, it's directly shooting this error to my face but if I open Xcode with Rossetta and re-build/open the simulator again, it is working with zero error and fast. Really what is wrong with this M1 chip? React web is so good but there are so many errors for the mobile side..

@Eronred start by cleaning the ios folder doing
cd ios && xcodebuild clean && rm -rf ~/Library/Caches/CocoaPods && rm -rf Pods && rm -rf ~/Library/Developer/Xcode/DerivedData/* && pod cache clean --all && pod deintegrate

Additionally, there are some dependencies in your project that require an x86 to build after cleaning the ios package run arch -x86_64 pod install --repo-update

Hope this helps.

@Eronred start by cleaning the ios folder doing cd ios && xcodebuild clean && rm -rf ~/Library/Caches/CocoaPods && rm -rf Pods && rm -rf ~/Library/Developer/Xcode/DerivedData/* && pod cache clean --all && pod deintegrate

Additionally, there are some dependencies in your project that require an x86 to build after cleaning the ios package run arch -x86_64 pod install --repo-update

Hope this helps.

This helped me a looooot, could not run a simple app on physical iphone. But this command solved it :)

@Ekaanth I think it would be most useful to mention that your guides describe workarounds for people using specific ruby packages, namely FFI), and the posts should link to the issues you are working around so that as they get fixed and the post goes stale, people can at least detect that (ffi/ffi#922 - tracking an M1-compatible FFI release)

If you're not using FFI, those posts will just lead people off into the post-apocalyptic wasteland of mixed-architecture ruby gem installs 😆

@Ekaanth I think it would be most useful to mention that your guides describe workarounds for people using specific ruby packages, namely FFI), and the posts should link to the issues you are working around so that as they get fixed and the post goes stale, people can at least detect that (ffi/ffi#922 - tracking an M1-compatible FFI release)

If you're not using FFI, those posts will just lead people off into the post-apocalyptic wasteland of mixed-architecture ruby gem installs 😆

Yaa, I should have mentioned better. Those link would work for people who start newly. I understand what you mean, I took down the post for now. Sorry for being crude.

not crude at all! For anyone that does need FFI, those workarounds would be vital. I'm all for useful hacks as long as they are specific (like with a link to the FFI issue) :-)

Few tips to save you from pain and misery for new react projects on m1 macs:

Don't create a new react project in a path which includes a blank space, ex: react project/myApp. This caused the debug shell scripts to fail on my laptop
Before running npx run ios for the first time, comment out typedef uint8_t clockid_t; in RCT-folly/folly/portability/Time.h.
Make sure you have the latest ios simulator and the correct platform selected before running run ios, or add --simulator=<simulator> flag to the command

I gotta say that flutter was much easier to setup than this, but react native is still worth the effort

@kshitej sounds like you are not using the Podfile post-install workaround if you need this, I'd be careful and make sure you include that one:

Before running npx run ios for the first time, comment out typedef uint8_t clockid_t; in RCT-folly/folly/portability/Time.h.

The postinstall workaround is supposed to solve that issue for you

https://github.com/Yonom/react-native/blob/ba70ca4c5841df9796f353671395cc9592d418b2/scripts/react_native_pods.rb#L584

react native 0.66.4 working fine with mac M1 but after 0.67 and 0.68 in not working on ios

** BUILD FAILED **

The following build commands failed:
CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'YogaKit' from project 'Pods')
CompileC /Users/adilkhan/Library/Developer/Xcode/DerivedData/namal_woo_react_deliveryboy-coxbjeyuoivbqpceuhgsqzwkndku/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/RCT-Folly.build/Objects-normal/x86_64/SysUio.o /Volumes/development/working\ dir/react-woocommerce/untitled\ folder/namal_woo_react_deliveryboy/ios/Pods/RCT-Folly/folly/portability/SysUio.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'RCT-Folly' from project 'Pods')
(2 failures)

any solution ?

i have used these commands but nothing work

sudo arch -x86_64 gem install ffi
arch -x86_64 pod install
i have checked it on mac mini m1 and macbook pro m1

@adilkhan2163 that is not an actual error. That's the message indicating there was an error. What was the error? You have to go look through the log to find the actual build failure message

@adilkhan2163 that is not an actual error. That's the message indicating there was an error. What was the error? You have to go look through the log
to find the actual build failure message

@adilkhan2163 You have to continue digging - why did the script fail? What you do next is you take that whole set of export statements and copy/paste them in to a Terminal so your Terminal environment is the same as what Xcode executed. Then you run the script indicated (/Users/adilkhan/etc/etc/etc/Script-3423542352etcetc.sh - copy paste it from the failure message) and see what happened. Run echo $? to get the exit code, if it's not zero that's the failure. Open the script in an editor and see what command failed (I do that by just console debugging - I add "echo step 1" etc etc after each step that could error) and see what failed. Figure out why

Hi,

I'm having an issue with Taking Archive in Xcode. When I try to take build and run the app in simulator or real device via react-native-cli or Xcode it works fine, Only taking archives throwing this error.

iphoneos/iGoal.app
warning: the transform cache was reset.
                    Welcome to Metro!
              Fast - Scalable - Integrated


error SHA-1 for file /Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js (/Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js) is not computed.
         Potential causes:
           1) You have symlinks in your project - watchman does not follow symlinks.
           2) Check `blockList` in your metro.config.js and make sure it isn't excluding the file path.
ReferenceError: SHA-1 for file /Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js (/Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js) is not computed.
         Potential causes:
           1) You have symlinks in your project - watchman does not follow symlinks.
           2) Check `blockList` in your metro.config.js and make sure it isn't excluding the file path.
    at DependencyGraph.getSha1 (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/node-haste/DependencyGraph.js:245:13)
    at Transformer.transformFile (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/Transformer.js:104:23)
    at Bundler.transformFile (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/Bundler.js:48:30)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Object.transform (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/lib/transformHelpers.js:101:12)
    at async processModule (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/traverseDependencies.js:137:18)
    at async traverseDependenciesForSingleFile (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/traverseDependencies.js:131:3)
    at async Promise.all (index 0)
    at async initialTraverseDependencies (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/traverseDependencies.js:114:3)
    at async DeltaCalculator._getChangedDependencies (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/DeltaCalculator.js:164:25)
info Run CLI with --verbose flag for more details.
Command PhaseScriptExecution failed with a nonzero exit code

any idea how to fix this? I tired deleting pod, pod.lock, node_modules, clearing the project, running Xcode in rosetta (one time it worked when I ran Xcode via rosetta), everything..

react native 0.66.4 working fine with mac M1 but after 0.67 and 0.68 in not working on ios

** BUILD FAILED **

The following build commands failed: CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'YogaKit' from project 'Pods') CompileC /Users/adilkhan/Library/Developer/Xcode/DerivedData/namal_woo_react_deliveryboy-coxbjeyuoivbqpceuhgsqzwkndku/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/RCT-Folly.build/Objects-normal/x86_64/SysUio.o /Volumes/development/working\ dir/react-woocommerce/untitled\ folder/namal_woo_react_deliveryboy/ios/Pods/RCT-Folly/folly/portability/SysUio.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'RCT-Folly' from project 'Pods') (2 failures)

any solution ?

i have used these commands but nothing work

sudo arch -x86_64 gem install ffi arch -x86_64 pod install i have checked it on mac mini m1 and macbook pro m1

I can see in your paths that you have spaces in some of your folder names (..such as "working\ dir"). I was getting stuck with the same error, and found this to be the cause. A brand new project from react-native init wouldn't even work - I had to move to a new location without any spaces in any parent folders, and it fixed it.

To test, I created a new folder with a space, ran init, and hit the error again - haven't yet been able to figure out the underlying reason.

Edit: kshitej first spotted this above. Missed that.

react native 0.66.4 working fine with mac M1 but after 0.67 and 0.68 in not working on ios
** BUILD FAILED **
The following build commands failed: CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'YogaKit' from project 'Pods') CompileC /Users/adilkhan/Library/Developer/Xcode/DerivedData/namal_woo_react_deliveryboy-coxbjeyuoivbqpceuhgsqzwkndku/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/RCT-Folly.build/Objects-normal/x86_64/SysUio.o /Volumes/development/working\ dir/react-woocommerce/untitled\ folder/namal_woo_react_deliveryboy/ios/Pods/RCT-Folly/folly/portability/SysUio.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'RCT-Folly' from project 'Pods') (2 failures)
any solution ?
i have used these commands but nothing work
sudo arch -x86_64 gem install ffi arch -x86_64 pod install i have checked it on mac mini m1 and macbook pro m1

I can see in your paths that you have spaces in some of your folder names (..such as "working\ dir"). I was getting stuck with the same error, and found this to be the cause. A brand new project from react-native init wouldn't even work - I had to move to a new location without any spaces in any parent folders, and it fixed it.

To test, I created a new folder with a space, ran init, and hit the error again - haven't yet been able to figure out the underlying reason.

Edit: kshitej first spotted this above. Missed that.

Yes you are right now it's working fine. ♥️♥️
Thank you so much.

In a mixed Intel/M1 team whoever builds the app last changes the ios project file in the setting for EXCLUDED_ARCHS.

Is there a fix to that? This is done in the react_native_pods.rb file depending on the hosts architecture.
On each commit we have to double check this is not committed to the trunk.

I've noticed the same @pke and I'm not aware of any activity in the area

Hmmm guess we have to upgrade all team members to M1 then ;) It's possible all 10.000 devs at facebook already have M1 so they just don't care? ;)

I'd be shocked if that were the case, as M1 causes build failures in react-native semi-frequently.
I think they may just ignore those files or not care if they "flap" back and forth

if I'd have to guess, it's more likely because they rely on BUCK on everything internally - anyway I think that it's an interesting report that you are surfacing and I feel more and more folks will start hitting it... I'll start asking internally at MSFT to see if we've hit it yet

In a mixed Intel/M1 team whoever builds the app last changes the ios project file in the setting for EXCLUDED_ARCHS.

Is there a fix to that? This is done in the react_native_pods.rb file depending on the hosts architecture. On each commit we have to double check this is not committed to the trunk.

Which version of react-native are you using? The only reference to EXCLUDED_ARCHS I see on 0.68 is this:

react-native/scripts/react_native_pods.rb

Lines 212 to 221 in 2a6a685

    
           # Hermes does not support `i386` architecture 
        
           excluded_archs_default = has_pod(installer, 'hermes-engine') ? "i386" : "" 
        
           projects.each do |project| 
        
             project.build_configurations.each do |config| 
        
               config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = excluded_archs_default 
        
             end 
        
             project.save() 
        
           end

It doesn't look like it'd break or flip unless you're enabling/disabling Hermes regularly.

@tido64 that's new. Guess we need to upgrade RN then. We are on 66.3
Or better wait until react 18 made it into RN?

@kelset what is BUCK? I have seen it but only in Android builds

@pke https://buck.build/ this is what I'm referring to.

I would probably suggest to update to RN67 or even 68 and see if things change, maybe it will address that for you

~~@tido64 could line 213 in the snippet you shared not be the culprit? I frequently see it flap back and forth with that i386 entry, I think that's the culprit.~~

Oh never mind, most people are probably not testing builds with and without hermes, most people probably just switching it on and leaving it on

@krdc + @adilkhan2163 - spaces in project working directories has been problematic off and on for a while. I believe the CLI doctor command could check for this and warn people of the danger, I enqueued react-native-community/cli#1583 to capture that idea, and perhaps if/when that's implemented it will save some future developers some time. Cheers

Small update for Android users on M1s with the New Architecture. This is a patch to make sure the Android builds are working fine on M1s without any workaround or patching of files from the user:

#33588

Hopefully we'll land it on 0.68.1 so we don't need further intervention on the Android side of things.

EDIT: Clarification

@cortinico A little clarification: android builds on M1 were already working for old architecture, this makes sure that they work for 0.68+new-architecture+M1, if I understand correctly? (great work making sure people that opt in are able to do so on m1 though of course :-) )

@cortinico A little clarification: android builds on M1 were already working for old architecture, this makes sure that they work for 0.68+new-architecture+M1, if I understand correctly? (great work making sure people that opt in are able to do so on m1 though of course :-) )

That's correct. To be exact, you would have faced the same issue with any other 3rd party NPM package that needed to run the NDK (I'm not sure if there are any). Regardless, the patch is primaly targeted for users on the New Architecture

It still exist

/node_modules/react-native/scripts/../Libraries: No such file or directory
Command PhaseScriptExecution failed with a nonzero exit code

@Aarchi-Ayoub your comment is indecipherable, and thus not actionable. I cannot understand what you mean at all, sorry. https://stackoverflow.com/help/how-to-ask

this part seems to be outdated, the issue is closed in vscode

VSCode Terminal issues
tl;dr: do not run install / compile commands from a Terminal in VS Code.

If you program using VSCode and use Terminal inside VSCode for commands, like run pod install, you should be aware that as of this typing VSCode Terminal runs under Rosetta 2, and your pod install will do things you do not want based on mis-diagnosing your arch as x86_64 (via Rosetta 2), resulting in undefined behavior and pod install / compile errors. See https://github.com/microsoft/vscode/issues/116763 for more details.

@a7madgamal good point! I was helping on that issue a bit and yes, with current versions of VS Code I no longer have Rosetta2 issues. I edited that part of the description with that update, and I'll collapse these two comments as resolved, cheers!

Hi,

I'm having an issue with Taking Archive in Xcode. When I try to take build and run the app in simulator or real device via react-native-cli or Xcode it works fine, Only taking archives throwing this error.

iphoneos/iGoal.app
warning: the transform cache was reset.
                    Welcome to Metro!
              Fast - Scalable - Integrated


error SHA-1 for file /Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js (/Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js) is not computed.
         Potential causes:
           1) You have symlinks in your project - watchman does not follow symlinks.
           2) Check `blockList` in your metro.config.js and make sure it isn't excluding the file path.
ReferenceError: SHA-1 for file /Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js (/Users/prem/Desktop/Projects/igoal/node_modules/metro-runtime/src/polyfills/require.js) is not computed.
         Potential causes:
           1) You have symlinks in your project - watchman does not follow symlinks.
           2) Check `blockList` in your metro.config.js and make sure it isn't excluding the file path.
    at DependencyGraph.getSha1 (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/node-haste/DependencyGraph.js:245:13)
    at Transformer.transformFile (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/Transformer.js:104:23)
    at Bundler.transformFile (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/Bundler.js:48:30)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Object.transform (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/lib/transformHelpers.js:101:12)
    at async processModule (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/traverseDependencies.js:137:18)
    at async traverseDependenciesForSingleFile (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/traverseDependencies.js:131:3)
    at async Promise.all (index 0)
    at async initialTraverseDependencies (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/traverseDependencies.js:114:3)
    at async DeltaCalculator._getChangedDependencies (/Users/prem/Desktop/Projects/igoal/node_modules/metro/src/DeltaBundler/DeltaCalculator.js:164:25)
info Run CLI with --verbose flag for more details.
Command PhaseScriptExecution failed with a nonzero exit code

any idea how to fix this? I tired deleting pod, pod.lock, node_modules, clearing the project, running Xcode in rosetta (one time it worked when I ran Xcode via rosetta), everything..

I am facing the same error, error computing sha-1, while triggering the build from jenkins,fastlane.

@garetjaxor that has nothing to do with react-native, it should not be a comment here. I have a demonstration script for react-native-firebase that shows you how to integrate it correctly from start to finish, with comments though. It works on an M1 mac. Perhaps it is illuminating https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh

Wrong repository.

Hey folks - it's been quite some time that this issue has been open and over time the tooling in the ecosystem (from CocoaPods to NDK, etc) have all rolled out newer versions so that the problems of compatibility with Apple Silicon machines have been addressed; so this issue is not relevant anymore.

Closing.

	# Hermes does not support `i386` architecture
	excluded_archs_default = has_pod(installer, 'hermes-engine') ? "i386" : ""

	projects.each do \|project\|
	project.build_configurations.each do \|config\|
	config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = excluded_archs_default
	end

	project.save()
	end

Apple Silicon (M1) troubleshooting guide (RN 0.64/0.65/0.66)