Flipper: Flipper should not get built on iOS release builds

[TPXP]

Hello,

As pointed by someone else in a related issue, when adding Flipper to a React-Native project (or I guess any project), building times get significantly increased. This is not desirable.

Impact: longer build times https://github.com/react-native-community/discussions-and-proposals/issues/226

Proposed solution: I'm thinking about adding flag DISABLE_FLIPPER, and wrap all files with #ifndef DISABLE_FLIPPER. I guess that would definitely help, but requires patching dependencies as well. Thoughts?

[Monkeystation]

Also when creating the archive, the file size is significantly larger. In the screenshot you'll see the default 'AwesomeProject' with Flipper (283MB) and without Flipper (removed from Podfile, 88MB)

[mweststrate]

@TPXP all our files for react-native-flipper have been wrapped recently in #ifdef DEBUG flags, however, that doesn't remove the build times for transitive dependencies as you noticed. I think these kind of issues should be solved on an infrastructural level by having conditional builds / dependencies or something, rather than here by monkey patching dependencies. Many deps are quit generic which might have a lot of unforeseen effect (e.g some other library might depend on a dependency flipper has a well, and a monkey patch would break those in production, which would bring us in a worse situation).

(disclaimer: I'm not too familiar with iOS builds in general)

[alloy]

@TPXP There is no need to add extra configuration, simply remove the lines that include Flipper from your Podfile.

[mweststrate]

@alloy can that be made conditional based on debug vs release build?

[alloy]

That already is conditional, alas it’s being hidden behind a layer of indirection https://github.com/facebook/react-native/blob/eb2a561ecb10a97d458cce53ee27b0fba655f018/scripts/react_native_pods.rb#L62-L90.

To re-iterate, it _will_ be build for release builds, but it will _not_ be linked.

[TPXP]

Thanks for your feedback, I didn't know that the files for react-native-flipper were wrapped in #ifdef DEBUG. Any reason why the files for Flipper and its subpackages don't have the same optimization?

Granted, I could remove the lines about flipper from the PodFile before creating a release build, but that requires installing pods again. It would work, but I'm sure we can find a better way to handle this!

[mweststrate]

Because these packages are used in different other environments, or could actually be a transitive dependency of your real project as well. So wrapping them could have very unintended consequences.

Closing the issues as there is further not anything we can do from our side.

[TPXP]

How about wrapping the code of these dependencies in a custom flag like #ifndef DISABLE_FLIPPER? This way, I think we can avoid building these tools when building production builds while not affecting projects using these tools as dependencies

[alloy]

@TPXP Have you by any chance tried and measured the actual impact of doing so?

[andreialecu]

I'm not sure why this wasn't proposed yet, but a simple ENV variable can help with this.

  if !ENV['CI']
    use_flipper!
    post_install do |installer|
      flipper_post_install(installer)
    end
  end

On CircleCI the above tweak resulted in dropping build times from about 14 minutes to 8 minutes.

[TPXP]

Well, such changes require to install dependencies for the Pods project to be updated (and Xcode to not build Flipper and its dependencies). It definitely makes sense in a CI environment, which is where build minutes are the most "costly". And since CI systems have to install pods anyway, it's smart to prevent bundling of flipper here.

I'm trying to see if this can be disabled also if the app is built on dev machines but your approach is definitely a good step forward :+1:

[TPXP]

I dug some more into this today. It seems we cannot inject custom definitions when working with Cocoapods anyway, since the only one ("Debug") is hardcoded, and configuration definition does not take into account the target for which the configuration is generated (see https://github.com/CocoaPods/CocoaPods/blob/56538172fac99b410046812df67087a8829a7019/lib/cocoapods/project.rb#L379).

This issue of pods being built even if not used in the configuration has already been raised to Cocoapods: https://github.com/CocoaPods/CocoaPods/issues/9658#issuecomment-605874654 . A few things have been attempted, but nothing landed yet.

I guess we'll have to implement a few things on Cocoapods before we can make progress on this.