App build fails on iOS 14.5

[cigaciga]

I'm having an issue after upgrading to Xcode 12.5 and iOS 14.5, build is failing with error:

Undefined symbols for architecture x86_64:
"Swift._ArrayBuffer._copyContents(initializing: Swift.UnsafeMutableBufferPointer) -> (Swift.IndexingIterator<Swift._ArrayBuffer>, Swift.Int)", referenced from:
generic specialization <serialized, Swift._ArrayBuffer<Swift.Int8>> of Swift._copyCollectionToContiguousArray(A) -> Swift.ContiguousArray<A.Element> in libMixpanel-swift.a(AutomaticProperties.o)
ld: symbol(s) not found for architecture x86_64

[taschik]

We discovered the same here, too.

[AndreasGS]

+1. Disabled mixpanel until it's fixed

[VincentQuillien]

same here

[zihejia]

Sorry guys! We are looking into this now.

[mavarazy]

+1

[kkelley-leftbrain]

Hey all - there appears to be some workarounds for 0.64 and at least in my case, 0.63.3 found in the thread mentioned above. My solution was pulled from a lot of folks across a few issues, found here.

@zihejia not sure if this is potentially the solution here, as a lot of the pain is coming from the Big-Sur automatic updates jacking with XCode and a cascading number of libraries coupled with it. Always appreciate the work you guys are doing, thank you for the support

Cheers

[zihejia]

Thanks @kkelley-leftbrain and everyone who brought this up and provided the valuable information. Here is the workaround based on the threads. Tested in Xcode 12.5 and RN 0.64

• open the iOS project/workspace project file

• go to the Build Settings of your project, search for Library Search Paths

• remove $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)
  

• add an empty swift file to your iOS target and create the Bridging Header when prompt
  

[zihejia]

Feel free to reopen if the above solution doesn't work, or contact our support if you need to continue the conversation for any critical issues.

[checklist]

Thanks @kkelley-leftbrain and everyone who brought this up and provided the valuable information. Here is the workaround based on the threads. Tested in Xcode 12.5 and RN 0.64

• open the iOS project/workspace project file
• go to the Build Settings of your project, search for Library Search Paths
• remove $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)
  
• add an empty swift file to your iOS target and create the Bridging Header when prompt
  

Guys - this has been open since April. It is now August. Shouldn't have this been handled without this extra work?

Thanks in advance.

[jckw]

Should this issue be closed? There might be a work around but this doesn't feel fully solved. Do we know why the workaround works (and what does removing the library path do?)?

[IdrisHanafi]

Using XCode 12.5.1 and RN 0.63.4. @zihejia

Couldn't find the $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) in my Library Search Paths. But I did try adding the bridging header but no luck (same error). Would love to see an updated status on this, thanks! :)

[ekram21]

I Couldn't find the $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) in my Library Search Paths either. If this doesnt get resolved soon I may have to look for alternative to mixpanel.

Any ETA when will be resolved? @zihejia

[zihejia]

hi @ekram21 @IdrisHanafi , would you like to check out the latest issue from RN about this? Unfortunately, this issue has still not been fully resolved and a workaround is still needed. It is not specific to Mixpanel but more related to RN with Xcode.

[mikehardy]

Coming over here from the related react-native issue, we've worked on this for the next release (0.66) of react-native and have implemented the required workarounds in a general way. This affects everyone using react-native so if you can please spread the word to other developers in any other repos you work in to help them out, pointing that related issue and encouraging them to examine the Podfile addition that helps people https://react-native-community.github.io/upgrade-helper/?from=0.65.1&to=0.66.0-rc.4 (check the Podfile workaround line that was added)

[ololoepepe]

@zihejia So you say this is RN and Xcode issue, then how could it be that my project compiled fine with the same RN and Xcode versions until installing Mixpanel? The issue still exists and there is no workaround (at least for Xcode 12.5.1). The methods posted above does not work (at least for my case), as I do not have $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) path nor does the fix from facebook/react-native#31480 help.

[mikehardy]

Perhaps mixpanel is the first Swift code you've ingested @ololoepepe ? There should be no problems like this on react-native 0.66 (released now).

[ololoepepe]

@mikehardy Well, I have more than 60 native modules and some code in AppDelegate.m (if that counts). Surely I have faced some issues from time to time, but none was without a fix/workaround and developers saying "this is not our fault, we will not do anything to fix it".
As for upgrading RN version (mine is 0.64.2), it is hard or even impossible to just upgrade without breaking some package. I know one should upgrade from time to time, but doing it too often is a pain and waste of empolyer's money (especially when some packages break and one have to fix them).

[ololoepepe]

RN 0.66 gives the same error, by the way.

[mikehardy]

I hear you. It's really not easy. Are you certain that on the upgrade to 66 you put the compile workaround function call in your podfile? Have you checked out the archs specifiers I slice in via podfile in react-native-firebase tests podfile? I don't have 60 native modules in my app but I maintain about 30 native modules and in my experience this is an xcode config issue that is out of module's control. I collaborated directly with the react-native team to add workarounds for that reason and we had no fail reports by the time we released 66

