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!

[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.

[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.

[mikehardy]

@jspizziri apologies for the delay, you (and anyone else listening here) have been patient.

We've been discussing this internally to schedule the effort and we have a draft PR plus time allocated, this item is in development currently.

I hesitate to give ETAs ever in software development, but for the purposes of recruiting testers I'd like to know if anyone is available to test our work if we were to have test builds available later today (it's 9am my time as I type this - so in a few hours) and going forward?

We are sadly constrained by not having Apple Silicon to test ourselves but there appears to be a rough consensus on the best way to do this and we believe we can have it done quickly, with the exception of testing/verification.

[mikehardy]

For adventurous testers only but this works for me (macOS BIgSur 11.1/Xcode 12.3/x86_64 simulator + physical iPhone SE arm64/iOS 14.3) integrated into my main app when doing local debug and TestFlight release builds:

1. Alter your package.json dependency to be like this:

    "@notifee/react-native": "notifee/react-native-notifee.git#@helenaford/xcframework-draft",

2. add a postinstall step to package.json like this:

    "postinstall": "cd node_modules/@notifee/react-native && yarn"

(although mine actually looks like this, as I use patch-package plus a jetify for good measure:

    "postinstall": "patch-package && jetify && cd node_modules/@notifee/react-native && yarn"

)
3. ...it should work on Apple Silicon now for simulators and ios

There is an unresolved problem with maccatalyst builds at the moment @ajnozari so this likely will not work for you yet but it is very close, just a matter of file locations / symbolic links not copying correctly

[mikehardy]

@dcloux / @jspizziri if either of you have time, there is a test branch we would love feedback on ☝️ . The only change from 0.15.2 official release is how we package the library, so if 0.15.2 was working otherwise but failed on Apple Silicon (arm64) Macs when you tried to use those as development / simulator hosts, it should work for you. We're just looking for confirmation from someone to publish these changes

[jspizziri]

@mikehardy thanks for the updates here. Some additional info that we've discovered since my original comment:

The issue only seems to be happening for us when we're trying to build & run for a simulator while also in Release mode. Building and running for simulators in Debug mode doesn't seem to be an issue. Lastly, we're able to build successfully for a generic device in Release mode and publish to the AppStore. So far none of those builds have had any issues when running on various devices via TestFlight.

So for now it seems that we (at least) have a path forward provided I'm not missing something.

Regarding the testing however, I will definitely try to check it out but we're in the midst of launch prep and unless this becomes a blocker for that again I won't be able to provide feedback until after the release is finished.

[mikehardy]

@jspizziri okay - that makes sense and I understand the time crunch. The previous packaging style made some decisions about which slices to keep for which configurations and should always work in release on real devices, so that should explain your behavior. The new packaging should work in all combinations though without worrying about host, target, or debug vs release

[mikehardy]

We would still love feedback from anyone that test integrates via the instructions above #162 (comment) - specifically I just re-pushed to that branch and now Mac Catalyst builds should be working as well.

Thanks!

[ajnozari]

I’ll test it out in a bit just saw this!

[helenaford]

Thanks @ajnozari. It's now possible to test this with the pre-release 0.16.0-0 so no need for the post-install step.

[ajnozari]

@helenaford, I'm trying 0.16.0-0 but it's giving me an issue

'NotifeeCore/NotifeeCore.h' file not found

[helenaford]

Ah interesting 🤔 Do you get an issue with using this branch following @mikehardy's steps above?

[ajnozari]

@helenaford Yes, it gives me the same error. I see that @mikehardy mentioned an unresolved error, could that still be the potential issue?

[helenaford]

@ajnozari possibly. thanks for testing. Will leave it with Mike to comment further regarding the Mac Catalyst issue.

[mikehardy]

I'm still 99% sure this is working for Apple Silicon now - I'd love to hear feedback on that but I assume it's working now.

For macOS Catalyst builds I am of course less sure and your feedback is disappointing (professionally) since I was pretty sure I'd nailed it with this line! I'll get it though...

@ajnozari I'm digging through the internet trying to find a good starter project template I can use that's enabled for Catalyst, are you aware of one? I can't seem to find a good one so I don't have a good test rig set up to make sure I actually solve this. I can generate my own but I don't want to reinvent the wheel if you have experience here and know of one.

You can see the header file is here so I think we're close - something about symbolic links or file locations or git + symbolic links interaction is going to be the problem.

[ajnozari]

@mikehardy take a look in the xcframework. iOS-arm64_x86_64-maccatalyst's folder structure differs from the ios-arm64_armv7 and the simulator folders.

This would explain the error as NotifeeCore.h is in NotifeeCore.framework/Versions/A/Headers/NotifeeCore.h not NotifeeCore.framework/Headers/NotifeeCore.h, and it seems that Xcode is either ignoring the sym links, or not following them properly.

To answer our question about another example React-native-webrtc is also working on this and they too have a podspec. They're having other issues due to webrtc but they do link.

[mikehardy]

@ajnozari - yes, that's what we've been looking at, it's clearly something to do with that, our questions are about best way to solve it since this (those subdirectories, with a different layout than the ios builds) appears to be the way Xcode builds catalyst frameworks by default.

1- should we bend the catalyst headers layout to match the others? (seems like the wrong direction, we're fighting the build system...but would probably work and might be "good enough", you could try it by just manually copying them)
2- should we add the catalyst header directories to the include path for catalyst builds via podspec directives? This could work but is untested
3- and of course we need to be absolutely certain that the layout is correct after traveling from xcodebuild of Notifee core to the react-native module through a git commit, a git checkout, and then a pod install. There were problems during those transformation steps prior - we think we've worked them out but it needs careful checking

If you wanted to just manually copy the header files a la item 1 above into the directory or add the Versions/Current/Headers directory to the path (Current should be a stable symbolic link to the 'A' directory...) a la item 2, both might solve it for you locally this moment, and the feedback would be great

[ajnozari]

So when I remade the symlinks in my node_modules, Xcode found the framework, but then complained that were building for catalyst, but are giving macOS frameworks. I think catalyst needs x86_64 iOS frameworks to be generated, since it’s technically compiling the iPad app for macOS.

…

Sent from my iPhone On Jan 3, 2021, at 9:53 PM, Mike Hardy <notifications@github.com> wrote:  @ajnozari<https://github.com/ajnozari> - yes, that's what we've been looking at, it's clearly something to do with that, our questions are about best way to solve it since this (those subdirectories, with a different layout than the ios builds) appears to be the way Xcode builds catalyst frameworks by default. 1- should we bend the catalyst headers layout to match the others? (seems like the wrong direction, we're fighting the build system...but would probably work and might be "good enough", you could try it by just manually copying them) 2- should we add the catalyst header directories to the include path for catalyst builds via podspec directives? This could work but is untested 3- and of course we need to be absolutely certain that the layout is correct after traveling from xcodebuild of Notifee core to the react-native module through a git commit, a git checkout, and then a pod install. There were problems during those transformation steps prior - we think we've worked them out but it needs careful checking If you wanted to just manually copy the header files a la item 1 above into the directory or add the Versions/Current/Headers directory to the path (Current should be a stable symbolic link to the 'A' directory...) a la item 2, both might solve it for you locally this moment, and the feedback would be great — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#162 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRDXJ2PU4KNRRSMFJFYUTSYEUTZANCNFSM4SD22LSA>.

[mikehardy]

Interesting - thanks for checking at any rate, sorry the results weren't better. We are definitely on it - Helena and I are both poking around at this as current work item. Irony is that in order to generate catalyst framework you do have to specify a macos flavor, and we're doing things by the book there

echo "Archiving for Mac Catalyst"
xcodebuild archive -workspace "./${FRAMEWORK_NAME}.xcworkspace" -scheme ${BUILD_SCHEME} -configuration Release \
  -destination='platform=macOS,arch=x86_64,variant=Mac Catalyst' -archivePath "${CATALYST_ARCHIVE_PATH}" \
  SKIP_INSTALL=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES

example from internet including the same, with Apple verification https://developer.apple.com/forums/thread/120542

we'll get there!

[mikehardy]

So I did this:

1. https://github.com/mikehardy/rnfbdemo/blob/master/notifee-demo.sh
2. changed package.json notifee dependency to 0.16.0-0
3. pushd node_modules/@notifee/react-native/ios/NotifeeCore.xcframework/ios-arm64_x86_64-maccatalyst/NotifeeCore.framework && cp -rv Versions/A/* . && popd
4. opened the Podfile and disabled Flipper
5. ran pushd ios && pod install && popd
6. open the .xcworkspace and toggled on 'ipad' and 'macos' targets (also set my development team here...)
7. built it and...it ran just fine! I click the link and get a notification

Witness: https://youtu.be/KL4neid0MC4

I'm not sure why the directory structure xcodebuild generates has the Versions/A / Versions/Current in it, but if you collapse those directories, what we've already published works for me on catalyst.

@ajnozari (or @helenaford) If you could try step 3 there and pod install / rebuild it should work, or failing that, those 7 steps should result in success for you too.

Once I see we are reproducing success with at least one style of catalyst support we'll have a solid foundation to build on.

[ajnozari]

Mike, I gave it another test and the app seems to build past notifee now, I can’t confirm 100% as I’m waiting for another package to update to xcframework now, but it is getting pat notifee in the compiler so I’m going to take that as a positive until the other package updates. Andre

…

Sent from my iPhone On Jan 5, 2021, at 6:42 PM, Mike Hardy <notifications@github.com> wrote:  So I did this: 1. https://github.com/mikehardy/rnfbdemo/blob/master/notifee-demo.sh 2. changed package.json notifee dependency to 0.16.0-0 3. pushd node_modules/@notifee/react-native/ios/NotifeeCore.xcframework/ios-arm64_x86_64-maccatalyst/NotifeeCore.framework && cp -rv Versions/A/* . && popd 4. opened the Podfile and disabled Flipper 5. ran pushd ios && pod install && popd 6. open the .xcworkspace and toggled on 'ipad' and 'macos' targets (also set my development team here...) 7. built it and...it ran just fine! I click the link and get a notification Witness: https://youtu.be/KL4neid0MC4 I'm not sure why the directory structure xcodebuild generates has the Versions/A / Versions/Current in it, but if you collapse those directories, what we've already published works for me on catalyst. @ajnozari<https://github.com/ajnozari> (or @helenaford<https://github.com/helenaford>) If you could try step 3 there and pod install / rebuild it should work, or failing that, those 7 steps should result in success for you too. Once I see we are reproducing success with at least one style of catalyst support we'll have a solid foundation to build on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#162 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAKRDXKQ7LQGGLIFDHOQFXLSYOPXDANCNFSM4SD22LSA>.

[helenaford]

Release v0.16.0 includes support for arm64 architecture.

[thuynt99]

'NotifeeCore/NotifeeCore.h' file not found. i try version v1.16.0 v1.15.2 v2.0.0

[mikehardy]

Interesing @thuynt99 - there is no v1.16.0, v1.15.2 or v2.0.0. Those version simply don't exist.

Also, @helenaford now has an Apple Silicon rig for personal use and has tested the work, if you were testing builds on Apple Silicon for Simulator, that should work and Helena has confirmed it.

if you were testing for macOS Catalyst builds then that should work also, I personally verified them

I suspect there is something wrong in your local project? All I can think of is perhaps a pod deintegrate && pod install or similar, using the current stable version that exists which should be v1.0.0 as I type this