Repository navigation
Make iOS linking to Podfile or directly linking as framework an option for library maintainer and for consumer #37
Description
Since the introduction of the Cocoapods check in this PR, any project with a Podfile linking any library with .podspec will be linked by adding the library to the cocoapods. Although this is theoretically the desired behaviour and a much better way to link libraries, there are various reasons why some libraries need to be linked in the direct way instead. Most app projects require cocoapods for something during their lifecycle. After adding cocoapods, adding several high profile react native libraries becomes much more complicated. This is a proposal to address that.
With this issue I propose two things:
- It should be possible for a library maintainer to indicate that the iOS native library should be linked directly to the app project, instead of through cocoapods, even with a Podfile available in the target. (eg. Make
react-native linkplay nicely with CocoaPods-based iOS projects. react/react-native#15460 (comment)) - It should be possible for a linking target project to force
react-native linkto specify individual libraries to link directly through the project, instead of through the Podfile.
One example of why this would help is react-native-firebase, where their install for iOS documentation describes:
Firebase recommends using Cocoapods to install the Firebase SDK.
and the react-native-firebase
Option 1: Link React Native Firebase (Recommended)
Some related communication from @chrisbianca: invertase/react-native-firebase#838 react/react-native#15460 (comment)
Other scenarios where linking to Podfile is causing issues is react-native-config and react-native-branch.
If 1. is implemented, the library maintainers can resolve those issues for their users, by forcing link to ignore the Podfile and the libraries .podspec. 2. can be used by the consumers of those libraries to implement a stable workaround until the libraries in question have resolved it for them.
Just an additional link as to why this is important, here is a workaround posted to one of the issues which basically instructs the user to delete the Podfile, then run link, then add the Podfile again: react-native-config/react-native-config#187 (comment)
This shouldn't be necessary :)
Activity
grabbou commentedon Jan 28, 2019
CC: @rhdeck - I would love to hear your input on the CocoaPods support.
rhdeck commentedon Jan 29, 2019
OK, I blew away my previous comment because I didn't understand the issue at the time and managed to comment on the wrong thing.
So my thinking is:
Third party dependencies are best managed as cocoapods. I certainly do this, and created
react-native-podto make this easier and declarative from thepackage.jsonlevel. Every package that i have seen the "drag and drop framework" instruction was available as a CP, and deploying this way made life easier.This creates a potential conflict with RN libraries that have podspecs. Once you create a Podfile,
react-native linkruns around adding all of them to the Podfile, and that creates a dependency mess. For this I am hoping that the RN crew might come up with areact native link --without-podsflag, but for now I have the more-hackyreact-native-linknopodthat basically does this. So I runreact-native linknopodinstead ofreact-native linkto do my... link.3P cocoapod dependencies also make library development harder, because the CPs are attached to the app, while the library is developed elsewhere. For this, one needs to make sure to import the appropriate header paths (my
react-native-swift-clitemplates include this relative path reference) but since often lib development is done elsewhere, supporting the more complex path from the RN native library to your test app's cocoapod path is required. For this, I made and usereact-native-fix-pod-links. Its a slightly more complicated devex for a library maker, but still pretty high velocity imho.Longer term, it would be ideal to centralize all the dependency tree into cocoapods. The split personality of directly linked static libraries and cocoapods increases the energy a library developer needs to devote to RN-specific issues of deployment, which decreases native developer efficiency and reduces the universe of native developers who can work on RN-relevant projects. CocoaPods ain't perfect, but it has great community support and it removes an otherwise difficult concern - dpepndency management - from RN core.
I would not recommend RN create a specific mechanism of adding native dependencies outside of CP - creating more mechanisms increases developer work, and it increases the surface area of concerns that RN has, which would slow development in other, higher return areas.
@grabbou is this the kind of feedback you were looking for?
brenwell commentedon Jan 31, 2019
This would be so helpful. I feel like my pod file gets a new hack to keep the React pods and subspecs working every other week.
Simply the —without-pods would be enough. Though it would require pods already added to the pod file to not be linked
punksta commentedon Mar 7, 2019
--ios_linking_method pod|xcodeprojcould be an optiongrabbou commentedon Mar 11, 2019
Looking at this issue again in order to make sure our CocoaPods support is first-class before 0.60 is cut.
@bartolkaruza, I messaged you on Discord to discuss some of the details and sync our work.
grabbou commentedon Mar 11, 2019
Do I understand correctly that the use-case presented in this issue is to let certain libraries still be linked the "standard" way even though the 3rd party library ships with Podspec? Why they ship with it in first place then?
rhdeck commentedon Mar 11, 2019
@grabbou the answer to your question is that the library is trying to support both of the ways that RN can be deployed - via direct SLs or through CP. But if one deploys RN via the currently-stock SL method and then adds a Podfile to support 3P libraries (like react-reality does), a subsequent
react-native linkbrings over the package as a pod, which then brings the train of dependencies, including a second shot at RN itself.In my experience, that's a mess. The purpose of
react-native-linknopodand of this issue is to give more control over how the package gets added to the app itself, so that one can have RN modules via direct SL binding, and have the Podspec handle other concerns.This complexity is a necessary consequence of RN allowing two mechanisms for adding native modules, which is a separate issue, as it were. 😄
grabbou commentedon Mar 11, 2019
Ashoat commentedon Apr 24, 2019
I spent today trying to move to a CocoaPods-based setup and didn't get very far. I went through each of the native modules I used, and ran
react-native unlink react-native-gesture-handler(for example) and thenreact-native link react-native-gesture-handler.Very fewNone of them worked out of the box.MostAll ended up having to be manually linked using the classic three-step process.I would love to see CocoaPods become "first-class", but if that means having to manually link everything I'd prefer the old approach. I think these issues can probably be resolved by fixing up the relevant projects' Podspecs, but I'm new to CocoaPods and not quite ready to send out all the PRs. Going forward with CocoaPods now will probably push maintainers to try and fix up their Podspecs (assuming it's possible), but it will probably make
react-native linkfeel pretty "broken" to end users in the short term.UPDATE
After more debugging, I'm realizing this issue has to do with my use of yarn workspaces. Having a flag to choose linking would allow me to circumvent it, but the right solution would certainly be to fix up support for yarn workspaces. I've created #352 to track this. My apologies for commenting on this issue with a mostly unrelated complaint.
kyle-ssg commentedon Apr 24, 2019
There’s no way I’d dependencies via pods, it’s so painful. react-native-linknopod is a great alternative. I tend to use this for Android only
thymikee commentedon Mar 9, 2020
linkis soon to be removed. Should be fixed with autolinking available since RN 0.60+