Cli: Make iOS linking to Podfile or directly linking as framework an option for library maintainer and for consumer

[bartolkaruza]

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:

1. 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. https://github.com/facebook/react-native/pull/15460#issuecomment-346374083)
2. It should be possible for a linking target project to force react-native link to 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: https://github.com/invertase/react-native-firebase/pull/838 https://github.com/facebook/react-native/pull/15460#issuecomment-346374083

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: https://github.com/luggit/react-native-config/issues/187#issuecomment-395585247
This shouldn't be necessary :)

[grabbou]

CC: @rhdeck - I would love to hear your input on the CocoaPods support.

[rhdeck]

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:

1) Third party dependencies are best managed as cocoapods. I certainly do this, and created react-native-pod to make this easier and declarative from the package.json level. Every package that i have seen the "drag and drop framework" instruction was available as a CP, and deploying this way made life easier.

2) This creates a potential conflict with RN libraries that have podspecs. Once you create a Podfile, react-native link runs 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 a react native link --without-pods flag, but for now I have the more-hacky react-native-linknopod that basically does this. So I run react-native linknopod instead of react-native link to do my... link.

3) 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-cli templates 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 use react-native-fix-pod-links. Its a slightly more complicated devex for a library maker, but still pretty high velocity imho.

4) 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]

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]

--ios_linking_method pod|xcodeproj could be an option

[grabbou]

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]

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]

@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 link brings 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-linknopod and 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]

Thanks for explanation. Makes sense. This is going to be less of an issue
now that CocoaPods is going to be standard for all new projects from 0.60
on. We will still have to support older projects tho.

I guess a flag to manually choose linking method is going to be a good
solution to this problem. And we are going to default to CocoaPods when
Podfile is present in both places.

If anyone is willing to contribute this, please do! Happy to help.
On Mon, 11 Mar 2019 at 14:57, Ray Deck [e-mail] wrote:

@grabbou https://github.com/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 link brings 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-linknopod
and 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. 😄

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/react-native-community/react-native-cli/issues/37#issuecomment-471548835,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWcxv4a3dmi5_BeKSEXNYNRU8UD0h95ks5vVmDjgaJpZM4ZJ-kU
.

[Ashoat]

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 then react-native link react-native-gesture-handler. Very few None of them worked out of the box. Most All 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 link feel 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]

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]

link is soon to be removed. Should be fixed with autolinking available since RN 0.60+