Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flipper for React Native 0.62 #27565

Closed
23 of 30 tasks
rickhanlonii opened this issue Dec 18, 2019 · 38 comments
Closed
23 of 30 tasks

Flipper for React Native 0.62 #27565

rickhanlonii opened this issue Dec 18, 2019 · 38 comments
Labels
DX Issues concerning how the developer experience can be improved. p: Facebook Partner: Facebook Resolution: Locked This issue was locked by the bot. Type: Discussion Long running discussion.

Comments

@rickhanlonii
Copy link
Member

rickhanlonii commented Dec 18, 2019

Overview

This issue is to track items to get Flipper enabled for 0.62.

RNTester Integration

Default Template Integration

Upgrade Flipper SDK Version

Upgrading

Documentation

  • Add React Native the Flipper website
  • Add documentation to the website
    • Adding Flipper to new projects (mention included by default after 0.62)
    • Adding Flipper to existing projects
  • In Flipper Docs

Commits to Cherry Pick

@rickhanlonii rickhanlonii added the Type: Question Issues that are actually questions and not bug reports. label Dec 18, 2019
@react-native-bot

This comment has been minimized.

@react-native-bot react-native-bot added Ran Commands One of our bots successfully processed a command. Resolution: No Template labels Dec 18, 2019
@thymikee thymikee reopened this Dec 18, 2019
@charpeni charpeni added DX Issues concerning how the developer experience can be improved. and removed Resolution: No Template Type: Question Issues that are actually questions and not bug reports. labels Dec 18, 2019
@elicwhite elicwhite reopened this Dec 19, 2019
@elicwhite elicwhite added the p: Facebook Partner: Facebook label Dec 19, 2019
@elicwhite elicwhite reopened this Dec 19, 2019
@elicwhite
Copy link
Member

I give up. @hramos! 😭

@rmevans9
Copy link
Contributor

rmevans9 commented Dec 19, 2019

While working on a Flipper plugin it was noted that the inclusion of FlipperKit in the Podfile caused pods to need to install openssl-ios-bitcode which required building openssl for all the architectures. As you can imagine this takes a while. In a normal pod install the developer will not know what is going on likely as this is what they will see for a long time:

Screen Shot 2019-12-18 at 8 12 14 PM

If you run pod install --verbose you can actually see progress during this process. On my machine it took a good 10+ minutes to complete this install. The good news is once this pod is in your cache future pod installs are much quicker. If you would like to experience this first hand you can do the following steps:

  1. Run pod cache clear openssl-ios-bitcode
  2. Run pod install (include --verbose if you are interested in seeing what it is actually doing) in a ios folder of a RN project with the FlipperKit pods setup. If Pods have been installed previously do a rm -rf Pods/ for good measure too.

I understand the need for this library but it will be a jarring experience for developers upgrading and also for first time users of react-native. I feel like if we can't avoid it that it is at least worth calling attention to it so users don't cancel the pod install part way through and say its broken.

Edit: It seems maybe the openssl-ios-bitcode dependency changed here https://github.com/facebook/flipper/pull/577/files so maybe this is a non issue with the later versions of Flipper. My experience is based upon the Flipper version that was floating around the rn repository a while back - 0.23.6

@elicwhite
Copy link
Member

@rmevans9, I added that to the checklist. 👍

@charpeni charpeni added the Type: Discussion Long running discussion. label Dec 19, 2019
@charpeni charpeni reopened this Dec 19, 2019
@charpeni
Copy link
Contributor

@rmevans9 thanks for bringing that.

I confirm that bumping the version from 0.23.6 to 0.30.0 solved that issue, we now rely on OpenSSL-Universal (1.0.2.19) instead of openssl-ios-bitcode. I've just double checked, and openssl-ios-bitcode is not in Podfile.lock.

@charpeni charpeni removed Ran Commands One of our bots successfully processed a command. Resolution: No Template labels Dec 19, 2019
@charpeni charpeni reopened this Dec 19, 2019
@charpeni
Copy link
Contributor

Looks like I got you, bot!

@rmevans9
Copy link
Contributor

@charpeni ok perfect! I am glad that issue got solved with the upgrade.

@safaiyeh
Copy link
Contributor

safaiyeh commented Dec 19, 2019

Submitted a PR to initialize Flipper on Android & iOS based on the context from @axe-fb.

PR: #27569

Conversation: react-native-community/releases#145 (comment)

@mweststrate
Copy link
Contributor

@AndrewMorsillo please don't respond to closed issue as very little people will see them, and provide relevant reproduction information. "Doesn't work" is unactionable.

@ezranbayantemur
Copy link

ezranbayantemur commented May 4, 2020

After updating 0.61.5 to 0.62.2 ENABLE_BITCODE error drives me crazy. Not any problem while creating fresh project but it happens on upgrading to 0.62.2.

Trying to run on debug mode it gives error message on below. It happens only debug mode.

ld: '... project path .../ios/Pods/OpenSSL-Universal/ios/lib/libcrypto.a(bio_lib.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

It tried pod cache clear openssl-ios-bitcode on #27565 (comment) but it couldn't find openssl-ios-bitcode pod.

Any idea about it? @alloy

@mweststrate
Copy link
Contributor

@ezranbayantemur please don't respond to closed issue as only few people will see them, and it pings a people that don't have your specific issue needlessly. So please open a new issue instead :)

@ezranbayantemur
Copy link

@ezranbayantemur please don't respond to closed issue as only few people will see them, and it pings a people that don't have your specific issue needlessly. So please open a new issue instead :)

Oh my bad, I saw mentioned comments about it and didn't recognize it was closed.
Sorry for bother people 👍

@xgqfrms
Copy link

xgqfrms commented Jun 30, 2020

need help

$ pod install --verbose

#29251

stop, after installing here

image


$ pod install

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
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
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
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
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
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
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
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
@hongmaoxiao
Copy link

need help

$ pod install --verbose

#29251

stop, after installing here

image

$ pod install

same here! anyone knows how to solve it?

facebook-github-bot pushed a commit to facebook/flipper that referenced this issue Sep 16, 2020
Summary:
A few people reported issues due to the previous repo name (`Sonar`) being referenced in the Podfile.

- facebook/react-native#27565
- facebook/react-native#29251
- #1321

This PR updates it to the current name (`flipper`). Please let me know if these updates are also needed for the files under `Specs/Flipper/**/Flipper.podspec` (not sure what the purpose is).

Pull Request resolved: #1528

Reviewed By: nikoant

Differential Revision: D23730546

Pulled By: passy

fbshipit-source-id: b4d776f44a054f3fe8b793ca36a8fbc8835e5d04
@facebook facebook locked as resolved and limited conversation to collaborators Oct 2, 2021
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Oct 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
DX Issues concerning how the developer experience can be improved. p: Facebook Partner: Facebook Resolution: Locked This issue was locked by the bot. Type: Discussion Long running discussion.
Projects
None yet
Development

No branches or pull requests