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

[kelset]

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 https://github.com/facebookarchive/react-native-fbsdk/issues/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 https://github.com/microsoft/vscode/issues/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.

[mikehardy]

@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 (https://github.com/ffi/ffi/issues/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 :laughing:

[Ekaanth]

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

[mikehardy]

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) :-)

[kishjad]

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

1. 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
2. Before running npx run ios for the first time, comment out typedef uint8_t clockid_t; in RCT-folly/folly/portability/Time.h.
3. 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

[mikehardy]

@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

[adilkhan2163]

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

[mikehardy]

@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]

@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

[mikehardy]

@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

[premdasvm]

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

[krdc]

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.

[adilkhan2163]

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.

[pke]

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.

[mikehardy]

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

[pke]

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? ;)

[mikehardy]

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

[kelset]

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

[tido64]

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:

https://github.com/facebook/react-native/blob/2a6a6851ecbe1c3f965943a027e70bd7685c78ab/scripts/react_native_pods.rb#L212-L221

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

[pke]

@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?

[pke]

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

[kelset]

@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

[mikehardy]

@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

[mikehardy]

@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 https://github.com/react-native-community/cli/issues/1583 to capture that idea, and perhaps if/when that's implemented it will save some future developers some time. Cheers

[cortinico]

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:

• https://github.com/facebook/react-native/pull/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

[mikehardy]

@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]

@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

[ayoubaarchi]

It still exist

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

[mikehardy]

@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

[a7madgamal]

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.

[mikehardy]

@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!

[BharatRathore]

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.

[mikehardy]

@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

[mikehardy]

Wrong repository.

[kelset]

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.