Will Notifee support the arm64 architecture?

[dcloux]

Hello,

I'm trying to port an RN application to a DTK with an Apple silicon processor.
Unfortunately, Xcode refuses to compile my application with the following message:

ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/me/git/myapp/node_modules/@notifee/react-native/ios/NotifeeCore.framework/NotifeeCore' for architecture arm64

Will Notifee soon support the arm64 architecture?

Thank you for your answers!

[mikehardy]

That's interesting + new to me. I ran through a bunch of Apple developer forums threads and stack overflow and I'm not sure what the recommended state of the art is for a fix here.

There were quite a few mentions that if there was 'arm64' in the excluded arches for build targets in Xcode project settings, to remove that for debug with a side effect that you can't deploy debug builds to a real device (so not a great solution)

This was the best / most informative post I've seen so far:

https://stackoverflow.com/a/64139830/9910298

It appears @dcloux that you could put this stanza in your Podfile:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings["ONLY_ACTIVE_ARCH"] = "YES"
    end
  end
end

...per that linked stack overflow answer, and you should be able to bulid and run.

I want to emphasize this is an experimental change - it may impact how the app runs on devices when released via TestFlight

I put that in bold because I didn't see any confirmation from people that this solution (or the more surgical ones in the podspec) worked in all combos of apple silicon or x86 silicon building debug or release to simulator on apple silicon or x86 silicon or real device armv7 or arm64-v8. That full combo matrix needs confirmation before I will be confident in it.

Can you report any all success you have? If it's a total failure and we need to change our build of the core lib that's also a valuable result and we'll investigate further to move this forward

[dcloux]

Thx for your answer!

I did some tests. Exclude ARM64 architecture is not a good idea:

And the stanza in my Pod file doesn't work (error comes quickly on build...):

ld: library not found for -lRNNotifee clang: error: linker command failed with exit code 1 (use -v to see invocation)

Is it possible that people on the linked issue on Stackoverflow use Xcode 12 on an Intel Mac? I'm working on an Apple DTK with an ARM64 Apple Silicon processor... Not only the target processor is ARM64 but the compiling processor is ARM64.

[mikehardy]

I wish everyone on that stackoverflow had organized their discussion around a matrix of host + target + release mode tuples and then noted which workaround worked (or was terrible!) for which part of the matrix. Many of the workarounds were ill-specified with regards to which tuple they would allow progress on.

I fear there may be something we need to do in our core library / framework generation procedure then, but this is going to be difficult for us because I don't have arm64 / "apple silicon" host and I'm not sure anyone @ Invertase does 😞 - @Salakar sorry to rope you in, but perhaps you already know what needs to be done to support arm64 hosts with a react-native notifee integration, or you can lay your hands on a host to use as a test rig?

Not-really-helpfully I will add that Apple's plan to make all us developer purchase new harder appears to be working 🤔

[helenaford]

I think this has to do with Xcode 12, and the way the bundle is being built to a .framework and not a .xcframework. This article sums it up well (https://apontious.com/2020/08/23/arm-wrestling-your-ios-simulator-builds/). In the last build, I had to add EXCLUDED_ARCHS=arm64 due to the Xcode update.

If we convert the bundle to a .xcframework should fix it, which "should" be testable on both types of machines/hosts.

[mikehardy]

I separately checked to see how / if this was handled in cocoapods and it looks like it's in flux as they changed it between cocoapods 1.9 and 1.10 but since 1.10 is still rc1 and not generally available, integrating it in the 1.9 style should work? https://blog.cocoapods.org/CocoaPods-1.9.0-beta/

we're already using the vendored_frameworks thing so "should" "just" be a matter of rebuilding and altering it to xcframework and it'll work (scare quotes intentional)

[Guuz]

Hello :) We are also experiencing the same issue as described above.

ld: building for iOS Simulator, but linking in dylib built for iOS, file '/Users/guus/Projects/ApotheekInJeBroekzak/node_modules/@notifee/react-native/ios/NotifeeCore.framework/NotifeeCore' for architecture arm64
We can't run our Detox tests since xcode 12 and while using Notifee because that uses a Release build.

It's all very confusing, but i still cant find a solution as to what to do. And if the end-user (app developers) or the package-creators should fix something.

I know a lot of packages had to change this:

See the following as an example: FormidableLabs/react-native-app-auth#562
Is this something Notifee needs to do too?

[mikehardy]

If that could fix it and is a problem then I think you could see it right in the podspec in node_modules and try to fix it directly as a test? Patch-package could then be used until we adopt it. I don't believe that is the issue though

[helenaford]

hmm, no I don't think that's the same issue. That fix above looks like a React related issue. And, I believe we have 'React-Core' in our dependencies. For us to support arm64 we need to bundle the internal library differently to support arm64 which we are looking into. Will post here when there's updates and a release.

[jspizziri]

@helenaford any updates on this? We need to make a decision if we need to rip out Notifee for app launch or not, as we can't build on any new devices.