mikehardy
commented
3 years ago @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 https://github.com/facebookarchive/react-native-fbsdk/issues/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_installstanza 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
archcommand is useful in these cases, you may use it either in package.json scripts or your Podfile to detect if you are onx86_64orarm64and 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 yourpod installwill do things you do not want based on mis-diagnosing yourarchasx86_64(via Rosetta 2), resulting in undefined behavior and pod install / compile errors. https://github.com/microsoft/vscode/issues/116763 - do not run install / compile commands from a Terminal in VS Code.
azeezat
sadikyalcin
AntouanK
losheredos
Mr0cket
James-Wilkinson-git
Icasso
fkgozali
lubomyr
lunaleaps
darrylyoung
Yonom
yurakruhlyk
onlyling
pixelknitter
daniel-keen
gio-moros
Eafy
Eronred
saifmattias
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
...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'spost_installsection (aka "stanza"):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
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 runpod install, you should be aware that as of this typing VSCode Terminal runs under Rosetta 2, and yourpod installwill do things you do not want based on mis-diagnosing yourarchasx86_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.