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.

[mikehardy]

@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

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

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

5. 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. VS Code Terminal is running using Rosetta 2 on Apple M1 microsoft/vscode#116763 - do not run install / compile commands from a Terminal in VS Code.

[azeezat]

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