Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apple silicon support #295

Closed
hsavit1 opened this issue Nov 17, 2020 · 74 comments
Closed

Apple silicon support #295

hsavit1 opened this issue Nov 17, 2020 · 74 comments
Labels
🗣 Discussion This label identifies an ongoing discussion on a subject

Comments

@hsavit1
Copy link

hsavit1 commented Nov 17, 2020

Introduction

Will react native be supported by apple silicon?

Details

Discussion points

  1. will apps run properly on apple silicon machines?
  2. will I be able to build my react native app?

UPDATE
there may be some hiccups with getting cocoapods working, but overall seems to work well, as either a catalyst app or a iOS / android simulator app. Flipper does not seem to work, currently

UPDATE 2
Flipper version 75.1 mostly seems to fix M1 builds. see this comment https://stackoverflow.com/a/66071245/11721286

@gwmccull
Copy link

The M1 is in the same class of processors as the A-series chips used in iPhones and iPads so I don't think it should be a problem. They already said the M1 computers will be able to run all iPhone apps natively

@hsavit1
Copy link
Author

hsavit1 commented Nov 17, 2020

how about building react native projects on apple silicon machines?

@gwmccull
Copy link

gwmccull commented Nov 17, 2020

I don't have access to one of the new machines so I haven't tried but Xcode works on them so you'd think it'd work. At worst, you might have to run an older version of Xcode in emulated mode

edit: I just saw in the Infinite Red slack channel that someone tried it and Xcode was not working for them. Sounds like a possible issue with Xcode itself though so maybe not an issue w/ RN

@kelset
Copy link
Member

kelset commented Nov 17, 2020

I think it's quite too early to discuss this - let's wait until the laptops have been out for at least a few weeks before trying to figure out what is going to be needed to work. As @gwmccull points out correctly, it's most likely that first Android Studio and Xcode will have to properly work and then we can investigate if there are going to be React Native specific issues.

@kelset kelset added the 🗣 Discussion This label identifies an ongoing discussion on a subject label Nov 17, 2020
@billycastelli
Copy link

Using Rosetta, I was able to install Homebrew and the necessary requirements to set up a working React Native environment according to the setup guide: https://reactnative.dev/docs/environment-setup.

On my first attempt, I was receiving this error:

checking whether the C compiler works... no
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'Path' in SDK 'iphoneos'
/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing: Unknown `--is-lightweight' option
Try `/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
configure: error: in `/Users/billycastelli/Library/Caches/CocoaPods/Pods/Release/Flipper-Glog/0.3.6-1dfd6':
configure: error: C compiler cannot create executables
See `config.log' for more details

I fixed this error by opening Xcode > Preferences > Locations and selecting Xcode 12.2 from the Command Line Tools dropdown.

Screen Shot 2020-11-18 at 6 27 05 PM

After selecting this, I was able to go through the install and build process smoothly.

Note: According to the activity monitor, Node and Watchman are using the Intel architecture (x86 through Rosetta)
Screen Shot 2020-11-18 at 6 44 31 PM

while the iOS simulator is using Apple's ARM architecture (and running very smoothly).
Screen Shot 2020-11-18 at 6 45 18 PM

Hope this helps!

@diegolmello
Copy link

I wonder if whole Android stuff (build, emulator, etc) works properly as well.

@darrylyoung
Copy link

Thanks for sharing, @billycastelli. That's helpful. 👍

@terrysahaidak
Copy link

Seems like not everything is going well:
https://twitter.com/ericlewis/status/1329420283288096770
image

@ericlewis
Copy link

There is a lot of workarounds involved with getting this to even remotely run, I attempted to build the RNTester app & was running into problems repeatedly. I will try to help, but it is unlikely I have the time.

@gwmccull
Copy link

I've gotten that ffi error on Catalina as well. I had to gem install pristine ffi (or something like that) to fix

@phatlaunchdeck
Copy link

Hey guys, thanks for opening up the discussion about this matter, I actually received an email from Apple notifying me about my app using Core Location and it might not work well since Mac does not have it. Any idea how to fix/adjust this? Thanks!

@hsavit1
Copy link
Author

hsavit1 commented Dec 14, 2020

Update here - I have been able to successfully use react native on my M1, additionally have had few problems with using the catalyst simulator, I think if you follow the steps with cocoapods you should generally be ok

