NativeModule.RNDeviceInfo is null on RN 0.59.10 #748
Comments
|
I'm having the same issue here, but I'm using RN 0.60.4, this still need to link manually? |
|
@rodrigowpl for RN60 you do not need to link. The example is RN60 and I just closed a similar bug #747 please search for dupes first, that one has the info you need @beeremy I'm looking into doing a refresh-example-rn59.sh script similar to the one I keep current and corresponding examplern59 test app right now, almost have it working. It should work but if it fails that will show the problem. |
|
Okay, I have an example just now for RN59, everything works, so I can't reproduce. I know react-native upgrades are difficult (I just finished moving to RN60, hooboy...) but I don't think this module has a problem with RN59 |
|
I am having this same issue. I just initialized a fresh RN project at v0.59.10, initialized cocoapods ( I ran into this issue yesterday and was able to get it to work by manually linking react-native-device-info even though I am using cocoapods. Because of other odd issues I've been fighting the past week, I decided to initialize a fresh project, yet I am still getting this error. I would prefer NOT to manual link if technically the correct way would be to utilize pods. |
|
well that is most strange, we both did a fresh init and got different results. Thanks for reporting this. I am guessing when you did the link your Podfile was there based on the steps you describe and the mention of device-info content in the Podfile I think for RN59 at least with the current release the recommendation must be to run the link before you had a Podfile (or temporarily move it out of the way). Why? Good question, but when I do a fresh init I know that RN59.10 comes down with no Podfile by default, which triggers a different linking style, and I link that way: https://github.com/react-native-community/react-native-device-info/blob/master/refresh-example-rn59.sh#L31 I think for RN59 the use of pods was experimental (I had to hack around it a lot to get it to work with various workarounds depending on included modules) and I recommend manual link (with Podfile not present during link), whereas for RN60 it's the reverse - just add the module and you're done |
|
@mikehardy that makes sense, actually. Executing |
|
It seems - based on the success of my refresh-example-rn59.sh and the failure of your link-after-pod-init - that you are correct: if using cocoapods with rn59, manually link but - to make it easy at least, I have moved the Podfile out of the way for certain modules and then run link, then moved it back and that automates everything at least. This should probably be documented 😅 - could you please PR to the install docs mentioning there seems to be a need to work this way, with a link here? 🙏 |
|
I am facing the same issue. I also updated react-native to 0.59.10 and started experiencing this. Is there any way to get it working without the need of manual linking? What is the latest version of react-native that doesn't have this issue? |
|
If you use react-native <= 0.59.x you must manually link, just like forever. And if you have a podfile, move it out of the way first, or use patch-package to delete the podspec from react-native-device-info until you can move to 0.60 perhaps. Cocoapods was not officially supported by react-native prior to react-native 0.60 because of problems like this. I have sympathy for the difficulty of moving to react-native 0.60 but as it is unavoidable I am not motivated to hack on fixes for old versions. If someone can figure out whatever the problem in the podspec was and wants to make a PR I could maybe branch and do a release on 2.x or similar. But I'm focused on getting v3 out #760 so I can fix App Store warnings, and the 20 other bugs that will be closed out. |
|
@mptorz, not long after encountering this issue, I decided to upgrade to RN v0.60.5 and no longer have this issue. Although not technically a direct solution, upgrading to 0.60 is such a huge improvement and I highly recommended it if you can. I ran into so many odd issues related to linking/pods with 0.59 and now everything seems to work as expected. NOTE: When I upgraded, I literally started from scratch (react-native init projectname) and copied over my source files. I think in order to upgrade your current project, you need to unlink everything first, but I can't comment on the results of that approach. |
|
Yes, react-native 60 upgrades are out of scope here but the upgrade-helper site and the CLI do nudge you in the right direction. And yes, you must unlink almost everything first. The things you keep are the things where you need the symbols in your code still (like react-native-splash-screen where you have to add code in MainActivity etc) |
|
The same issue, is there any updates about how to fix it? |
|
@Luckygirlllll I just updated the RN59 example script over the weekend to prove / confirm it works, so I'm not sure what the problem is in any specific project, but I know for certain that the current code here (released at the moment as 4.0.1-beta.4, but really any version v3.x and forwards) should work just fine My best recommendation is to examine that demonstration (possibly clone it and run it) to see how it does what it does, then copy that |
|
@mikehardy after your reply, I checked once again the whole RN Helper from 0.59 to 0.61.2 but the library link stills seems broken. Manual linking in |
|
Fair enough that it's still happening for you, but it definitely should not be. Something is off in your project if you have to manually link after RN60. Proof, vs words: https://github.com/react-native-community/react-native-device-info/blob/master/refresh-example.sh - what it could be I have no idea, the RN59->RN60 transition was tough enough I'm trying to forget it. But something's missing in your project. |
|
Yeah, I am still facing the transition: I will reply here if I will find something missing in my configuration. Thanks a lot for your time. |
|
Removing the podfile entry for the lib ( pod 'RNDeviceInfo', :path => '../node_modules/react-native-device-info'), and re-linking manually, as described here: https://github.com/react-native-community/react-native-device-info#linking-for-react-native--059-only-react-native--060-skip-this-as-auto-linking-should-work, worked for RN 59. |
|
[android] |
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Mar 28, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Mar 30, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 1, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 1, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 1, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 2, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 2, 2020
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
chrisbobbe
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 2, 2020
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
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Apr 3, 2020
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug
Dear all,
I am upgrading my app from RN 0.53 to RN 0.59.10 and it's been a day I'm facing the following bug after the app successfully compiles:
*** Terminating app due to uncaught exception 'RCTFatalException: Unhandled JS Exception: @react-native-community/react-native-device-info: NativeModule.RNDeviceInfo is null.
I have upgraded to the package version to the last one (i.e. 2.3.2), I've tried to follow the instructions given, I've tried to unlink, uninstall, install, link, pod install, but still, the issue remains. I've also added the piece of code inside react-native-config.js.
Environment info
React native info output:
React Native Environment Info: System: OS: macOS 10.14.5 CPU: (4) x64 Intel(R) Core(TM) i7-6660U CPU @ 2.40GHz Memory: 149.80 MB / 16.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 12.7.0 - /usr/local/Cellar/node/12.7.0/bin/node Yarn: 1.12.3 - ~/.yarn/bin/yarn npm: 6.10.0 - /usr/local/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 12.4, macOS 10.14, tvOS 12.4, watchOS 5.3 Android SDK: API Levels: 23, 24, 25, 26, 27, 28 Build Tools: 23.0.1, 23.0.2, 25.0.1, 25.0.2, 26.0.1, 27.0.3, 28.0.2, 28.0.3 System Images: a...s_playstore | Google Play Intel x86 Atom Sys... IDEs: Android Studio: 3.3 AI-182.5107.16.33.5314842 Xcode: 10.3/10G8 - /usr/bin/xcodebuild npmPackages: react: 16.8.3 => 16.8.3 react-native: ^0.59.10 => 0.59.10 npmGlobalPackages: react-native-cli: 2.0.1Library version: 2.3.2
The text was updated successfully, but these errors were encountered: