Can't build react-native project for ios 11

[macrozone]

Is this a bug report?

yes

Have you read the Contributing Guidelines?

yes

Environment

1. react-native -v: react-native: 0.47.1
2. node -v: v6.11.2
3. npm -v: 3.10.10
4. yarn --version: 0.27.5

• Target Platform: ios 11
• Development Operating System: macOS 10.12.6
• Build tools: xCode Version 9.0 beta 6 (9M214v)

Steps to Reproduce

I created an expo app with create-react-native-app

and ejected it to use expokit: yarn eject. Goal was to use arkit in this project (IOS).

In xcode i run it on a real device.

Expected Behavior

It should build

Actual Behavior

Build in xcode fails with

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_RCTSRWebSocket", referenced from:
      objc-class-ref in libReact.a(RCTInspectorPackagerConnection.o)
  "_OBJC_CLASS_$_RCTReconnectingWebSocket", referenced from:
      objc-class-ref in libReact.a(RCTPackagerConnection.o)
ld: symbol(s) not found for architecture arm64

[macrozone]

I managed to fix it.

I forgot to mention that I needed to do this step here:

https://stackoverflow.com/a/41488258/1463534

but i had to react-versions there, one from pods and one that i added manually to libraries. moving to the pods version fixed the issue here.

[macrozone]

i was too early. My coworker checked it out and could not build it. I know did a clean and can't build it again with the same error. Very weird.

[hramos]

0.48 is the newest version, can you try with the latest release and update your issue accordingly if it repros?

[djalmaaraujo]

Having the same issue, after upgraded xcode 9, my project won't work again.

[devyu]

@djalmaaraujo @macrozone It's a strange question but I just fix it. In Xcode 9,Select your project target -> Build Settings -> Other Linker Flags . Add -ObjC complication arguments in debug mode.It is worked for me.

----------- update -------------
If it can not work, try reduce your node version and rm -rf node_module && npm install

[macrozone]

Thanks all for your replys.

I could fix it. As mentioned, expo uses cocoapods for react dependencies.

(DISCLAIMER: i am very new to react-native and ios development and could be totally wrong)

third party react-native libraries might reference react header files in their "Header Search Paths" by looking into "$(SRCROOT)/../../react-native/React/**",

This seems to fail on cocoapods project. They need to search for the header files in "../../../ios/Pods/Headers/Public/**", which is the relative path from the libraries folder inside node_modules to the Pods directry inside your project.

If i add this folder to external libraries, it just builds fine. Do NOT do anything like this: https://stackoverflow.com/a/41488258/1463534 (link from above) as this might lead to other build errors like the one mentioned above.

[bitcrumb]

I'm getting the same errors after upgrading existing project to 0.48.3.
I'm using a Podfile with only 'Core' and 'DevSupport' subspecs of react native. The other libraries are included via Xcode. I've tried removing CocoaPods entirely, but it keeps giving me the same error as above.

[djalmaaraujo]

I fixed by upgrading react-native to new versions.

[hramos]

Closing as original author was able to resolve their issue. Please open a new issue with new details if you run into a similar problem.

[maraujop]

I'm experiencing this @macrozone 's error. It is true that his answer in stackoverflow fixes the compilation issue.

However, when I start the app I see Native module cannot be null. If I dismiss the error then I get.
No component found for view with name "RCTText". All these errors are clearly produced by bad linking that is not triggered in compilation phase.

My setup is:

• XCode 8.2.1
• IPhone 5s iOS 10.3.2

I'm using Cocoapods for react-native with subspecs like this:

  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'BatchedBridge',
    'DevSupport',
    'RCTText',
    'RCTImage',
    'RCTNetwork',
    'Core',
    'RCTWebSocket',
  ]

My feeling is that something is not correct with cocoapods, and this is causing the problems. But not sure what. The funniest thing for me is that buddybuild compiles my project without issues at all.

Maybe this helps someone shed some light on this. I wouldn't say this issue is closed.

[maraujop]

Ok, I've just updated to:

• Xcode 8.3.3
• node 6.11.1
• mac OSX High Sierra

My application is using RN 0.48.4 (lastest available today)

It hasn't worked, still the same linker error

[maraujop]

Ok, I got it to work adding all my podspecs dependencies as .xcodeproj to Libraries and linking them in binaries, the old fashioned way. I had to add RCTText, RCTNetwork, RCTWebSocket, RCTImage...

When I do this it compiles perfect in my local machine, but now it fails in buddybuild with duplicate symbols:

ld: 295 duplicate symbols for architecture arm64

Errors like this one:

duplicate symbol _OBJC_IVAR_$_RCTWebSocketModule._sockets in

It is obvious to me, that something is wrong with my local cocoapods, not sure what. Buddybuild states to use the same version as in my Podfile.lock and iOS project settings are the same. So it has to be a bad local cache or some magic they do.

[dotansimha]

Same here with High Sierra, 0.48.4 and XCode 11.
Simulator works fine, when trying to Archive the app, then the linker errors appears.
Tried with node 6/7/8.

[maraujop]

Today I found out, that it archives correctly using xcodebuild. So If I do:

xcodebuild archive -scheme Debug -workspace MYPROJECT.xcworkspace -configuration Debug BITCODE_GENERATION_MODE=bitcode ONLY_ARCHIVE_ARCH=NO -jobs 2 DEBUG_INFORMATION_FORMAT=dwarf-with-dsym

However if I remove archive, it fails with:

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_RCTReconnectingWebSocket", referenced from:
      objc-class-ref in libReact.a(RCTPackagerConnection.o)
  "_OBJC_CLASS_$_RCTSRWebSocket", referenced from:
      objc-class-ref in libReact.a(RCTInspectorPackagerConnection.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@dotansimha I believe latest XCode is version 9, I've tried that too.

I'm quite confident this is not related to XCode, mac os version or node. It's some XCode build setting or something like that.

[dotansimha]

I believe I managed to find a solution for this, the final issue is either 2 libReact.a during linkage, or 0.

My Podfile contains this now:

  pod 'DoubleConversion', :podspec => react_native_path + '/third-party-podspecs/DoubleConversion.podspec'
  pod 'GLog', :podspec => react_native_path + '/third-party-podspecs/GLog.podspec'
  pod 'Folly', :podspec => react_native_path + '/third-party-podspecs/Folly.podspec'

  pod "Yoga", :path => "#{react_native_path}/ReactCommon/yoga"
  pod 'React', :path => '../node_modules/react-native'

  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'Core',
    'DevSupport',
    'CxxBridge',
  ]

Also, with this in the end, to avoid libReact.a compiled in the Pod project:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == "React"
      target.remove_from_project
    end
  end
end

Then, my XCode project is using libReact.a and libRTCWebSocket.a:

This way, I managed to finally be able to both run in Simulator and Archive for the store...

Using XCode 9, RN 0.48.4, compiling the xcodeworkspace.

@maraujop

[maraujop]

Thanks @dotansimha You are right! there is a combination of libraries in cocoapods and libraries manually linked in Libraries in XCode, that gets both the simulator and archive working in all schemes. I'm finally out of the hole!

Thank you so much!

[shahme]

I was having the same problem the and did not have a pod file, I was able to build the app by placing libRCTWebSocket.a before libReact.a

[msand]

An alternative solution where the "target.remove_from_project" part can be skipped, is to have two targets, one for cocoapods, where the react modules aren't manually linked, allowing for release build and archive, and another for debugging where they are manually linked. Release build / archive might still require issuing the command using the CLI, but at least it can be manually installed to the simulator, and shows up in the organizer.