@darrylyoung
Copy link

I can confirm that I'm also working with React Native on an M1 Mac and, to be honest, things are going way better than I thought they would. I installed CocoaPods using sudo gem install cocoapods and haven't had any issues there.

Not that it's directly related to React Native but I duplicated iTerm, called one iTerm x86 and set that to run with Rosetta. For Homebrew, managing all dependencies, and for the Metro bundler that's what's used and it's been just fine. It's all very fast, too, and I came from a 16" i9 MacBook Pro.

@RETFU
Copy link

RETFU commented Dec 14, 2020

Hey @darrylyoung do you have a quick benchmark for compilation time on iOS on your previous mac vs M1 ?

@lemontron
Copy link

I've been developing on Apple Silicon for a few days now and it's not bad. In fact the performance of the cli apps is the least of the concerns. What's different is that doing any pod work requires you to enter a Rosetta 2 shell with arch -x86_64 /bin/zsh (a dependency called ffi which is a gem has not been updated yet, possible a host of other packages too) and then everything works smoothly. I can even run expo, using expo start ios and it will open the simulator albeit with the ironic twist that the app process is Intel. To get around this, I tried exporting the IPA file with Archive from Xcode and opening it with Apple's brand new feature of running iOS apps within MacOS. Surprisingly it freaking works out of the box, of course no hot reloading capability though as it has production flags. I also had to exclude arm64 to get some of my code to compile.

Of course the full arm64 suite is a ways away but if we could just do a build of a development IPA file with hot-reloads and open it up it directly in MacOS it would really close the loop on the Apple Silicon transition from a practical viewpoint.

@AdamGerthel
Copy link

AdamGerthel commented Dec 14, 2020

I've gotten in up and running without the need to use Rosetta at all. The only caveat is that I can't use Flipper (yet). My setup is available here: facebook/react-native#29984 (comment)

@RETFU no benchmarks yet, but it's fast.

@darrylyoung
Copy link

Hey @darrylyoung do you have a quick benchmark for compilation time on iOS on your previous mac vs M1 ?

Hi, @RETFU. Unfortunately not, no. I sold my 16" Pro when I got the M1 Air so didn't have chance to do side-by-side testing but after working on the 16" all year, I can say that the Air feels fast. Really fast. It obviously doesn't have the same 32 GB RAM as the 16" Pro but I haven't run into any issues yet doing daily development work. The best thing of all is how the Air clearly outperforms the 16" Pro but manages to do it completely silently and while barely warm to the touch, even when under the highest loads. It's impressive and I'm glad I'm able to continue working on my React Native project on this as there's no going back now.

@andreialecu
Copy link

andreialecu commented Dec 15, 2020

Regarding compilation times on the M1:

I used to have a 2017 MacBook Pro with an i7 CPU and 16GB of RAM.
I replaced it with an 8GB Mac Mini M1 because that was the only one in stock, but I will be replacing it with the 16GB model as soon as it is available.

The compilation times, using fastlane to produce a binary ready for upload to the App Store were as follows:

  • 781 seconds on the 2017 Macbook Pro
  • 145 seconds on the Mac Mini M1 (!)

(this includes both compiling via xcode and producing the js bundle)

I'm running nodejs 15.3.0 compiled to arm64. With nodejs 14 and xcode running via rosetta2 the compilation time was 225 seconds, so still extremely good.

Additionally, my main work PC was a Desktop i7 [email protected] with 32GB of RAM and an M.2 SSD (running Windows) and I benchmarked compiling the same Angular app in production mode on it vs the M1.

  • 7700k: 65 seconds
  • M1: 40 seconds (!)

So, switched to the M1 full time.

Even with just 8GB of RAM it still outperforms the Desktop i7 by a huge margin which I didn't expect.

The SSD on the M1 is fast enough so that swapping is instant so the fact it has just 8GB of RAM isn't a huge deal breaker. I will still be upgrading to 16GB just because Chrome is super memory hungry and I noticed that having a ton of tabs open does degrade performance a tiny bit, so I need to be more mindful about that.

@raienko
Copy link

raienko commented Dec 26, 2020

I hope you'll find better way.. But this one worked for me:

