Store prebuilt versions of our custom iOS React Native artifacts

[mateuuszzzzz]

Background

Build times for standalone NewDot and HybridApp significantly impact developer productivity and CI efficiency. Faster builds enable quicker iterations and shorten the feedback loop when testing changes. Despite previous optimizations, build times remain high, affecting both local development and CI runs.

Problem

When engineers push new changes, long build times delay feedback, which slows down development and reduces overall efficiency.

Solution

We will introduce a system for storing and reusing build artifacts for our patched React Native versions instead of rebuilding React Native from source every time.

For Android, this approach is already in place and working.
For iOS, this capability is not yet implemented.

Artifacts will be regenerated only when patches on main or the React Native version change, which happens infrequently. The solution includes:

• Adding a mechanism to store and retrieve prebuilt artifacts, for example through a Maven repository (Meta also stores iOS artifacts on Maven)
• Automating version tracking to detect changes in patches and trigger artifact regeneration

[mateuuszzzzz]

I created tracking issue for iOS RN artifacts cc: @roryabraham

[roryabraham]

making this a weekly

[mateuuszzzzz]

Small update:

I’ve been working on two areas:

1. Build workflow
   This is similar to the existing Android workflow. It’s about 99% ready just needs some cleanup. It is strongly inspired by the upstream workflow, which publishes iOS artifacts to a Maven repository. We could take advantage of this and reuse our existing GitHub Packages Maven repository.

2. Podfile scripts for custom artifacts
   This is the next step. I looked into how React Native handles this, and it’s easy to apply our modifications there because Ruby classes are open, which lets us override methods to fit our needs.

One issue I ran into: when prebuilt artifacts are enabled, Xcode’s HMAP leaks Boost’s list header globally. This creates conflicts with another library that also includes own list header file. I’m currently looking for an elegant solution that requires minimal changes to the Xcode project and Podfile setup.

It’s a bit surprising, because when we build from source, this kind of leak doesn’t occur, which suggests that CocoaPods handles prebuilt binaries differently.

[mateuuszzzzz]

I’ll share all my findings on HMAP conflicts here once I’ve gathered a set of suitable solutions