I found what's missing. If you add:
```diff
s.source_files = "ios/**/*.{h,m,mm}"
+ s.pod_target_xcconfig = { "DEFINES_MODULE" => "YES" }
```
to the `RNBootSplash.podspec`, Cocoapods will generate a proper module that can be imported in Swift.

I can have a look at it tomorrow or in the next few days!

ABI safety/stability is not be a goal in the first step. We need more tooling around our API/ABI stability to be able to ensure it. And the problem of ensuring ABI stability is independent to the problem of shipping prebuilds.
We can solve them at different times, so let solve one problem first!

Also, it should already be possible to distribute community packages prebuilt as pods… you can make a binary that depends on React Native and Cocoapods should resolve the linking part when the binary is integrated with the app.

JSI (and its headers) will be part of the ReactNative framework, so I expect for community modules to just depend on ReactNative to have access to JSI. If there is a need to depend on a JSI isolated binary, we can look into that but I feel it’s a bit early.

We are also looking into preparing a pre build ReactNative.xcframework that we can ship so that apps don’t have to build iOS from scratch every time. But the path to that artifacts has several questions we need to find an answer for, so we need a bit more time for it…

Hi Jamie! Thanks for the test and for publishing the result.

The dependency graph can probably be simplified: the fact that Fabric modules depend on Codegen is wrong and son of an old state of the codebase.

Split React-Fabric module can be complicated because there are dependencies inside it..

Cocoapods should create the module map for you.

In theory, it should be possible to just `import RNBootSplash`, as long as you don’t have c++ files in the `RNBootSplash.h` file