Environment:
macOS Big Sur 11.1
xcode 12.3
xcode -> preferences -> locations -> command line tools 12.3
"react-native": "^0.63.4"

Issues and fixes:

  1. Homebrew installation fails
    Fix in 2 steps:
    /bin/bash -c "$(curl -fsSL https://gist.githubusercontent.com/nrubin29/bea5aa83e8dfa91370fe83b62dad6dfa/raw/48f48f7fef21abb308e129a80b3214c2538fc611/homebrew_m1.sh)

source .zshrc

  1. /Library/Ruby/Gems/2.6.0/gems/ffi-1...
    Fix:
    sudo arch -x86_64 gem install ffi

  2. Pods installation still fails with arm64 related errors
    Fix:
    arch -x86_64 pod install

  3. Pods installed but build fails. Errors related to "arm64" or "C libs"
    Fix:
    Applications -> xcode -> get info -> Open using rosetta

@asterisx
Copy link

Regarding compilation times on the M1:

I used to have a 2017 MacBook Pro with an i7 CPU and 16GB of RAM.
I replaced it with an 8GB Mac Mini M1 because that was the only one in stock, but I will be replacing it with the 16GB model as soon as it is available.

The compilation times, using fastlane to produce a binary ready for upload to the App Store were as follows:

  • 781 seconds on the 2017 Macbook Pro
  • 145 seconds on the Mac Mini M1 (!)

(this includes both compiling via xcode and producing the js bundle)

I'm running nodejs 15.3.0 compiled to arm64. With nodejs 14 and xcode running via rosetta2 the compilation time was 225 seconds, so still extremely good.

Additionally, my main work PC was a Desktop i7 [email protected] with 32GB of RAM and an M.2 SSD (running Windows) and I benchmarked compiling the same Angular app in production mode on it vs the M1.

  • 7700k: 65 seconds
  • M1: 40 seconds (!)

So, switched to the M1 full time.

Even with just 8GB of RAM it still outperforms the Desktop i7 by a huge margin which I didn't expect.

The SSD on the M1 is fast enough so that swapping is instant so the fact it has just 8GB of RAM isn't a huge deal breaker. I will still be upgrading to 16GB just because Chrome is super memory hungry and I noticed that having a ton of tabs open does degrade performance a tiny bit, so I need to be more mindful about that.

Does using external monitors affect memory usage? I would be using 2 4k monitors with the 8gb ram and I am quite worried between webstorm, one simulator, couple of tabs in safari I might slow down the M1 Mac mini.

@andreialecu
Copy link

andreialecu commented Dec 26, 2020

Does using external monitors affect memory usage? I would be using 2 4k monitors with the 8gb ram and I am quite worried between webstorm, one simulator, couple of tabs in safari I might slow down the M1 Mac mini.

I'm also using 2 4k monitors. I don't have anything to compare it with, but I don't notice any glaring issues.

I usually have a simulator and couple of VSCode windows open, and probably 10-20 Chrome tabs open. Like mentioned previously, it seems like the biggest memory hog is the web browser, and I definitely need to manage my tabs better vs my previous i7 with 32GB of RAM.

So I'll definitely be looking to upgrade to the 16GB model. However, besides the occasional 1-2 second mini stutters while it is swapping it's not a huge problem. I didn't run into any complete blockers because of the limited ram.

Here's how the memory tab in Activity monitor looks like with:

  • 3 x VSCode on three big monorepos
  • 3 x nodejs apps running (react native, angular, nestjs)
  • Chrome with 16 tabs + 1 DevTools window open
  • MongoDB Compass
  • Microsoft Outlook
  • Microsoft Word
  • Slack
  • Discord

Screenshot 2020-12-26 at 16 40 07

A bit extreme on the swap usage, but hardly any performance degradation.

@asterisx
Copy link

Does using external monitors affect memory usage? I would be using 2 4k monitors with the 8gb ram and I am quite worried between webstorm, one simulator, couple of tabs in safari I might slow down the M1 Mac mini.

I'm also using 2 4k monitors. I don't have anything to compare it with, but I don't notice any glaring issues.

I usually have a simulator and couple of VSCode windows open, and probably 10-20 Chrome tabs open. Like mentioned previously, it seems like the biggest memory hog is the web browser, and I definitely need to manage my tabs better vs my previous i7 with 32GB of RAM.

