You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Store prebuilt versions of our custom iOS React Native artifacts #86437
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
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.
Created and assigned to you: #100503 — Fix Hermes version mismatch between prebuilt iOS React Native artifacts and the app build. Labeled Engineering + Improvement, framed as a follow-up to this issue.
I couldn't read the swmansion Slack thread, so I linked it and seeded the issue with a starting hypothesis from the code instead. Two candidates, both in Expensify/App:
ios/Podfile:90 sets RCT_HERMES_V1_ENABLED = '1' and is the only place in the repo that sets it. The publish workflow passes only HERMES_VERSION (publishReactNativeiOSArtifacts.yml:65-77), so artifacts may be built without Hermes V1 while the app links it.
The resolution key is react-native version + patches hash (artifactsResolver.ts) with nothing about Hermes in it, so a mismatched artifact resolves as a match instead of falling back to a source build.
I marked that as unverified in the issue body — edit it if the Slack thread points somewhere else.
Fix merged ([No QA] Pin Hermes V1 version in artifacts iOS workflow, deployed 9.4.75-3) and artifacts republished successfully on 2026-09-15. Open only on the question you asked mateuuszzzzz: whether the publish workflow should also re-trigger on workflow-file edits. He's offered to raise that PR — needs your call.
We're getting closer to considering this issue done. Here are a few open PRs that are somehow related to this tracking issue. They're either follow-ups or small polish improvements aimed at improving our workflows around artifacts on iOS:
This issue has not been updated in over 15 days. @roryabraham, @mateuuszzzzz eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
Activity
mateuuszzzzz commentedon Mar 26, 2026
I created tracking issue for iOS RN artifacts cc: @roryabraham
roryabraham commentedon Apr 6, 2026
making this a weekly
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
92 remaining items
mateuuszzzzz commentedon Sep 7, 2026
@MelvinBot, an issue related to artifacts has been identified. In this thread https://swmansion.slack.com/archives/C08CZDJFJ77/p1788687366059049, a Hermes version mismatch was discovered.
Could you create a tracking issue to investigate and fix this problem and assign it to me?
MelvinBot commentedon Sep 7, 2026
Created and assigned to you: #100503 — Fix Hermes version mismatch between prebuilt iOS React Native artifacts and the app build. Labeled
Engineering+Improvement, framed as a follow-up to this issue.I couldn't read the swmansion Slack thread, so I linked it and seeded the issue with a starting hypothesis from the code instead. Two candidates, both in
Expensify/App:ios/Podfile:90setsRCT_HERMES_V1_ENABLED = '1'and is the only place in the repo that sets it. The publish workflow passes onlyHERMES_VERSION(publishReactNativeiOSArtifacts.yml:65-77), so artifacts may be built without Hermes V1 while the app links it.artifactsResolver.ts) with nothing about Hermes in it, so a mismatched artifact resolves as a match instead of falling back to a source build.I marked that as unverified in the issue body — edit it if the Slack thread points somewhere else.
roryabraham commentedon Sep 18, 2026
@MelvinBot what's the status of this issue?
MelvinBot commentedon Sep 18, 2026
Status: the core work is shipped. This issue is open only for three follow-ups, two of which are close to done.
Prebuilt iOS RN artifacts are live and consumed on HybridApp — [No QA] Create iOS RN artifacts workflow (deployed in 9.4.44-6) and [No QA] Add support for consuming React Native artifacts on iOS (deployed in 9.4.52-11), plus the dSYM and stale-cache fixes. Your own measurement was ~271s saved per cold local build.
What's still open
mikolajpochecpicked it up; the Mobile-Expensify-side PR he linked above is waiting on internal review.mateuuszzzzz: whether the publish workflow should also re-trigger on workflow-file edits. He's offered to raise that PR — needs your call.Closed follow-ups: Enable iOS prebuilt RN artifacts in staging and production CI workflows (nothing to enable — deploy scripts already had the token), Consume react-native dSYMs in staging and production CI workflows for Sentry symbolication, and Fix stale prebuilt React Native artifacts cache causing iOS dev build crashes.
The one thing needing you: reply to
mateuuszzzzzon #100503 about the workflow-edit trigger. The other two are waiting on their owners.view run
mateuuszzzzz commentedon Sep 25, 2026
Update:
We're getting closer to considering this issue done. Here are a few open PRs that are somehow related to this tracking issue. They're either follow-ups or small polish improvements aimed at improving our workflows around artifacts on iOS:
#98383
#98384
#101728
All of them have either merged PRs or PRs that are open and awaiting review/merge. Once all of them are completed, we can close this parent issue
melvin-bot commentedon Oct 19, 2026
This issue has not been updated in over 15 days. @roryabraham, @mateuuszzzzz eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
roryabraham commentedon Oct 21, 2026
@MelvinBot what's the status of this issue? What code work remains to be completed?
MelvinBot commentedon Oct 21, 2026
Status: almost done. The core iOS prebuilt artifacts work has shipped. Two open sub-tasks remain before you can close this issue.
Code work remaining
mateuuszzzzzplans to adjust it now that [No QA] Trigger artifacts workflow when artifacts workflow files change merged (Oct 20). Artifacts must be built for it before merge. You're waiting on their ping.mikolajpocheclinked on Sep 7. It was last reported as ready for internal review. I can't access that repo, so I can't confirm whether it merged.Done since the last update: [Due for payment 2026-09-30] Add iOS prebuilt RN artifacts support on standalone NewDot and [Due for payment 2026-10-05] iOS prebuilt RN artifacts: React-Core-prebuilt Podfile.lock checksum depends on the local absolute path are both closed and paid.
What needs you: review the Mobile-Expensify PR (or ask
mikolajpochecfor its status), and review the Hermes check PR once it's ready.view run