[mikehardy]

I have lots of caching so npx react-native-clean-project was needed in my case as well then pod reinstall and I blew away my ccache for good measure.

[ololoepepe]

@mikehardy

Are you certain that on the upgrade to 66 you put the compile workaround function call in your podfile?

Yes, it is there.

this is an xcode config issue that is out of module's control

Well then how do other packages maintainers avoid such issues? I understand there may be a bug in RN, or Xcode, or whatever, but the packages people use do not exist in an isolated space, they exist in the same world as those buggy tools and incorrect (incorrect for what, by the way?) configs.

Say you produce cars, but the roads are not very well and you cars can not be used on those roads. So you say: "I have made a car, and it is not my problem you can not use it on the roads". Then why even produce that car? It is useless in real world outside the factory it was produced at.

I mean, why not change something about the lib to improve it's compatibility, so it is more incorrect-configuration-tolerant? The whole history of this lib's releases consists of "fixed compiling on ios", "fixed what previous improvement have broken" and so on.

[mikehardy]

Just to make sure I did this:

npx react-native init MixPanelTest --version 0.66.0
cd MixPanelTest
yarn add mixpanel-react-native
cd ios && pod install && cd ..
yarn ios

it worked

Other module maintainers don't avoid the issues (they're not avoidable), (so finally) I had to work with the core to fix Xcode builds.

I'm not going to pontificate about metaphors, I don't see build errors when I apply documented workarounds (for RN < 0.66) or have a fresh RN66 app

[ololoepepe]

I've tried react-native-clean-project with exact same results. I have never made any extra changes to xcode/Podfile/whatever-ios-build-related after create-react-native-app my-project, so it's as common and default as possible.

And once again, as for blindly upgrading to the next version of RN, there are issues with other packages (at least appropriate react-native-reanimated release seems to be buggy and causes crashes). You may say again "this is 3rd-party persons who causes this", but wait, again, we all live the same world, and react-native-reanimated is used more often than mixpanel-react-native.

[ololoepepe]

At the end it may be just easier and cheaper for employer to just choose another service with better libs than spending developer's hours (and thus money) fighting with what is just broken.

[mikehardy]

Yep, I patched react-native-reanimated as well: software-mansion/react-native-reanimated#2477 (comment)
But if you stay on lower than react-native 0.66 with reanimated and gradle flavors you have a separate problem.
It's just hard, all this software.
I'm busy fixing things and trying to help you though. Or I was, off to real work now, cheers

[ololoepepe]

@mikehardy

Just to make sure I did this: it worked

• Doctor, I've broken my leg.
• Can not reproduce, I also have a leg and it's just fine.

[mikehardy]

Metaphors are inefficient ways to convey meaning.
We're talking about scientific experiments with reproducible methodologies, that is, scripts here.
You cannot build humans from scratch. This software and all of its dependencies may be built from scratch for a directly reproducible experiment.
I did that.
You can do that with your app too.

[ololoepepe]

For anyone who struggle with this issue: you may use react-native-mixpanel. It is deprecated, but at least it works (without requiring some mysterious right configuration).

[kkelley-leftbrain]

@ololoepepe I really wouldn't recommend that.

I hung out with @zihejia and company whilst they made the transition from closed beta to the public repo, and there is a trove of changes that you would be missing, in addition to operating the underlying API in a non-standard way (see: JS/HTML-esque approach when a fully supported RN version is available for you to use here).

I slogged through a nearly identical plight with the issue mentioned at the very top of the thread, and did my best to link to some other workarounds. @mikehardy has also given you quite a bit to work with here.

Generally speaking, if you're changing versions of RN, or any of your underlying library dependencies, there's going to be some friction and I recommend taking it one step at a time. Save off progress (i.e. commit) at each phase so you can go the nuclear option if things get too jacked up along the way.

If there's anything specifically you're running into, feel free to drop me a line and we can compare notes when I've got a moment.

Cheers

[ololoepepe]

@kkelley-leftbrain While I agree with you generally, there is just too much effort to make this lib work. For me and our company it does not worth time and money spent. I'm not an iOS pro, but I suspect some unusual native things are used by the lib, that's why it requires unusual configuration. At the very least, I suggest the devs add this to the docs, like "change that line to X", "make sure you have Y set to Z", etc. This lib is not the only available (and so is Mixpanel), so why waste our time?
There is a kind of devs who loves all brand-new things and can't live without bringing that things into projects immediately. Often these things break everything (just because some time is needed to test/fix bugs/etc.). Unfortunately, that kind of devs is also very stubborn and never replaces their unusual stuff with something "good old". They love to fight their own tools and thinks others also must like it and have unlimited time to do so.

[mikehardy]

"unusual things" used by this module, in this case === "Swift",

That is, the next major language that will be / is used by all iOS devs

It's just that react-native was a little slow starting to adopt it, and Xcode itself has issues with it at some deep layers (like, they ship iOS Simulator SDKs without the symbols sometimes! It's crazy)

