Bundle, build and run iOS test app in separate steps in production + ccache enabled (#427)

* Bundle, build and run iOS test app in separate steps in production

* Boot the simulator and use an older xcode

* Print module path on framework slicing failure

* Add x86_64-apple-ios as a default target on an Apple host

* Use ad-hoc signing

* Build app for "iOS Simulator"

* Bundle the test app before running pod install

react-native-test-app resolves the resources declared in app.json when it
generates the workspace (validate_resources in ios/test_app.rb), warning
about and skipping any that don't exist yet:

  CocoaPods will not include resources it cannot find: [...] The app will
  still build and run if they are served by the dev server. To include
  missing resources, make sure they exist, then run `pod install` again.

Bundling after `pod install` therefore left dist/main.ios.jsbundle out of
the app, so it expected a Metro dev server that CI never starts.

Also pass `--assets-dest dist` rather than `dist/res`: dist/res is the
Android convention, whereas React Native's iOS bundler writes into
<assets-dest>/assets and app.json declares dist/assets for iOS.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Pick an available iPhone simulator instead of hard-coding one

"iPhone 17" only exists on the Xcode versions that shipped it, and
macos-latest rolls forward, so hard-coding a device name means the boot
step breaks on a runner image update. Query simctl for the first available
iPhone instead, wait for it with `bootstatus -b`, and address it by UDID in
the later steps rather than relying on the "booted" alias.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Don't let xcbeautify mask a failing xcodebuild

GitHub Actions runs a bare `run:` step as `bash -e {0}`, without pipefail,
so `xcodebuild ... | xcbeautify` reports xcbeautify's exit code and a
failing build is swallowed. Naming the shell explicitly opts into
`bash --noprofile --norc -eo pipefail`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Disable explicit modules so the ccache build works

The Release build failed with every system module unbuildable:

  module '_c_standard_library_obsolete' requires feature
  'found_incompatible_headers__check_search_paths'
  could not build module '_Builtin_float' / 'CoreFoundation' / 'Foundation'

preceded by 116 copies of:

  note: Explicit modules is enabled but the compiler was not recognized;
  disable explicit modules with CLANG_ENABLE_EXPLICIT_MODULES=NO, or use
  C_COMPILER_LAUNCHER with CLANG_ENABLE_EXPLICIT_MODULES_WITH_COMPILER_LAUNCHER=YES
  if using a compatible launcher

USE_CCACHE=1 makes React Native's Podfile integration point CC/CXX at its
scripts/xcode/ccache-clang{,++}.sh wrappers. Xcode does not recognise a
wrapper script as a compiler, so it cannot build explicit modules with it.

Of the two fixes Xcode suggests, this takes the first: it keeps ccache,
which is the point of the change. The second would need React Native to
configure ccache through C_COMPILER_LAUNCHER rather than by overriding
CC/CXX, which it does not do as of 0.81.4.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Wire ccache through C_COMPILER_LAUNCHER instead of USE_CCACHE

The previous commit silenced the "Explicit modules is enabled but the
compiler was not recognized" notes but did not fix the build: the module
errors remained, so explicit modules was a symptom rather than the cause.

The cause is which compiler runs. USE_CCACHE makes React Native set
CC/CXX/LD/LDPLUSPLUS to scripts/xcode/ccache-clang{,++}.sh, whose last line
is:

  exec $CCACHE_BINARY clang "$@"

That `clang` is unqualified, so it resolves off PATH rather than to Xcode's
toolchain. This job runs aminya/setup-cpp, which puts an LLVM toolchain on
PATH, so the build compiles against the iOS SDK with a compiler that does
not match it. Apple traps precisely this:

  module '_c_standard_library_obsolete' requires feature
  'found_incompatible_headers__check_search_paths'

and every system module (_Builtin_float, CoreFoundation, Foundation,
CoreGraphics, UIKit) then fails to build. main is unaffected because it
never sets USE_CCACHE for the app build.

So drop USE_CCACHE and use Xcode's compiler-launcher support instead, which
keeps Xcode's own clang and only prefixes it with ccache. Explicit modules
stays enabled, opted in for a launcher as Xcode's diagnostic describes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Retry pod install on the CocoaPods null-byte flake

CocoaPods intermittently aborts while generating the Pods project:

  ArgumentError - pathname contains null byte
  cocoapods/project.rb:452 Pod::Project#group_for_path_in_group

It hit 2 of the 4 pod install runs on this branch, twice ending the job
before the build step ran at all. It is an unresolved upstream bug that
CocoaPods' own issue matcher points at, specific to pnpm monorepos:
CocoaPods/CocoaPods#12866 and #12798. 1.17.0 is the newest release on
RubyGems (2026-07-06) and is the version that fails, so there is no fixed
version to move to and a workaround is the only option here.

The retry is deliberately narrow: only a failure whose output carries that
exact signature is retried, so any genuine pod install error still fails
the step immediately, and each retry emits a ::warning:: annotation so the
flake stays visible in the run summary instead of being silently absorbed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* ci: stop piping the iOS xcodebuild through xcbeautify

Follows #391, which dropped xcbeautify from the macOS job and noted it was
the only use of it in the repo. This branch forked before that landed, so
rebasing brought it back for iOS — it should go the same way.

Its stated failure mode showed up here too. Diagnosing the Release build on
this branch, "** ARCHIVE FAILED **" and the failed-command list printed
~150 lines *before* the compiler errors that explained them, because
xcbeautify's stdout is block-buffered through the pipe. The summary read as
the whole story and pointed at the wrong cause.

Raw xcodebuild output is verbose but complete and correctly ordered. It
also makes the pipefail guard added earlier on this branch unnecessary: the
step's exit code is now xcodebuild's own, so `shell: bash` goes too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Trim the inline comments in the iOS job

Comment-only; the non-comment diff is empty. Keeps the load-bearing facts —
why bundling precedes pod install, why USE_CCACHE is not set, the upstream
issue behind the pod install retry and the condition for dropping it — and
cuts the surrounding explanation.

* Apply React Native's ccache tuning to the Xcode build

The first green run cached almost nothing: 2160 of 2190 calls uncacheable,
and the 30 hits came from the CMake bootstrap rather than Xcode.

React Native ships scripts/xcode/ccache.conf for exactly this, but it only
takes effect through their ccache-clang.sh wrapper, which sets
CCACHE_CONFIGPATH to it. Moving ccache to a compiler launcher dropped the
wrapper and with it that config, leaving ccache on its defaults — under
which Xcode's -fmodules, precompiled headers, -index-store-path and
-ivfsoverlay all make a compile "too hard" to cache.

So set the same options directly. They land in the config file the ccache
action already writes, which is where the launcher's ccache reads them from,
so the previous CCACHE_DIR/MAXSIZE/COMPILERCHECK exports are now redundant
and go.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

* Give the iOS ccache room to hold a whole build

With React Native's tuning applied, cacheable calls went from 30/2190
(1.37%) to 1082/2185 (49.52%). The cache could not hold the result:

  Cache size (GB):  0.5 /  0.5 (99.76%)
  Cleanups:          88

500M is the action's default. One build filled it and evicted 88 times, so
most of the 1052 newly-cached objects were discarded before the build
finished, and none survive for the next run to hit.

Raised on the iOS job only, which is the one building React Native from
source; the other jobs stay on the default.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: kraenhansen

.changeset/spotty-readers-go.md

@@ -0,0 +1,5 @@
+---
+"react-native-node-api": patch
+---
+
+Print module path on framework slicing failure

.changeset/true-ideas-retire.md

@@ -0,0 +1,5 @@
+---
+"ferric-cli": patch
+---
+
+Add x86_64-apple-ios as a default target on an Apple host

.github/workflows/check.yml

@@ -117,7 +117,7 @@ jobs:
         uses: android-actions/setup-android@v4
         with:
           packages: tools platform-tools ndk;${{ env.NDK_VERSION }}
-      - run: rustup target add x86_64-linux-android aarch64-linux-android armv7-linux-androideabi i686-linux-android aarch64-apple-ios-sim
+      - run: rustup target add x86_64-linux-android aarch64-linux-android armv7-linux-androideabi i686-linux-android aarch64-apple-ios-sim x86_64-apple-ios
       - run: pnpm install
       - run: pnpm run bootstrap
       - run: pnpm test
@@ -170,6 +170,19 @@ jobs:
       - uses: pnpm/action-setup@v6
         with:
           cache: true
+      # Device names change with every Xcode release, so pick one dynamically.
+      - name: Boot the simulator
+        run: |
+          SIMULATOR_UDID=$(xcrun simctl list devices available --json | node -e "
+            const { devices } = JSON.parse(require('node:fs').readFileSync(0, 'utf8'));
+            const runtimes = Object.keys(devices).filter((r) => r.includes('iOS')).sort();
+            const device = runtimes.flatMap((r) => devices[r]).find((d) => d.name.startsWith('iPhone'));
+            if (!device) throw new Error('Found no available iPhone simulator');
+            console.log(device.udid);
+          ")
+          echo "Booting $SIMULATOR_UDID"
+          xcrun simctl bootstatus "$SIMULATOR_UDID" -b
+          echo "SIMULATOR_UDID=$SIMULATOR_UDID" >> $GITHUB_ENV
       - name: Setup cpp tools
         uses: aminya/setup-cpp@v1
         with:
@@ -178,28 +191,71 @@ jobs:
         uses: hendrikmuhs/ccache-action@v1.2.23
         with:
           key: ${{ github.job }}-${{ runner.os }}
-      - name: Set up JDK 17
-        uses: actions/setup-java@v5
-        with:
-          java-version: "17"
-          distribution: "temurin"
-      - name: Setup Android SDK
-        uses: android-actions/setup-android@v4
-        with:
-          packages: tools platform-tools ndk;${{ env.NDK_VERSION }}
-      - run: rustup target add x86_64-linux-android aarch64-linux-android armv7-linux-androideabi i686-linux-android aarch64-apple-ios-sim
+          # The action defaults to 500M, which a from-source React Native build
+          # fills mid-build: it evicted 88 times in one run, discarding most of
+          # what it had just cached.
+          max-size: 3G
+      - run: rustup target add aarch64-apple-ios-sim x86_64-apple-ios
       - run: pnpm install
       - run: pnpm run bootstrap
         env:
           CMAKE_RN_TRIPLETS: arm64;x86_64-apple-ios-sim
-          FERRIC_TARGETS: aarch64-apple-ios-sim
-      - run: pnpm run pod-install
+          FERRIC_TARGETS: aarch64-apple-ios-sim,x86_64-apple-ios
+      # Mirrors React Native's scripts/xcode/ccache.conf, which only applied
+      # while ccache ran through their wrapper script (it sets CCACHE_CONFIGPATH
+      # to it) and so no longer does now that it runs as a compiler launcher.
+      # Without this sloppiness Xcode's modules, PCH and index-store flags leave
+      # ccache treating almost every compile as uncacheable.
+      - name: Tune ccache for Xcode
+        run: |
+          ccache --set-config sloppiness=clang_index_store,file_stat_matches,include_file_ctime,include_file_mtime,ivfsoverlay,pch_defines,modules,system_headers,time_macros
+          ccache --set-config file_clone=true
+          ccache --set-config depend_mode=true
+          ccache --set-config inode_cache=true
+      # Must precede `pod install`: react-native-test-app embeds the resources
+      # declared in app.json when generating the workspace, skipping missing
+      # ones, and the app would then expect a Metro dev server at runtime.
+      # `--assets-dest dist` lands assets in dist/assets, as app.json expects.
+      - name: Bundle test app
+        run: pnpm exec react-native bundle --entry-file index.ts --platform ios --dev false --minify false --bundle-output dist/main.ios.jsbundle --assets-dest dist
         working-directory: apps/test-app
-      - name: Run tests (iOS)
-        run: pnpm run test:ios:allTests
-        # TODO: Enable release mode when it works
-        # run: pnpm run test:ios:allTests --mode Release
+      # No USE_CCACHE: it points CC/CXX at React Native's ccache-clang.sh, whose
+      # bare `clang` resolves to setup-cpp's LLVM instead of Xcode's, breaking
+      # every system module. Ccache goes on the xcodebuild invocation instead.
+      #
+      # Retries the intermittent CocoaPods/CocoaPods#12866 "pathname contains
+      # null byte" crash, and only that. Drop once CocoaPods > 1.17.0 fixes it.
+      - name: Install pods
+        shell: bash
         working-directory: apps/test-app
+        run: |
+          for attempt in 1 2 3; do
+            if pnpm run pod-install 2>&1 | tee "$RUNNER_TEMP/pod-install.log"; then
+              exit 0
+            fi
+            if ! grep -q 'pathname contains null byte' "$RUNNER_TEMP/pod-install.log"; then
+              echo "::error::pod install failed for an unrelated reason"
+              exit 1
+            fi
+            echo "::warning::pod install hit CocoaPods/CocoaPods#12866 (attempt ${attempt}/3), retrying"
+          done
+          echo "::error::pod install kept failing with CocoaPods/CocoaPods#12866"
+          exit 1
+      # Raw xcodebuild output, not piped through xcbeautify — see #391.
+      # C_COMPILER_LAUNCHER keeps Xcode's own clang and just prefixes it with
+      # ccache; explicit modules needs opting in when a launcher is used.
+      - name: Build test app
+        run: xcodebuild archive -workspace ReactTestApp.xcworkspace -configuration Release -scheme ReactTestApp -destination "generic/platform=iOS Simulator" -archivePath ./build/test-app.xcarchive CODE_SIGN_IDENTITY="-" CODE_SIGNING_ALLOWED=YES C_COMPILER_LAUNCHER=ccache CLANG_ENABLE_EXPLICIT_MODULES_WITH_COMPILER_LAUNCHER=YES
+        working-directory: apps/test-app/ios
+      - name: Run test app
+        run: |
+          # Install the app
+          xcrun simctl install "$SIMULATOR_UDID" ./ios/build/test-app.xcarchive/Products/Applications/ReactTestApp.app
+          # Run Mocha Remote wrapping the launch of the app
+          pnpm exec mocha-remote --exit-on-error -- xcrun simctl launch --terminate-running-process --console-pty "$SIMULATOR_UDID" com.microsoft.ReactTestApp
+        working-directory: apps/test-app
+        env:
+          MOCHA_REMOTE_CONTEXT: allTests
   test-macos:
     # Disabling this on main for now, as initializing the template takes a long time and
     # we don't have macOS-specific code yet. Currently also blocked on react-native-macos:

packages/ferric/src/build.ts

@@ -207,6 +207,7 @@ export const buildCommand = new Command("build")
           if (isAppleSupported()) {
             if (process.arch === "arm64") {
               targets.add("aarch64-apple-ios-sim");
+              targets.add("x86_64-apple-ios");
             }
           }
           logNotice(

packages/host/src/node/cli/apple.ts

@@ -508,7 +508,7 @@ export async function linkXcframework({
   });
   assert(
     framework,
-    `Failed to find a framework slice matching: ${JSON.stringify(expectedSlice)}`,
+    `Failed to find a framework slice of '${modulePath}' matching: ${JSON.stringify(expectedSlice)}`,
   );
 
   const originalFrameworkPath = path.join(