So I'll definitely be looking to upgrade to the 16GB model. However, besides the occasional 1-2 second mini stutters while it is swapping it's not a huge problem. I didn't run into any complete blockers because of the limited ram.

Here's how the memory tab in Activity monitor looks like with:

  • 3 x VSCode on three big monorepos
  • 3 x nodejs apps running (react native, angular, nestjs)
  • Chrome with 16 tabs + 1 DevTools window open
  • MongoDB Compass
  • Microsoft Outlook
  • Microsoft Word
  • Slack
  • Discord
Screenshot 2020-12-26 at 16 40 07

A bit extreme on the swap usage, but hardly any performance degradation.

Ohh nice. Thanks mate for the ram usage screenshot. Yeah the swap usage is high. There is a concern among people that this will trash the SSD but honestly for people like me who are heavy users and wish to keep the machine for 1-2 years it’s not that much of a problem. I am getting a really sick deal on a used m1 Mac mini 8gig version and I will just grab that one. If I were buying a new one though I would definitely buy the 16gigs version, just to make it last a bit longer.

@ecekoprucu
Copy link

I still have issues. After spending hours to make Cocoapods to work, now my build keeps failing with error code 65. I tried every solution suggested (Pod install, changing build settings, using Rosetta etc.) still no luck.

Any help is appreciated from anyone who experienced the same and managed to solve this issue.

@OKNoah
Copy link

OKNoah commented Jan 2, 2021

I'm a little confused about whether people are saying they got things working natively or with Rosetta. Cause folks make it sound like they got things going arm64 style, but then. people are posting guides on how to just retreat to x86_64. So it's weird. Folks are also saying they can do just make a fresh React Native project and it works out of the box (minus Flipper). It seems like there's something I'm missing.

@andreialecu
Copy link

andreialecu commented Jan 2, 2021

I'm definitely using arm64 end to end with real complex apps.

Based on my experience: I recommend compiling node 15 for arm (nvm install 15), and running via xcode instead of react-native run-ios. Also flipper won't work so it needs to be disabled in the pod file.

If you use vscode and the terminals inside it, make sure to use the insiders version that is compiled for arm64, otherwise the terminals will run under Rosetta.

@AdamGerthel
Copy link

Same for me. I'm running 100% silicon in my project. I'm using node v15 (which supports silicon). The only problem I had was installing pods, which failed because of a Flipper dependency. I removed it and got everything working.

@OKNoah
Copy link

OKNoah commented Jan 17, 2021

Found solution (workaround if you prefer), will publish guide ASAP.

EDIT: My Ghost + Gatsby CI is broken, so I will have to fix tomorrow.

@asterisx
Copy link

Hey, I was able to make everything run natively without needing to install ffi or rosetta. The issue seems to be with the ruby version shipped default with MacOS, I read somewhere that for compatibility reasons it exposes arch as x86. The way I solved this was to brew install latest ruby version, do the exporting of path as brew asks to do and then voila my expo project was running on my device. On the emulator there is some weird error about expo-cli not being able to open expo app.

Screenshot 2021-01-23 at 9 08 25 AM

@hsavit1
Copy link
Author

hsavit1 commented Feb 5, 2021

Update: Flipper v74 should have a fix for arm64 devices

Has anyone tried this?

@SohaibKtb
Copy link

@hsavit1 yes I tried it and it works, also it fixed for me 'event2/event-config.h' file not found issue.

thank you for your help🙏❤️

@hsavit1
Copy link
Author

hsavit1 commented Feb 12, 2021

@SohaibKtb did you not have any problems with OpenSSL? I posted a bug here facebook/flipper#1758 (comment)

@manzars
Copy link

manzars commented Feb 12, 2021

@SohaibKtb @hsavit1 can you guys please tell me how to fix the flipper issue. I did checked the fix for arm64 devices but I didn't get it.

Thank you in advance.

@SohaibKtb
Copy link

@manzars please check here the answers https://stackoverflow.com/a/66071245/11721286

If did not help, please let me know your issue, and will see if I can help you.

@donaldparker
Copy link

After upgrading all the cli tools

node -v  > v15.10.0
brew -v > Homebrew 3.0.2
gem -v > 3.0.3
gem which cocoapods  > /Library/Ruby/Gems/2.6.0/gems/cocoapods-1.10.1/lib/cocoapods.rb

