[Bridge] Native module inside framework

Is there a way to implement native module inside framework instead of static library?

[a2]

As of now, this is not possible because React Native looks for all RCT_EXPORT entries in its binary.

Sometimes developer needs to use native modules inside frameworks. For example, it's required to avoid build problems because of the conflicts between 3rd party libs code and React Native libs.
Can we propose to extend React Native functionality to let Objective-C class that implements RCTBridgeModule has an option to return list of methods for export to JS?

[drkibitz]

Not exactly sure I am following this issue, but I'm interested. Is the question if you can add a new Framework that utilizes react native and exposes functionality?

[ide]

@drkibitz yes, if you publish e.g. a keyboard component that has some native code, it currently has to be distributed as a static library. This means you can't write helper code in Swift without splitting it out into a separate framework.

So far I've found RCT_EXPORT easy to type and maintain so it would be nice to keep it or something very similar. Maybe it (or a new macro) could generate dummy methods that RCTBridge knows to scan for?

[a2]

Alright, I'm currently working on an updated version of RCT_EXPORT and I will look into making this possible.

[ide]

@a2 That sounds really great. One of the practical benefits of framework support is that you can use CocoaPods containing Swift -- if a pure-ObjC pod (e.g. a React module) depends on a pod with Swift code (e.g. Alamofire, whatever) then CocoaPods builds both as frameworks.

@a2 sounds good, will be waiting eagerly!

[tptee]

👍 this is the last thing blocking my WebSockets native extension: https://github.com/tptee/RCTWebSocket

This'll help distribution/CocoaPods interop immensely.

Any news?

[tptee]

#982 is done, which is awesome, but I'm not sure frameworks work yet. When CocoaPods builds a framework, it spits all of the project's headers into one folder, and a few headers in React Native reference relative paths. This breaks clang modules, which CocoaPods framework support depends on. So while we can write extensions in Swift, we can't deliver them in a clean way yet :/

[nicklockwood]

That's true. I'm working on it :-)