Repository navigation
Support SHARED FRAMEWORK targets in CMake RN #258
Description
We're currently expecting CMake projects to output "free" dynamic libraries (not wrapped in Apple frameworks) and it would be great if we supported use-cases where developers wants to control the framework options and skip the transformation from dynamic library to framework that CMake RN performs.
Documentation for CMake's support for outputting frameworks: https://cmake.org/cmake/help/latest/prop_tgt/FRAMEWORK.html
add_library(dynamicFramework SHARED
dynamicFramework.c
dynamicFramework.h
)
set_target_properties(dynamicFramework PROPERTIES
FRAMEWORK TRUE
FRAMEWORK_VERSION C
MACOSX_FRAMEWORK_IDENTIFIER com.cmake.dynamicFramework
MACOSX_FRAMEWORK_INFO_PLIST Info.plist
# "current version" in semantic format in Mach-O binary file
VERSION 16.4.0
# "compatibility version" in semantic format in Mach-O binary file
SOVERSION 1.0.0
PUBLIC_HEADER dynamicFramework.h
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
)It would be great if we added documentation and tests for this as well 🤞
Activity
shirakaba commentedon Sep 28, 2025
The NativeScript repo was originally producing a
libNativeScript.dylib(orlibNativeScript.0.1.0.dylib, ifBUILD_FRAMEWORKwereTRUErather thanFALSE), which it renamed toNativeScript.nodefor use with Node.js.I ended up changing this to a
.frameworkfor consistency with the iOS side of things. Though would've been interesting if react-native-node-api could've handled either (somehow).kraenhansen commentedon Oct 11, 2025
I'm starting to think of another issue. The way we're handling XCFramework might not be ideal if the author wants to sign their binaries 🤔
I'm contemplating if we should ease requirements of these prebuilds and instead provide the
requireNodeAddonfunction with enough information to handle XCFrameworks regardless of how they're built (as long as they expose a dylib which use Node-API to register an addon).And then have "opt-in" helpers for renaming to avoid clashing names when linking 🤔 To be honest - most of that requirement is driven from the hope of being able to run the Node.js tests and examples without requiring code-changes ...
kraenhansen commentedon Oct 20, 2025
I've started work on this and will likely take it even further to the point of requiring CMake projects to set
FRAMEWORK TRUEtheir shared object libraries. I'll extendgyp-to-cmakewith an option to emit this configuration in theCMakeList.txtfor the GYP projects to be compatible and I'll make sure to update examples in the repo to match this new expectation.We could also provide an includeable .cmake file with a function to make that easier (like we do for
weak-node-api) if this is causing too much friction.