Repository navigation
Prebuilt iOS Artifacts #87123
Description
Problem
When we build our React Native project, if we have custom patches of React Native iOS code, then we must build React Native iOS from source on every full native build, which takes ~10-15 minutes, lengthening our feedback loop and slowing our development velocity.
Solution
Set up prebuilt React Native artifacts on iOS, just as we have on Android.
Activity
roryabraham commentedon Apr 4, 2026
Chatted with @mateuuszzzzz about this 1:1. let's gooooooo
roryabraham commentedon Apr 6, 2026
whoops, this is a dupe
mateuuszzzzz commentedon Apr 8, 2026
Small update:
I’ve been working on two areas:
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.
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 commentedon Apr 8, 2026
I’ll share all my findings on HMAP conflicts here once I’ve gathered a set of suitable solutions
mateuuszzzzz commentedon Apr 8, 2026
Ah, now I noticed this one was closed, I'll paste my updates to another issue