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

[azeezat]

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

[sadikyalcin]

Yup, this solution works on M1's.

[mikehardy]

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

[AntouanK]

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?

[mikehardy]

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.

[AntouanK]

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

[AntouanK]

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.

[mikehardy]

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

[AntouanK]

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

[mikehardy]

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

[AntouanK]

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

[mikehardy]

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.

[losheredos]

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!

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

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.

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

@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

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

• Improve support for Android users on M1 machine #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

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

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