I started a fresh project with RN 0.64.0-rc.3 which still had the reference to the old Flipper version so I upgraded that to v74 per @SohaibKtb post above, which brings me to a new error.

undefined symbols for architecture arm64:
  "protocol descriptor for Swift.ExpressibleByFloatLiteral", referenced from:
      l_got.$ss25ExpressibleByFloatLiteralMp in libYogaKit.a(YGLayoutExtensions.o)
  "associated type descriptor for Swift.ExpressibleByIntegerLiteral.IntegerLiteralType", referenced from:
      l_got.$s18IntegerLiteralTypes013ExpressibleByaB0PTl in libYogaKit.a(YGLayoutExtensions.o)
  "associated conformance descriptor for Swift.ExpressibleByIntegerLiteral.Swift.ExpressibleByIntegerLiteral.IntegerLiteralType: Swift._ExpressibleByBuiltinIntegerLiteral", referenced from:
      l_got.$ss27ExpressibleByIntegerLiteralP0cD4TypeAB_s01_ab7BuiltincD0Tn in libYogaKit.a(YGLayoutExtensions.o)
  "method descriptor for Swift.ExpressibleByFloatLiteral.init(floatLiteral: A.FloatLiteralType) -> A", referenced from:
      l_got.$ss25ExpressibleByFloatLiteralP05floatD0x0cD4TypeQz_tcfCTq in libYogaKit.a(YGLayoutExtensions.o)
  "protocol descriptor for Swift.ExpressibleByIntegerLiteral", referenced from:
      l_got.$ss27ExpressibleByIntegerLiteralMp in libYogaKit.a(YGLayoutExtensions.o)
  "value witness table for Builtin.Int32", referenced from:
      full type metadata for __C.YGUnit in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftCoreImage", referenced from:
      __swift_FORCE_LOAD_$_swiftCoreImage_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftCoreImage_$_YogaKit)
  "associated type descriptor for Swift.ExpressibleByFloatLiteral.FloatLiteralType", referenced from:
      l_got.$s16FloatLiteralTypes013ExpressibleByaB0PTl in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftQuartzCore", referenced from:
      __swift_FORCE_LOAD_$_swiftQuartzCore_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftQuartzCore_$_YogaKit)
  "__swift_FORCE_LOAD_$_swiftDispatch", referenced from:
      __swift_FORCE_LOAD_$_swiftDispatch_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftDispatch_$_YogaKit)
  "method descriptor for Swift.ExpressibleByIntegerLiteral.init(integerLiteral: A.IntegerLiteralType) -> A", referenced from:
      l_got.$ss27ExpressibleByIntegerLiteralP07integerD0x0cD4TypeQz_tcfCTq in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftCoreFoundation", referenced from:
      __swift_FORCE_LOAD_$_swiftCoreFoundation_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftCoreFoundation_$_YogaKit)
  "protocol witness table for Swift.Int : Swift._ExpressibleByBuiltinIntegerLiteral in Swift", referenced from:
      associated type witness table accessor for Swift.ExpressibleByIntegerLiteral.IntegerLiteralType : Swift._ExpressibleByBuiltinIntegerLiteral in __C.YGValue : Swift.ExpressibleByIntegerLiteral in YogaKit in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftObjectiveC", referenced from:
      __swift_FORCE_LOAD_$_swiftObjectiveC_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftObjectiveC_$_YogaKit)
  "__swift_FORCE_LOAD_$_swiftCoreGraphics", referenced from:
      __swift_FORCE_LOAD_$_swiftCoreGraphics_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftCoreGraphics_$_YogaKit)
  "_swift_getForeignTypeMetadata", referenced from:
      type metadata accessor for __C.YGValue in libYogaKit.a(YGLayoutExtensions.o)
      type metadata accessor for __C.YGUnit in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftFoundation", referenced from:
      __swift_FORCE_LOAD_$_swiftFoundation_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftFoundation_$_YogaKit)
  "associated conformance descriptor for Swift.ExpressibleByFloatLiteral.Swift.ExpressibleByFloatLiteral.FloatLiteralType: Swift._ExpressibleByBuiltinFloatLiteral", referenced from:
      l_got.$ss25ExpressibleByFloatLiteralP0cD4TypeAB_s01_ab7BuiltincD0Tn in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftUIKit", referenced from:
      __swift_FORCE_LOAD_$_swiftUIKit_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftUIKit_$_YogaKit)
  "__swift_FORCE_LOAD_$_swiftMetal", referenced from:
      __swift_FORCE_LOAD_$_swiftMetal_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftMetal_$_YogaKit)
  "Swift.Float.init(Swift.Double) -> Swift.Float", referenced from:
      static (extension in YogaKit):CoreGraphics.CGFloat.% postfix(CoreGraphics.CGFloat) -> __C.YGValue in libYogaKit.a(YGLayoutExtensions.o)
      (extension in YogaKit):__C.YGValue.init(CoreGraphics.CGFloat) -> __C.YGValue in libYogaKit.a(YGLayoutExtensions.o)
  "__swift_FORCE_LOAD_$_swiftDarwin", referenced from:
      __swift_FORCE_LOAD_$_swiftDarwin_$_YogaKit in libYogaKit.a(YGLayoutExtensions.o)
     (maybe you meant: __swift_FORCE_LOAD_$_swiftDarwin_$_YogaKit)
  "protocol witness table for Swift.Float : Swift._ExpressibleByBuiltinFloatLiteral in Swift", referenced from:
      associated type witness table accessor for Swift.ExpressibleByFloatLiteral.FloatLiteralType : Swift._ExpressibleByBuiltinFloatLiteral in __C.YGValue : Swift.ExpressibleByFloatLiteral in YogaKit in libYogaKit.a(YGLayoutExtensions.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@radko93
Copy link

radko93 commented Feb 23, 2021

I also have this issue, happens with Swift projects (also on 0.63)

@Ovsdrak
Copy link

Ovsdrak commented Feb 26, 2021

Same as above, I have this issue with the latest version of Flipper 0.77.0, and RN 0.63.
Captura de Pantalla 2021-02-26 a la(s) 13 39 58

To get it work I had to use a terminal/Xcode with Rosetta, but it would be nice if it works with arm.

@flavio0567
Copy link

flavio0567 commented Mar 2, 2021

❯ brew Homebrew 3.0.3
❯ node v14.16.0
❯ gem 3.2.7
❯ gem which cocoapods /Library/Ruby/Gems/2.6.0/gems/cocoapods-1.10.1/lib/cocoapods.rb

image

image

image

Still trying to figure out how to run my react-native projects on Mac Silicon M1

@SohaibKtb
Copy link

SohaibKtb commented Mar 2, 2021

@flavio0567 the error appears in Flipper-Folly, try specifying Flipper version, the instructions are in this answer: https://stackoverflow.com/a/66071245/11721286,

if didn't help try specifying Flipper-Folly version this way:

use_flipper!({ 'Flipper-Folly' => '2.3.0' }) # update this part
 post_install do |installer|
   flipper_post_install(installer)
 end

@flavio0567
Copy link

@SohaibKtb I changed the Podfile with your suggestion, reinstalled pods and now one of the problems disappeared. Last de second one. Still trying to solve this 'atomic_notify_one' is unavailable.

many thanks.

@sunilkhuwal
Copy link

H

Same as above, I have this issue with the latest version of Flipper 0.77.0, and RN 0.63.
Captura de Pantalla 2021-02-26 a la(s) 13 39 58

To get it work I had to use a terminal/Xcode with Rosetta, but it would be nice if it works with arm.

I was able to solve this problem by following the below steps:
1 - With Xcode closed (Important) Go to finder -> Applications
2 - Right Click on Xcode and select "Get Info"
3 - On the info panel check "Open using Rosetta"
4 - Double Click in the bottom large preview of the info panel.
5 - Actions to install Rosetta will be responsive.

Hopefully this might help other guys who are facing the similar problem with M1 chip based mac pros

@radko93
Copy link

radko93 commented Mar 6, 2021

@sunilkhuwaln running in Rosetta is not really a workaround, all benefits are lost

@sunilkhuwal
Copy link

I'm new to apple community, could you or someone else pls share what am I loosing while choosing Rosetta?

@OKNoah
Copy link

OKNoah commented Mar 7, 2021

I'm new to apple community, could you or someone else pls share what am I loosing while choosing Rosetta?

Use the 3 commands that all issues on the topic describe, which is prefix with arch -x86_64 when doing pod install and/or some related installed commands, and if it's an RN project, remove Flipper.

@lubomyr
Copy link

lubomyr commented Mar 29, 2021

In my case for RN 0.64 (in native mode without rosetta) helped only creating empty swift file in project and removing LIBRARY_SEARCH_PATHS = ... in project.pbxproj
this solution i found by url https://www.gitmemory.com/issue/Agontuk/react-native-geolocation-service/226/740101556

зображення

@BigMrRob
Copy link

BigMrRob commented Apr 3, 2021

Hey, Wanted to post this here because I finally found the solution for me after what seems like decades of searching.
It has something to do with the podspec of Flipper (Mind you Im not well versed in all of this) , but the following change to my podfile worked:

(You can completely remove the useFlipper function, or do the below)

For Apple Silicon (M1 Chips):
This issue is caused by an update to the "Flipper-Folly" pod-spec. If you'd like to keep Flipper enabled, you can override the version in your Podfile:

use_flipper!({ 'Flipper-Folly' => '2.3.0' })

Also, remove Pods/ & Podfile.lock, then run npx pod-install

@hsavit1 hsavit1 closed this as completed Apr 3, 2021
@Naomarik
Copy link

In my case for RN 0.64 (in native mode without rosetta) helped only creating empty swift file in project and removing LIBRARY_SEARCH_PATHS = ... in project.pbxproj
this solution i found by url https://www.gitmemory.com/issue/Agontuk/react-native-geolocation-service/226/740101556

зображення

New M1 Macbook with latest updates and a new RN project with latest dependencies, these are the only two steps I've found to get RN to compile on the IOS simulator. Thanks so much for posting this, this is the only answer that works after many hours of searching.

Before finding this I found that selecting this works but there's no debug menu.
image

@Nico-Guyon
Copy link

In my case for RN 0.64 (in native mode without rosetta) helped only creating empty swift file in project and removing LIBRARY_SEARCH_PATHS = ... in project.pbxproj
this solution i found by url https://www.gitmemory.com/issue/Agontuk/react-native-geolocation-service/226/740101556

зображення

Same here, this is the only answer that allowed me to have a native version of a RN application running on the simulator.
Previously I was using the excluded architecture arm64 as a workaround but this means that the application was running as an Intel process through rosetta2.

I may have to run some additional tests, but the app feels way faster already.

@piyushchauhan2011
Copy link

piyushchauhan2011 commented Apr 28, 2021

Above worked for me except I had to disable flipper in Podfile and do pod install in ios folder. Probably there is new version but I didn't invest time installing it but it will be nice to have debugging capabilities with Flipper Folly

Thanks @Nico-Guyon

@radiosilence
Copy link

radiosilence commented Jun 9, 2021

I am still getting issues installing glog with cocoapods:

Installing glog (0.3.5)
[!] /opt/homebrew/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/bin/ginstall -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/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
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/jc/Library/Caches/CocoaPods/Pods/External/glog/2263bd123499e5b93b5efe24871be317-73c24/missing: Unknown `--is-lightweight' option
Try `/Users/jc/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.5.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin20.5.0 failed

This is in a Rosetta terminal.app.

@rwschmitz
Copy link

H

Same as above, I have this issue with the latest version of Flipper 0.77.0, and RN 0.63.
Captura de Pantalla 2021-02-26 a la(s) 13 39 58
To get it work I had to use a terminal/Xcode with Rosetta, but it would be nice if it works with arm.

I was able to solve this problem by following the below steps:
1 - With Xcode closed (Important) Go to finder -> Applications
2 - Right Click on Xcode and select "Get Info"
3 - On the info panel check "Open using Rosetta"
4 - Double Click in the bottom large preview of the info panel.
5 - Actions to install Rosetta will be responsive.

Hopefully this might help other guys who are facing the similar problem with M1 chip based mac pros

I'm using a Macbook Air with the M1 chip and this allowed a fresh copy of a React Native app to run in the simulator!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🗣 Discussion This label identifies an ongoing discussion on a subject
Projects
None yet
Development

No branches or pull requests