So from that perspective, this is not an unusual requirement, It is something that needs a real solution in your project and that's why I've worked so hard to try to get the required workarounds distributed out to people. At the same time it's just a real difficult area of iOS development at the moment. If other libs haven't hit it, they will.

I personally know of two widely-adopted libs that were bitten by this: the react-native-fbsdk-next and react-native-firebase.

[ololoepepe]

@mikehardy

react-native was a little slow starting to adopt it, and Xcode itself has issues with it at some deep layers

That's why we absolutely have to use it right now. Yep, that's what I was talking about in the previous post.

BTW react-native-firebase is used in my project from the very beginning without any issues.

[mikehardy]

BTW react-native-firebase is used in my project from the very beginning without any issues.

You're welcome ;-). But more seriously if you try to use the newer modules, like App Check - this will happen, right now.

[evanlarkin10]

I'm experiencing this issue, and I can't find $(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME) in the Library Search Paths either from @zihejia answer. Is there any other resolution yet?

[kkelley-leftbrain]

@evanlarkin10 , I had to manually edit my project.pbxproj file manually for that step, not sure if that helps (i.e. Ctrl+F "TOOLCHAIN" within the file in an editor)

[LucasGarcez]

I have the same problem. The only way that works for me was to update macOS to Monterey 12.1, so update Xcode to 13.2.1. No need for other steps, install lib and pods normally.
My project use react-native 0.64.0 and mixpanel-react-native 1.3.4

[zihejia]

Thanks @LucasGarcez for pointing it out. Yes, for anyone who has been impacted please update Xcode to 13.2.1 as long as you can, so there is no need for any extra steps mentioned in this thread. Thanks for everyone's great input and sorry for the inconvenience, special thanks to @kkelley-leftbrain @mikehardy and @LucasGarcez !

[dnlPacheco]

I'm having a problem similar to this error "Undefined symbols for architecture x86_64". Build is failing with this error:

Undefined symbols for architecture x86_64:
 "_RCTRegisterModule", referenced from:
   _initialize_MixpanelReactNative in MixpanelReactNative-7b8382e86c4871ddf502e2111c31c78a0bf98ae8fe355805573d3bbbc4a2d3d1.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I tried to build in 2 different Mac's:

• Big Sur 11.6.2 - Xcode 12.5
• Catalina 10.15.7 - Xcode 12.4

It's the same project using "react-native: 0.63.4" and "mixpanel-react-native": 1.3.7".

After reading this comment in this issue:
facebook/react-native#29633 (comment).

I changed the s.dependency to React-Core in MixpanelReactNative.podspec and the app build successfully.

[ololoepepe]

So finally there is an issue in this lib (incorrect dependency). Not a big surprise though.

[wgley3]

I changed the s.dependency to React-Core in MixpanelReactNative.podspec and the app build successfully.

I was really having an issue with this, and this ended up being the fix. Thanks @dnlPacheco !!

[princefishthrower]

@dnlPacheco @wgley3 , even after doing this modification and running pod update in my ios/ folder, I'm still having troubles. Are there any other steps you may have forgot to mention here?

I'm also worried about the brittleness of this solution, won't the MixpanelReactNative.podspec file get overwritten every time we upgrade mixpanel?

@mikehardy - I see the podfile modification you mentioned, it's called __apply_Xcode_12_5_M1_post_install_workaround(installer) - does this only help M1 macs or will it also help macs in general?

BTW I am on react-native 0.67.2, so I'm not sure how I ran into this issue 😅 (my guess is that my podfile wasn't touched by past upgrade commands because we have so much custom tooling)

EDIT: It gets worse; I indeed DO have this fix line in my Podfile.... so I'm lost for now, maybe I have to do this cache cleaning...

[mikehardy]

the __apply_Xcode_12_5_M1_post_install_workaround(installer) workaround is more of a "12.5+ or M1" workaround, it fixes issues with both, and is modified over time in new react-native versions to only be what's currently required.
You can see it's history here https://github.com/facebook/react-native/blame/main/scripts/react_native_pods.rb#L564-L591

Not sure if you need to, but If you need to patch a podspec, patch-package is your friend https://github.com/ds300/patch-package/ - it will warn you when patches don't apply or versions change so it's not that brittle as it is more "fail fast" as you update. I use it all the time personally.

[paprikka]

Hi there! Am I correct to think that #150 would fix the issue mentioned by @dnlPacheco ?

[paprikka]

I'm on RN 0.68.x, Xcode 13.4. Here's what worked:

1. fork this repo
2. update the podspec file with the patch mentioned in Update MixpanelReactNative.podspec #150
3. use the package from GH

   // in package.json
   - "mixpanel-react-native": "^1.4.2",
   + "mixpanel-react-native": "git+ssh://git@github.com/<your org name>/mixpanel-react-native.git",  

4. clean your pods and reinstall all dependencies $ yarn, then $ arch -x86_64 pod install --repo-update
5. subscribe to the notifications for this repo, so you can drop the fork once it gets updated 🚀💰

[hamzakashifCL]

I am still getting this error with React Native 0.73 and Xcode 15.1