Cache React Native iOS builds with sccache

[kieran-osgood-shopify]

Stack context

Part of the macOS CI migration and speed-up tracked in shop/issues-checkout-kit#1211, under shop/issues-checkout-kit#1202.

What?

• Adds an opt-in React Native iOS sccache launcher used by both sample build scripts.
• Enables it in both Bitrise React Native iOS workflows and persists the compiler cache across commits.
• Centralizes exact and fallback key generation in reusable restore/save step bundles.
• Uses Xcode's native C_COMPILER_LAUNCHER integration instead of treating sccache clang as an executable path.
• Starts the sccache daemon before invoking Xcode.
• Disables Clang header modules and response files for cached builds, as required by the upstream Xcode integration.
• Explicitly links the sample's existing CoreMotion dependency because disabling modules removes Reanimated's implicit framework auto-link metadata.

Why?

Shopify no longer permits ccache. sccache supports Xcode launchers, but deliberately bypasses Clang header-module invocations such as React Native's -fmodules calls. Following the complete upstream Xcode recipe makes every C, C++, and assembler invocation in these builds cacheable without wrappers or a banned dependency.

The integration remains opt-in locally with SCCACHE_ENABLED=1; Bitrise enables it for the two React Native iOS workflows. Android's existing sccache integration is unchanged.

Local performance

Each warm measurement deleted DerivedData while retaining only SCCACHE_DIR, forcing Xcode to reconstruct the build products from compiler-cache entries.

Workflow	Cold cache	Warm cache	Reduction	Warm hit rate
React Native sample build	259.12s	53.53s	79.3%	1,194 / 1,194 (100%)
React Native integration tests	201.52s	57.86s	71.3%	729 / 729 (100%)

Both cold runs had zero non-cacheable compiler calls, cache errors, or compilation failures.

Bitrise performance

The two affected workflows were first run cold and warm on separate Bitrise macOS machines. The warm runs restored an exact cache-key match. After moving key generation into shared step bundles, commit 48964fb3 was also run against the previous commit's cache: both workflows missed the new exact key, restored the branch-prefix fallback, and saved the cache under the newly generated exact key.

Workflow	Cold build step	Exact-key warm	Bundled branch-fallback run	Warm compiler result
React Native sample	3.6m	51.91s	44.79s	100% hits, 0 compilations
React Native integration tests	2.8m	56.95s	51.75s	729 / 729 hits, 0 compilations

All warm workflows passed with zero misses, non-cacheable calls, or cache errors.

Verification

• React Native iOS sample cold and warm builds: Build Succeeded
• React Native iOS integration cold and warm runs: 68 tests, 0 failures; Test Succeeded
• Repository dev style: passed
• Sample and integration CocoaPods installs with --deployment: passed
• Ruby script suite: 295 runs, 754 assertions, 0 failures
• bitrise validate --config=e2e/bitrise.yml: valid
• YAML parsing, shell syntax, and git diff --check: passed

[kieran-osgood-shopify]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Document the ci-ios pipeline and fix the stale Ruby pin in BITRISE.md #639
• Cache React Native iOS builds with sccache #638 👈 (View in Graphite)
• Cache DerivedData on the macOS build jobs and stop cleaning it away #637
• Port the remaining three macOS jobs to the Bitrise ci-ios pipeline #636
• Add ci-ios PR pipeline #635
• Increase CI script portability around xcbeautify #634
• Make the CocoaPods spec repo refresh opt-in on CI #633
• Drop the duplicate Swift compile in build_and_test_samples #632
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[kiftio]

yo, just browsing.. Should we use sccache to match up with what we run locally?