Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ios build: Start using CocoaPods again.
There was an attempt to use CocoaPods in aded466, 2017-03-19. That was removed in 4096e71, 2017-07-18. Some cleanup was done in 861744b, 2020-02-05. To paraphrase Greg on zulip#3983: CocoaPods is a tool for managing iOS libraries. It means instead of having an `.xcodeproj` file for every library, and manually connecting them to your app's own `.xcodeproj`, a separate `Pods.xcodeproj` is generated from a simple, declarative Podfile, and all you have to do to update or add dependencies is edit the Podfile and run `pod install`. Many people use it in their React Native apps, but there some tricky bits that have impeded universal adoption. RN v0.60 signals a full embrace of the use of CocoaPods by RN, by making it work more smoothly. CocoaPods becomes required in v0.61. Originally, we were going to start using CocoaPods as part of the RN v0.60 upgrade, but we have a fresh reason to want to use CocoaPods, with its own deadline: zulip#3964, Apple auth. Someone has made a handy Expo package to handle Apple auth, but we can't use Expo packages without either fully committing to using the Expo SDK (a dramatic step) or using a package called react-native-unimodules, which lets you select individual Expo packages. react-native-unimodules requires the use of CocoaPods. So, use CocoaPods now. Note that the Podfile will have to be different when we upgrade to RN v0.60.0; see the parent for details. Unfortunately, this has to be one giant commit instead of multiple commits. From experimentation, this seems to be the minimal set of changes that doesn't break functionality, which makes sense intuitively when changing entirely between management strategies for (somewhat) complex dependencies. We were also prompted to try this strategy from solution 3 at this SO post: https://stackoverflow.com/questions/53312887/error-on-archiving-react-native-app-in-xcode-multiple-commands-produce-libyog/55328241#5532824 But Greg has the most plausible theory for the actual reason why this is necessary: """ One possibility is something like: we were getting React, as a whole, from the direct references in the Xcode config; and so that version of the built React library had versions of RCTImageView etc. only when those were configured through RCTImage.xcodeproj etc., via direct references to those in our Xcode config. Whereas the built React library from React.podfile and our Podspec had the RCTImageView that was built due to the RCTImage subspec in our Podfile... but perhaps we just didn't get that one because it had to compete with the libReact.a (or whatever) from our Xcode config. And once we no longer had the latter, we started getting the former instead. """ We started with a Podfile based on the example Podfile given for react-native v0.59, at https://github.com/facebook/react-native-website/blob/ded79d2cf4456d8b1a4f67c2cdc1391789e70617/docs/integration-with-existing-apps.md. (That doc isn't live on the react-native docs website because of facebook/react-native-website#1603.) Then, we realized that more RN-provided libraries were present in our Xcode config, so we added those. We also added a number of dependencies that depend on React Native (react-native-image-picker, etc.). `grep -Rlw 'React' --include=\*.podspec node_modules/` verified that they do indeed depend on the 'React' pod, which is React Native. Also, add a build phase to start Metro. For some reason that we haven't found yet, Metro doesn't start automatically after the switch to CocoaPods. It seems that this was recognized by the RN maintainers as they were updating the template app to switch to CocoaPods. They separated the addition of this build phase into its own commit, facebook/react-native@1f719ae43, but it doesn't mention the reason it was added. In that commit, the name "Start Packager" was used. Here, we use "Start Metro" because a proper noun is more helpful, and this name is what RN uses in a more recent commit, facebook/react-native@e636eb60d, which creates a RNTesterPods project and workspace for testing some aspects of CocoaPods separately. (It's not clear without further digging what aspects those are, but it hasn't been relevant to using CocoaPods on RN v0.59.10.) Notes on individual dependencies: RNDeviceInfo (react-native-device-info): The install instructions at https://github.com/react-native-community/react-native-device-info#manual for RN v0.59.0 using CocoaPods wrongly say not to use CocoaPods (by omitting the line in the Podfile). The author's comment at react-native-device-info/react-native-device-info#748 (comment) suggests that he never found the successful strategy of doing an all-at-once adoption of CocoaPods, as we do here, and rather concluded that a bug was caused by RN v0.59.x having shaky support for CocoaPods. Including the pod works fine. Fixes: zulip#3983
- Loading branch information