Fix hermes executor not available when use_frameworks is enabled

[Kudo]

Summary

When in use_frameworks! + hermes_enabled mode, the React podspecs have not dependency to the React-hermes podspec. the HermesExecutorFactory.h is not available here and here. The app will fallback to JSCRuntime and crash in release build because the JSCRuntime cannot evaluate Hermes bundles.

The pr tries to add React-hermes to Framework Search Paths and make the HermesExecutorFactory.h reachable when in use_frameworks mode.

This pr should fix the problem mentioned in 0.70 release discussion.

Changelog

[iOS] [Fixed] - Fix Hermes executor not available when use_frameworks is enabled

Test Plan

use patch-package to apply the change to a RN 0.69.1 project with the following test cases:

• old architecture + jsc
• new architecture + hermes
• old architecture + use_frameworks! :linkage => :static + hermes
• old architecture +use_frameworks! :linkage => :static + hermes + release build

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	7,825,302	+0
android	hermes	armeabi-v7a	7,216,532	+0
android	hermes	x86	8,138,262	+0
android	hermes	x86_64	8,115,811	+0
android	jsc	arm64-v8a	9,703,479	+0
android	jsc	armeabi-v7a	8,457,929	+0
android	jsc	x86	9,654,618	+0
android	jsc	x86_64	10,252,016	+0

Base commit: ccdf9ac
Branch: main

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: ccdf9ac
Branch: main

[cipolleschi]

Hi @Kudo, thanks for the PR. However, I don't understand why, with use_framework! we lose the dependency from hermes.

From this file we should install hermes when it is enabled.

I would rather try to understand why with use_framework! this Pod is not installed and fix that, instead of adding a workaround, falling back to something else.

[Kudo]

@cipolleschi in use_frameworks mode, each podspec would has a dedicated xcode target. the header search is mostly based on the Framework Search Paths settings. CocoaPods generates the values based on podspec dependencies.

this is an example of Framework Search Paths from React-Core target, where contain both RCTAppSetupUtils and RCTCxxBridge files. there's no React-hermes in the Framework Search Paths and no hermes headers available to RCTAppSetupUtils/RCTCxxBridge.

the reason hermes works in non_use_frameworks mode is that the React-Core adds an header search entry to hermes. also in non_use_frameworks mode, the compiler don't have to generate *.a or *.so files. if headers are reachable, the compile can link *.o all together for final executable. however for use_frameworks mode, we should add correct framework search paths for xcode to link correct React-hermes libs.

that's my understands. hopefully that would help you to have some insight for further investigation.

[cipolleschi]

Thanks for the clarification. I just have another question, following this:

the reason hermes works in non_use_frameworks mode is that the React-Core adds an header search entry to hermes. also in non_use_frameworks mode, the compiler don't have to generate *.a or *.so files. if headers are reachable, the compile can link *.o all together for final executable. however for use_frameworks mode, we should add correct framework search paths for xcode to link correct React-hermes libs.

I don't see any check that says to skip that line when use_frameworks! is used. So Why that change to the HEADER_SEARCH_PATHS is not applied in that case? Should we replicate that line in another podspec setting, perhaps?

[Kudo]

I don't see any check that says to skip that line when use_frameworks! is used. So Why that change to the HEADER_SEARCH_PATHS is not applied in that case? Should we replicate that line in another podspec setting, perhaps?

because the path in use_frameworks mode is different. it's ${PODS_CONFIGURATION_BUILD_DIR}/React-hermes/reacthermes.framework/Headers. and we should also change #import <reacthermes/HermesExecutorFactory.h> to #import <HermesExecutorFactory.h>

sorry the following description was wrong. i just tested that. once i reached the header in ``${PODS_CONFIGURATION_BUILD_DIR}/React-hermes/reacthermes.framework/Headers`, xcode can build it successfully.

also in non_use_frameworks mode, the compiler don't have to generate *.a or *.so files. if headers are reachable, the compile can link *.o all together for final executable. however for use_frameworks mode, we should add correct framework search paths for xcode to link correct React-hermes libs.

[cipolleschi]

because the path in use_frameworks mode is different. it's ${PODS_CONFIGURATION_BUILD_DIR}/React-hermes/reacthermes.framework/Headers. and we should also change #import <reacthermes/HermesExecutorFactory.h> to #import <HermesExecutorFactory.h>

I understand. Sorry if I'm throwing all these questions to you but:

1. why is cocoapods adding the header into the search path for React-cxxreact and not for React-hermes?
2. what happens if we add the here an entry "FRAMEWORK_SEARCH_PATH" with the proper configurations?
3. Are we sure we need to change this #import <reacthermes/HermesExecutorFactory.h>? Can't we use the modular_headers settings to avoid it, for example?

I would rather try to reduce as much as we can the changes to the code to avoid the introduction of potential bugs.

[Kudo]

1. why is cocoapods adding the header into the search path for React-cxxreact and not for React-hermes?

React-Core.podspec doesn't have dependencies to React-hermes.

2. what happens if we add the here an entry "FRAMEWORK_SEARCH_PATH" with the proper configurations?

brilliant idea. that's work and it's an easy fix. i'll update the pr tomorrow based on this solution.

3. Are we sure we need to change this #import <reacthermes/HermesExecutorFactory.h>? Can't we use the modular_headers settings to avoid it, for example?

i didn't test this. i like approach 2.

I would rather try to reduce as much as we can the changes to the code to avoid the introduction of potential bugs.

np! i like these discussion and brainstorming for better solution. and there we are 👍

[cipolleschi]

Hi Kudo, thanks for updating this. Could you rebase on main? 🙏

[Kudo]

thanks for the update. let's see how it going for ci jobs

[Kudo]

remaining a test js error , other ci jobs are passed 🤔

[cipolleschi]

JS Error seems unrelated...

[facebook-github-bot]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[react-native-bot]

This pull request was successfully merged by @Kudo in 88b7b64.

^{When will my fix make it into a release? | Upcoming Releases}