Optimise the size of iOS artifacts

[grabbou]

Problem

Right now, the artifact itself is rather large after all architectures, dSYMs, and bitcode were included - 2GB. We need to find a way to reduce this to a reasonably small size, so that it doesn't affect React Native users.

The goal is to reduce the size so that it comes w/o penalty for new React Native applications.

Solution

• Optimise size of hermes-engine-darwin npm package
  • Turn off bitcode (2GB with bitcode enabled for three architectures, 12MB without bitcode). While it saves the size, it makes it impossible to build React Native with bitcode, which comes "on" by default. Potential change in the default template possible as long as it makes sense to do so. We can also disable bitcode for iphonesimulator architectures as I think it makes no sense to ship that for non-release architectures (won't be able to build for simulator in the release tho)
  • Decide what to do with symbols - dSYM weights 200mb
• Make it optional package, so that users will have to install hermes-engine-darwin npm package on demand (unlike for Android) - size constraint doesn't affect the initial setup time. Potential degraded DX as it requires many actions to be done to enable Hermes
• Do not use npm for hermes-engine-darwin, but use CocoaPods dependency management mechanism. We can publish full Hermes to CocoaPods repository and it will be automatically installed as soon as React Native users change the flag in a Podfile to enable_hermes. This is done by removing path to a Hermes podspec that points to node_modules.
• Build Hermes in the user land (don't ship artifacts)

Opening this issue to discuss potential ways going forward and options that we have.

[alloy]

We can also disable bitcode for iphonesimulator architectures as I think it makes no sense to ship that for non-release architectures (won't be able to build for simulator in the release tho)

We definitely do not need bitcode for the simulator. IIRC, Xcode doesn’t even actually build bitcode until an archive release is built.

Are you saying Xcode won’t allow a simulator release build without the slice present?

Decide what to do with symbols

Symbols should be made available, at the very least for release builds in order to symbolicate crash reports. These could potentially be made available separately for when needed, but we have to take into account the possibility that RN users will not know/remember to do so and in turn struggle with unhelpful crash reports.

Do not use npm for hermes-engine-darwin, but use CocoaPods dependency management mechanism

I am in favour of not using npm. At first it seemed like it might be good to stay consistent for now, but it’s becoming clear that it’s only adding friction, with eg mow needing to decide when to install it.

Make it optional package, so that users will have to install hermes-engine-darwin npm package on demand

Strong yes on this from me.

FWIW I believe we also shouldn’t install the Android runtime by default and perhaps also not via npm.

Build Hermes in the user land

This would indeed solve the artefact size issue, but the build isn’t trivial to convert (although everything is doable) and would increase the build time of RN projects.

[grabbou]

Are you saying Xcode won’t allow a simulator release build without the slice present?

I believe when bitcode is turned on and simulator slices don't contain bitcode, the build will fail, unless you turn that off for that particular build. I am fine with that, but I am trying to think for the users as well.

My current preferred solution is to release Hermes to the CocoaPods repository with artifacts and have pod install automatically download required artifacts (no matter their size) as soon as users flip the hermes_enabled flag and re-run installation.

I think this is totally fine, given it's what Flipper does already here. I think the approach of using npm makes sense for smaller packages, such as community native modules. For a package like this one, where 100% is native code, I don't see any benefits of going that path.

[mhorowitz]

2gb! This sounds painful for everyone without the biggest network connections.

How does the CocoaPods repository release process work?

[alloy]

@mhorowitz CocoaPods isn’t a package manager, so it doesn’t host packages; this means we just need to serve the artefacts from somewhere, e.g. a GitHub release, and then point the CocoaPods podspec to that location.

CocoaPods also supports tarballs compressed with xz, so I’m interested in seeing how large the archive will be when compressed with that algorithm.

[grabbou]

I will experiment with that and post results at the beginning of next week.

[grabbou]

I am back after holidays, resuming my work on this one. Will keep you posted.

The plan here is to not build bitcode for non-release targets (simulator) and to ship to CocoaPods. That should offload the installation of Hermes until it is turned on via a Podfile.

[alloy]

To publish a podspec to the centralised spec repo, you need to follow the steps outlined here: https://guides.cocoapods.org/making/getting-setup-with-trunk.html

An important thing to note here is that, as we’re planning to distribute prebuilt binaries, the source attribute of the spec needs to be updated for each release and we can leave out the prepare_command entirely. It’s probably easiest to look for an env variable from within the podspec, e.g.:

spec.source = ENV['hermes-artefact-url'] ? ENV['hermes-artefact-url'] : { git: "https://github.com/facebook/hermes.git", tag: "v#{spec.version}" }

unless ENV['hermes-artefact-url']
  spec.prepare_command = '…'
end

And then do:

env hermes-artefact-url='…' pod trunk push hermes.podspec

[mhorowitz]

Thanks, @alloy, a couple more questions.

1. If we push a podspec with ENV checks for the binary artifact, won't the user of the pod need to set the env var in order to download the prebuilt version? Is this something the RN podspec would do?

2. How does versioning work? In the future when we create v0.8.0 for use by rn 0.65, how do we have rn 0.64 continue to use hermes v0.7.x? Is there any mechanism for automatic updates to new patch releases?

[alloy]

1. When you push a podspec it will be serialized to JSON, so the evaluation results are then recorded and won’t require the user to do anything.

2. Setting version requirements on “pods” works similarly as with eg npm. That is, the React-Core/Hermes module in the React-Core.podspec in RN will have a requirement such as ~> 0.7, which indicates any 0.7.x (preferably the latest possible) will be used.