'Undefined symbols for architecture' on iOS

[grahammendick]

I've just started out adding Fabric support to my Navigation router. I created a basic spec file for my NavigationStack component. Then I initialised a test project npx react-native init test --version next and installed my navigation library as a dependency. After running RCT_NEW_ARCH_ENABLED=1 arch -x86_64 pod install (I'm using Mac M1) I can see that these files are generated

For example, here's what ComponentDescriptors.h looks like

#pragma once

#include <react/renderer/components/navigation-react-native/ShadowNodes.h>
#include <react/renderer/core/ConcreteComponentDescriptor.h>

namespace facebook {
namespace react {

using NVNavigationStackViewComponentDescriptor = ConcreteComponentDescriptor<NVNavigationStackViewShadowNode>;

Then I opened up the test workspace in Xcode and ran a build. I was expecting this to generate the Protocol class that I'm to implement. But instead I get the error

Undefined symbols for architecture arm64:
  "_NVNavigationStackViewCls", referenced from:
      _RCTThirdPartyFabricComponentsProvider in libReact-Codegen.a(RCTThirdPartyFabricComponentsProvider.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

If you need any more information just let me know.

[tomekzaw]

Hello! You will also need to implement NVNavigationStackViewComponentView class on iOS which is a wrapper for view manager from the old architecture. As a reference, feel free to check out RNGestureHandlerButtonComponentView in react-native-gesture-handler here. In order to make it work with React-Codegen, you will also need to implement NVNavigationStackViewCls function which will return RNGestureHandlerButtonComponentView.class (see here). Use .mm extension so it compiles as Objective-C++ file and make sure that these files are recognized as source files as well in Podspec (see here). Also, note that we use #ifdef RN_FABRIC_ENABLED in Fabric-specific files as Gesture Handler supports both architectures at once.

[grahammendick]

Hello! Thanks for the quick reply and for all that helpful information. I've got a clean build now so I'm a step further forward!

It wouldn't work with the #ifdef RN_FABRIC_ENABLED left in because then iOS ignored these files. How to I set RN_FABRIC_ENABLED to true? Is this the official way to support both old and new architectures at the same time?

I've been trying to get up and running following the "Supporting the New Architecture in your Library" section in the official docs. But I can't find the invaluable information you just gave me in these guides. Has it been left out on purpose? Should I be looking somewhere else for this information?

Thanks again for you help.

[cipolleschi]

Hi @grahammendick!

we know that the doc on these topics is a bit lacking, we are working on improving it in the next few days.

For your questions: the proper flag is actually RCT_NEW_ARCH_ENABLED, and you can set it to 1 when you install the pods. To do so, just run RCT_NEW_ARCH_ENABLED=1 pod install.

As further help, you can have a look at this repo and branch. It contains a step-by-step guide to create a backward compatible fabric component.

We are planning to make it publicly available as soon as we add the Android details.

[tomekzaw]

@grahammendick I'm glad it worked.

It wouldn't work with the #ifdef RN_FABRIC_ENABLED left in because then iOS ignored these files. How to I set RN_FABRIC_ENABLED to true?

You need to add it to compiler flags in your Podspec (see here) using -D option.

Is this the official way to support both old and new architectures at the same time?

Internally, React Native uses RN_FABRIC_ENABLED flag in a few places, e.g. here. This flag also appears in one of the tutorials (here), but indeed it looks like in AppDelegate.mm it was renamed to RCT_NEW_ARCH_ENABLED.

I'm afraid that, except for this repo by @cortinico and the one @cipolleschi mentioned, there's no official guidelines for library developers on how to support both architectures at the same time yet. However, I'd like to recommend this blog post from @software-mansion blog telling the migration story of react-native-screens which does exactly that.

Also, instead of using RN_FABRIC_ENABLED flag, you may define source files conditionally (here vs. here) but I prefer the approach with #ifdefs since you might also want to use Objective-C++ sources with the old architecture while still be able to use wildcard in Podspec.

I've been trying to get up and running following the "Supporting the New Architecture in your Library" section in the official docs. But I can't find the invaluable information you just gave me in these guides. Has it been left out on purpose? Should I be looking somewhere else for this information?

I think there was some WIP version with more information about migrating iOS View Managers and sending events from C++ to JavaScript but can't find it in the tutorials. @cortinico Do you happen to know if these topics will be added to "The New Architecture" section of the docs as well?

[grahammendick]

Thanks both!

@cipolleschi that step by step guide is just what I need. I think you should point library maintainers to this first rather than the official architecture docs.

Perhaps you could also include a simple prop in the step by step guide. One that doesn't need any special processing. I'm hoping that wouldn't need me to implement the updateProps method? I'm guessing that would be automatically handled by React Native (like with the old managers)?

[cipolleschi]

Hi @grahammendick, I'm happy that you found it useful!

I think you should point library maintainers to this first rather than the official architecture docs.

We are undergoing a refactoring effort for the documentation. Soon we will have the doc updated with all these tips and tricks. These step-by-step guides are intended as supporting material! 😉

Perhaps you could also include a simple prop in the step by step guide. One that doesn't need any special processing. I'm hoping that wouldn't need me to implement the updateProps method? I'm guessing that would be automatically handled by React Native (like with the old managers)?

For this initial release, even while using the RCT_EXPORT_VIEW_PROPERTY for a simple prop, developers are required to implement it manually in the updateProps. But we want to provide the best developer experience we can so, we will automate the handling of the simple props in the near future. When it come to them, the code is repetitive and should be automatically handled.