Xcode: "Update to recommended settings" #4112
Labels
Comments
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 1, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. This is a warning we've seen for a while (zulip#4112), and there's no suggestion that we can't do it before the main upgrade commit. This change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]. While some of that guide is out-of-date with the actual Xcode files in the template app, this particular change is correct. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 1, 2020
We'll actually enable it in the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and the conditional that appears there). This encompasses several RN commits, as follows, several of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Mostly, these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Generally, though, the RN commits aren't very clear or coherent, so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9, with Flipper release tag v0.26.0; see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we'll take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but it didn't work. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. We have this already, and, in fact, it gets *removed* if I follow an automatic deprecation fix that Xcode suggests in the buildtime warnings (an instance of zulip#4112). So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. This is not reflected in the upgrade guide on the Xcode changes [1], which still says you need to create the file. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. It also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do in the main upgrade commit. [1] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. This is a warning we've seen for a while (zulip#4112), and there's no suggestion that we can't do it before the main upgrade commit. This change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]. While some of that guide is out-of-date with the actual Xcode files in the template app, this particular change is correct. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
We'll actually enable it in the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we'll take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but it didn't work. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. We have this already, and, in fact, it gets *removed* if I follow an automatic deprecation fix that Xcode suggests in the buildtime warnings (an instance of zulip#4112). So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. This is not reflected in the upgrade guide on the Xcode changes [1], which still says you need to create the file. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author when he says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do in the main upgrade commit. [1] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. This is a warning we've seen for a while (zulip#4112), and there's no suggestion that we can't do it before the main upgrade commit. This change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]. While some of that guide is out-of-date with the actual Xcode files in the template app, this particular change is correct. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
We'll actually enable it in the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we'll take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but it didn't work. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. We have this already, and, in fact, it gets *removed* if I follow an automatic deprecation fix that Xcode suggests in the buildtime warnings (an instance of zulip#4112). So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. This is not reflected in the upgrade guide on the Xcode changes [1], which still says you need to create the file. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author when he says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do in the main upgrade commit. [1] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. This is a warning we've seen for a while (zulip#4112), and there's no suggestion that we can't do it before the main upgrade commit. This change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]. While some of that guide is out-of-date with the actual Xcode files in the template app, this particular change is correct. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 2, 2020
We'll actually enable it in the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we'll take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but it didn't work. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. We have this already, and, in fact, it gets *removed* if I follow an automatic deprecation fix that Xcode suggests in the buildtime warnings (an instance of zulip#4112). So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. This is not reflected in the upgrade guide on the Xcode changes [1], which still says you need to create the file. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author when he says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do in the main upgrade commit. [1] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 4, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. These are warnings I think we've seen for a while (zulip#4112), and there's no suggestion that we can't do them before the main upgrade commit. The diff in the RN commit seems to address two warnings at the same time, even though only the "Missing Localizability" one is mentioned; like in that commit, we do them both here. They are: """ Migrate "English.lproj" (Deprecated) Migrating the English, deprecated localization to English is recommended for all projects. This will ensure localized resources are placed in “en.lproj” directories instead of deprecated “English.lproj” directories. """ """ Turn on "Missing Localizability" This will turn on the static analyzer check for "Missing Localizability", because this project is localized for multiple languages. """ The "Missing Localizability" change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]; the "Migrate 'english.lproj' (Deprecated)" one does not. See also discussion on GitHub [3]. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13 [3] zulip#4244 (comment)
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 4, 2020
We'll actually enable it after the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and in the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but the wizard didn't activate. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. It appears Xcode doesn't like this change; it gets reverted later as part of facebook/react-native@ebb629d05 (which we take elsewhere in this series, before the upgrade, as an instance of zulip#4112), when they follow an Xcode automatic deprecation fix. So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. The commit message makes it sound like it's no longer necessary for projects to make the Swift file in the first place; on the other hand, the upgrade guide on the Xcode changes [1] indicate that it should be created and then removed. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author, who says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do after the main upgrade commit; see zulip#4244 (comment). [1] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 9, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. These are warnings I think we've seen for a while (zulip#4112), and there's no suggestion that we can't do them before the main upgrade commit. The diff in the RN commit seems to address two warnings at the same time, even though only the "Missing Localizability" one is mentioned; like in that commit, we do them both here. They are: """ Migrate "English.lproj" (Deprecated) Migrating the English, deprecated localization to English is recommended for all projects. This will ensure localized resources are placed in “en.lproj” directories instead of deprecated “English.lproj” directories. """ """ Turn on "Missing Localizability" This will turn on the static analyzer check for "Missing Localizability", because this project is localized for multiple languages. """ The "Missing Localizability" change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]; the "Migrate 'english.lproj' (Deprecated)" one does not. See also discussion on GitHub [3]. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13 [3] zulip#4244 (comment)
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 9, 2020
We'll actually enable it after the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and in the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but the wizard didn't activate. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. It appears Xcode doesn't like this change; it gets reverted later as part of facebook/react-native@ebb629d05 (which we take elsewhere in this series, before the upgrade, as an instance of zulip#4112), when they follow an Xcode automatic deprecation fix. So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. The commit message makes it sound like it's no longer necessary for projects to make the Swift file in the first place; on the other hand, the upgrade guide on the Xcode changes [1] indicate that it should be created and then removed. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author, who says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do after the main upgrade commit; see zulip#4244 (comment). [1] react-native-community/upgrade-support#13
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 11, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. These are warnings I think we've seen for a while (zulip#4112), and there's no suggestion that we can't do them before the main upgrade commit. The diff in the RN commit seems to address two warnings at the same time, even though only the "Missing Localizability" one is mentioned; like in that commit, we do them both here. They are: """ Migrate "English.lproj" (Deprecated) Migrating the English, deprecated localization to English is recommended for all projects. This will ensure localized resources are placed in “en.lproj” directories instead of deprecated “English.lproj” directories. """ """ Turn on "Missing Localizability" This will turn on the static analyzer check for "Missing Localizability", because this project is localized for multiple languages. """ The "Missing Localizability" change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]; the "Migrate 'english.lproj' (Deprecated)" one does not. See also discussion on GitHub [3]. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13 [3] zulip#4244 (comment)
gnprice
pushed a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 11, 2020
We'll actually enable it after the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and in the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but the wizard didn't activate. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. It appears Xcode doesn't like this change; it gets reverted later as part of facebook/react-native@ebb629d05 (which we take elsewhere in this series, before the upgrade, as an instance of zulip#4112), when they follow an Xcode automatic deprecation fix. So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. The commit message makes it sound like it's no longer necessary for projects to make the Swift file in the first place; on the other hand, the upgrade guide on the Xcode changes [1] indicate that it should be created and then removed. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author, who says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do after the main upgrade commit; see zulip#4244 (comment). [1] react-native-community/upgrade-support#13
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 11, 2020
Part of the RN v0.61 -> v0.62 changes to the template app [1], corresponding to facebook/react-native@ebb629d05. These are warnings I think we've seen for a while (zulip#4112), and there's no suggestion that we can't do them before the main upgrade commit. The diff in the RN commit seems to address two warnings at the same time, even though only the "Missing Localizability" one is mentioned; like in that commit, we do them both here. They are: """ Migrate "English.lproj" (Deprecated) Migrating the English, deprecated localization to English is recommended for all projects. This will ensure localized resources are placed in “en.lproj” directories instead of deprecated “English.lproj” directories. """ """ Turn on "Missing Localizability" This will turn on the static analyzer check for "Missing Localizability", because this project is localized for multiple languages. """ The "Missing Localizability" change appears in the Upgrade Support repo's official guide for how to change the Xcode files using Xcode [2]; the "Migrate 'english.lproj' (Deprecated)" one does not. See also discussion on GitHub [3]. [1] https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.2 [2] react-native-community/upgrade-support#13 [3] zulip#4244 (comment)
chrisbobbe
added a commit
to chrisbobbe/zulip-mobile
that referenced
this issue
Sep 11, 2020
We'll actually enable it after the main RN v0.61 -> v0.62 upgrade commit, if only because running Flipper pre-RN v0.62 isn't advertised as something you can do. Enabling it means calling the initialize function, like in facebook/react-native@05f5cb534, but in the form it took in facebook/react-native@b4d1fcfb2 (and in the conditional that appears there). This encompasses several RN commits, as follows, some of which broke builds (which poses a problem even without Flipper enabled). We lump these in with their fixes, so that we don't knowingly introduce errors at any commit in our project. Some of these problems can be traced to upgrading the FlipperKit pod and not handling breaking changes at the same time. Perhaps it wouldn't have been easy for RN to catch these before merging. Generally, though, the RN commits aren't very clear or coherent (at least by our standards), so I feel safer flattening all of these even if something could plausibly stand alone in our project. ----- facebook/react-native@70274f4e9 ----- This commit is unstable. One reason is that `pod install` fails until `:modular_headers` is added to the `Yoga` pod declaration in facebook/react-native@898b1db6d. The failure message: ``` [!] The following Swift pods cannot yet be integrated as static libraries: The Swift pod `YogaKit` depends upon `Yoga`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies. ``` ----- facebook/react-native@e8541e03f ----- The claim is that this commit adds running React Dev Tools to the template. I had thought this was something totally separate from Flipper (and so this would naturally stand in its own commit), but no; the added code comes from the `FlipperKitReactPlugin` subspec of the `FlipperKit` pod, and it'll be invoked in the Flipper initialization function. This commit also advances the FlipperKit pod version to v0.23.6; I'm not aware of any new issues that were specifically introduced in this version. Still, seems safest to apply these changes in this giant commit. ----- facebook/react-native@898b1db6d ----- A small handful of changes in `AppDelegate.m`, the Podfile, and `project.pbxproj` are made here. The motivation for the `AppDelegate.m` changes isn't clear to me, unless it's "The integration of Flipper on iOS was crashing the template"--not super descriptive or helpful in finding the origin of the issue. In the Podfile, the addition of `:modular_headers => true` to the `Yoga` pod declaration fixes a `pod install` failure introduced in facebook/react-native@70274f4e9, described above. Also in the Podfile, the change of FlipperKit's version to v0.30.0 introduces a build failure associated with facebook/flipper@ab121f9d9 (Flipper release tag v0.26.0); see facebook/react-native#27565 (comment). That issue was non-optimally resolved in facebook/react-native@b4d1fcfb2, which we take for now in this commit (see below); a more principled solution is open as facebook/flipper#1171. The `project.pbxproj` changes here aren't fully explained, but here's what I think happened, and what I did about it: - An empty Swift file was added, to rouse Xcode into being prepared to handle Swift files, which is needed for the "YogaKit" dep; see facebook/react-native#27426 (comment). This step is included in the upgrade guide [1]. The empty Swift file was later backed out in facebook/react-native@e3218a0d9 (see below), which is why it doesn't appear here. - The addition of the empty Swift file activated a wizard that walked the user through setting up an Objective-C "bridging header" file and set some plausibly desired settings in the `project.pbxproj` file. RN deleted the bridging header file, but the settings remained. We had actually already set up a bridging header file a long time ago, in d38129b, and this setup wizard didn't activate when I created the empty Swift file. I tried to *get* it to activate (to better reproduce the settings changes) by deleting our bridging header file and re-adding the Swift file, but the wizard didn't activate. However, the settings that got added in d38129b seem to match these settings pretty closely; one notable difference is that a SWIFT_VERSION build setting is 4.2 instead of 5.0. In any case, the upgrade guide on the Xcode changes [1] only says the bridging-header wizard will "most likely" appear, and if it doesn't, just keep going. - They added "English" under `knownRegions` in the project info. It appears Xcode doesn't like this change; it gets reverted later as part of facebook/react-native@ebb629d05 (which we take elsewhere in this series, before the upgrade, as an instance of zulip#4112), when they follow an Xcode automatic deprecation fix. So, ignore this. ----- facebook/react-native@e3218a0d9 ----- This Facebook commit looks fairly coherent, but it's a partial reversion of facebook/react-native@898b1db6d (just above) with a tweak on top of it. So, might as well put it into the same commit. The `project.pbxproj` changes are as follows, as best as I can tell: - The empty Swift file described just above is removed. The commit message makes it sound like it's no longer necessary for projects to make the Swift file in the first place; on the other hand, the upgrade guide on the Xcode changes [1] indicate that it should be created and then removed. - A `LIBRARY_SEARCH_PATHS` setting is added. This *is* reflected in the upgrade guide on the Xcode changes [1]; following those instructions does indeed generate a portion of the diff. - An `LD_RUNPATH_SEARCH_PATHS` setting is added; this is *not* reflected in the upgrade guide. It's reportedly crucial; see facebook/react-native#27922 (comment). I copied the code. - A `DEAD_CODE_STRIPPING` setting is removed; this is *not* reflected in the upgrade guide. Reportedly (and in my experience, as best as I can remember and conclude), it's crucial; see facebook/react-native#27922 (comment). I copied the code. ----- facebook/react-native@8f954b365 ----- Just simple prose adjustments to a comment, but it's substantially reworked in facebook/react-native@b4d1fcfb2 (which follows). ----- facebook/react-native@b4d1fcfb2 ----- This looks like a partial reversion of facebook/react-native@898b1db6d (above), with a tweak; the `FB_SONARKIT_ENABLED` conditional is removed from `AppDelegate.m`, but that identifier now appears in the `project.pbxproj`. `ENABLE_BITCODE = NO;` is added to the `project.pbxproj` to fix an issue introduced in facebook/react-native@898b1db6d (see above); see facebook/react-native#27565 (comment). The issue would be better resolved with something like facebook/flipper#1171. In particular, I'm inclined to agree with that PR's author, who says "it strikes me that not having access to current (and possible future) updates of a cryptography library is not a good long-term plan". This commit also continues the advancement of the FlipperKit pod's version, this time to v0.30.2, and adjusts some comments. ----- facebook/react-native@f6a8452e7 ----- After an upgrade to FlipperKit v0.32.0 in facebook/react-native@ada73a354, quickly reverted in facebook/react-native@4bb17944f, this commit brings us to v0.33.1. ----- facebook/react-native@8858d879e ----- This is the last commit that affects Flipper on iOS before the v0.62 release was made. It doesn't continue the advancement of the FlipperKit version (and a good thing, too, maybe!). It lists several transitive dependencies of FlipperKit pods to the Podfile and gives them each a `:configuration => 'Debug'` setting, and that's it. It appears to be accounting for a CocoaPods quirk that means that, before this change is made, all those dependencies would get included in release builds, increasing the binary size. Might as well avoid having any commits with that increased size; so, conclude this giant commit with these changes. All that's left is to actually enable Flipper, which we'll do after the main upgrade commit; see zulip#4244 (comment). [1] react-native-community/upgrade-support#13
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's nice to have as little noise as possible in the output of routine tasks like building for iOS with Xcode. We've made a strong effort to eliminate noise in the output of
yarn, which means we immediately notice new, often important warnings from our NPM dependencies that other projects likely ignore, to their detriment.We get a few messages while building with Xcode that say "Update to recommended settings". Unlike the majority of the warnings during the build, it seems like we might easily be able to do something about these.
So, this issue is to play around with that and see if we can understand and explain what these warnings are saying, clear them (Xcode has a handy "Perform Changes" button), and see if that breaks anything.
The text was updated successfully, but these errors were encountered: