Replies: 8 comments
-
I think the only anecdotal evidence I have of why React Native currently doesn't support vendoring a dynamic framework is that Facebook itself uses static libraries for everything. I wonder if @alloy has any context into this, as someone who has spent a large amount of time setting up React Native with CocoaPods. 🤔
Currently, even with the latest iOS versions, loading dynamic frameworks are still slower than loading static libraries. There's (lots) more context here: artsy/eigen#586 |
Beta Was this translation helpful? Give feedback.
-
Eli @eliperkins,
Anecdotally, this is not true. ;) David @dehlen, Currently, I only can share some constraints that we have to satisfy and some rough ideas that I have. First of all, here is constraints that we must satisfy to build a sustainable solution:
At Facebook, we only use Buck as build and dependency management tool. Let's consider this fact and the last constraint that I mentioned: Build scripts are quite complex and tricky. Event if can write new ones that produce iOS Frameworks, there is no way that they will not be broken in a couple of weeks by some change in the source code, and we cannot incentivize anyone who made this change to fix two independent build scripts. We already tried this model with Cocoapods. That was always painful and arguably failed. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
We've had our RFC for CocoaPods in internal discussion last week, so I've just shipped that off #18 Personally, and for Artsy, we don't want to lose the ability to fork and read/maintain the copies of React Native that we have in our app - switching CocoaPods support in RN to just be a system to move binaries around would make that considerably harder and IMO makes it harder for us to understand/adopt/own our dependencies.
On the flip side, a lot of the largest hybrid-app adopters were using React Native this way even when support was broken because there was flexibility in CocoaPods in handling dependency edge cases. I think it makes sense to make releases with binaries attached from buck, but I'd much rather not see that come at the cost of removing the current source access we have. |
Beta Was this translation helpful? Give feedback.
-
@orta Thanks for finishing up that RFC 👍 @eliperkins Most of the struggles came from trying to use CP in React Native in a way that’s not how CP is supposed to be used, whereas CP could be used correctly and follow the same structure that FB chose to split up the RN codebase. That’s what the RFC @orta posted is about and which we (Artsy) are proposing to put dedicated maintenance time for on our infrastructure roadmap. As may be obvious (to those that know @orta and I are colleagues) my preference follows his in that I’m not interested in binary artefacts, as it goes counter to our way of owning and diving into the source of our dependencies. |
Beta Was this translation helpful? Give feedback.
-
Thanks for all the contributions from you guys to this discussion. Especially thank you very much to @orta for adding the PR 👍. I read the Cocoapods RFC and I really like it. I could imagine switching from Carthage to Cocoapods for all our dependencies because of the support for ReactNative. I see your concerns using a build artifact instead of the source code for the ReactNative dependency. I guess debugging ability vs. build time ist one huge factor to consider. I wondered what constraints you see when instead of using ReactNative as a dynamic framework using it with Cocoapods. Would it lead to problems when embedding other native modules via I think which leads to the current problems with the overall build infrastructure of react-native is due to the fact that inside Facebook everybody uses Buck and there simply is no need to support other commonly used dependency management solutions on iOS as @shergin mentioned earlier. |
Beta Was this translation helpful? Give feedback.
-
The CocoaPods RFC looks great, and definitely a good strategy for cleaning up the native dependencies for React Native there. However, I would not like to derail this conversation by convoluting React Native exposing binary artifacts versus the root React Native xcodeproj vendoring a dynamic framework as a target. Yes, a benefit of dynamic frameworks is the ability to ship a binary around, but it is not the sole way to integrate it into your apps. Dynamic framework support and CocoaPods support should be able to coexist, not necessarily be mutually exclusive! For those choosing not to use CocoaPods, the only integration point is currently via the build products that are exposed via the xcodeproj. Since CocoaPods will not care about xcodeproj's, I believe we should be able to make changes here that work for all use-cases. |
Beta Was this translation helpful? Give feedback.
-
Absolutely 👍 I don’t want to derail from this, just wanted to make clear what our context was and remains. |
Beta Was this translation helpful? Give feedback.
-
Okay, if you want to have direct access to sources during build and development time, what if we make a set of Buck-generated Xcode projects and source code the "prebuilt" artifact that Cocoapod refers to? |
Beta Was this translation helpful? Give feedback.
-
Hi,
First and foremost I'd like to thank you and all the OS contributors for the effort going into this project and enabling so many people to write performant native applications with a single code base and with a great tooling. Me and my team love to hack with react-native.
Currently we use Carthage extensively at my team for dependency management on iOS. I wondered whether it would be possible to use react-native with Carthage as a dynamic framework. This is because
a) we don't want to mix and match multiple dependency management solutions
b) we could cache react-native as a dynamic framework. This way the dependency with all of it third-party dependencies could build one time and after that the CI server could use the cached version.
I think the approach of using react-native as a dynamic framework would increase the build time of our application by a huge factor. Also currently the whole react-native dependency is located in a dynamic framework of ourselves. This framework is then added to an app target which forces us to link the whole Xcode project of our framework and build the sources on the app build because we can't just integrate our framework via Carthage. This is mainly due to the fact that the dynamic framework of ours would need to export all the relevant react-native headers in order to import the framework correctly.
I would love to hear your thoughts whether
a) Carthage support is planned
b) if the support for Carthage is not on your list how we should deal with the current dependency problematic. We currently have to rebuild the whole react-native Xcode project for every app build on our CI server. This leads to huge increases of our build time and prevents us from benefiting the fast iteration cycles react-native could offer.
Also if no support for Carthage is planned maybe someone could help out with a sample project or script which includes the static react-native library and exports the headers correctly so we could maintain a dynamic wrapper framework to achieve our goals ?
Since react-native dropped support for iOS8 in 0.56.0 I guess providing a dynamic framework for iOS has no real disadvantage because since iOS8 dynamic frameworks are supported and could help a lot of people as other issues already have stated.
I am happy to hear your answers and to start a discussion about this.
Beta Was this translation helpful? Give feedback.
All reactions