react-native-website

react-native-website copied to clipboard

This PR introduces a comprehensive guide on packaging React Native modules as .framework for iOS:

• Describes the motivation to package React Native modules for integration with native apps.
• Provides step-by-step instructions, from creating a new React Native app to building the framework.
• ... TODO

The goal of this new documentation is to equip developers with the knowledge needed for seamless integration of React Native modules into native iOS projects.

✅ Deploy Preview for react-native ready!

Name	Link
🔨 Latest commit	fe76e9725f841beef061b84767ad60b583cb515f
🔍 Latest deploy log	https://app.netlify.com/sites/react-native/deploys/651565d07809a400089802ce
😎 Deploy Preview	https://deploy-preview-3861--react-native.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

Hi @michalchudziak, thanks for this guide, but I have a few questions:

1. how can I see the preview from netlify? I see that the guide is not connected with the sidebar and if I navigate to docs/packaging-ios, I can't see it.
2. There are some linting error that should be fixed
3. What's the goal with this guide? From which need does it come from? I am not sure that this is what we actually want to promote as a way to package libraries: we already have a guide to package iOS (and Android) modules use NPM and that should be the suggested way to ship those libraries. On top of that, packaging the code as XCFramework is not that straightforward if we think about the New Architecture and the code generated by Codegen: the framework you'd like to ship will not build as it needs the files generate by codegen that lives in the app space and not in the framework space. So, as of today, I don;t think that we can/should ship a guide like this: it is quite advanced and it can create confusion in the majority of React Native users.

Hey @cipolleschi! The PR isn't finished, which is why it's in a draft state. I haven't yet focused on fixing the linting issues and testing the actual preview (it's certainly not ready for merging yet).

Regarding point 3, I see significant value in the XCFramework approach, especially when considering brownfield applications. I've outlined the rationale behind this in the Why Package React Native? section of the docs.

When incorporating React Native modules into a native app, it's frequently necessary to bring in JavaScript-specific tooling, such as yarn, metro-bundler, jest, and other related tools. However, this can create challenges, as it might raise the entry barrier for native development teams. Furthermore, it's not uncommon for React Native teams to operate independently from native teams. In situations like these, dividing development across separate repositories can be beneficial. This is where packaging becomes invaluable.

I believe it aligns well with specific code organization patterns and organizational structures.

We're definitely keeping the new architecture in mind, and we want to ensure we consider it before finalizing this guide. Unless I'm mistaken, I believe that moving the generated files can be managed with a post-install script. I'm considering adding this information to the guide, alongside the Swift guide.

Do you think that if we address this, there would be room for such a guide in the docs? Maybe in the advanced section?

@michalchudziak I agree that XCFrameworks can bring benefit, but we can have this page in the official documentation, unfortunately.

This can make for an amazing post in your company blogpost, but for the official documentation we want to have something that is battle-tested and work in all the scenarios, including the New Architecture, and that integrates well with the current tooling (e.g. autolinking). At the moment, none of these requirements are true:

• We are not using packaged Xcframeworks internally (except from hermes-engine, which required a non trivial amount of work to have it working properly) => Not battle tested
• It doesn't work well in all the scenarios => the New Architecture is not supported
• It does not integrates well with the current tooling => it doesn't work with autolinking (as you have to reference the target manually and to modify the AppDelegate.mm) and it requires multiple steps to integrate from our users.

Also considering that now we can build dependencies with use_frameworks! and dynamic linking, the pros of packaging the library as XCFramework are obtainable in another way and with much less effort.

@cipolleschi I completely understand your point. Just to be clear, it does work with auto-linking without any issues. The change to the app delegate is not essential for the packaging process; it's solely about changing the name to demonstrate the ability to have multiple root views. In fact, AppDelegate is not used in this process at all.

I also think that achieving support for new architecture is possible with minimal overhead (at least in a simple setup), as described in the comment above. Also, I can't fully agree with the use_frameworks! argument, as I believe it addresses a slightly different use case, but I can't argue with the "battle-tested" point, hence I think I'll follow your suggestion and address this in a blog post. Thanks for the review!