fix(rnapp): regenerate iOS Podfile.lock for React Native 0.87

[KisaneNeko]

Human readable summary

CI failed to run CI / iOS road test & E2E (AppleApp - Vanilla) in my PR

This was not related to my work though, and also happened in this unrelated PR

The reason was outdated lockfile (after RN upgrade)

The bug

iOS road test & E2E (AppleApp - Vanilla) fails at Install pods (RN vanilla app, E2E):

[!] CocoaPods could not find compatible versions for pod "ReactNativeDependencies"

The RN 0.87 upgrade never regenerated the iOS lockfile:

apps/RNApp/package.json	react-native: 0.87.0
apps/RNApp/ios/Podfile.lock	ReactNativeDependencies (0.85.0) — and 126 pods pinned at 0.85.0
0f1b85d "feat: upgrade RN App to 0.87.0 (#447)"	touched zero files under apps/RNApp/ios/

Why it took three weeks to show up

The pods cache key is hashFiles(Podfile.lock). The stale lock never changed, so the key never changed, and a warm cache kept pod install from having to re-resolve. It broke on the first cold run after the cache aged out — run 34582797299 on 11 Sep, and every run since.

Only the Vanilla job is affected: this is the repo's only tracked Podfile.lock, and the Expo 56/57 jobs install pods under apps/ExpoApp56/57 instead. That matches what CI shows — Expo variants green, Vanilla red.

The fix

Regenerated apps/RNApp/ios/Podfile.lock with CocoaPods 1.15.2 (matching apps/RNApp/Gemfile.lock) on Ruby 3.2 (matching CI). One file. PODFILE CHECKSUM is unchanged, so the Podfile itself didn't change — only the resolution.

Verified locally

Reproduced the failure on a clean main checkout first — byte-identical error, exit 1 — then confirmed the fix:

• RCT_USE_PREBUILT_RNCORE=0 pod install (the failing CI step), cold, no Pods/ → exit 0, 89 pods installed
• plain pod install (the non-E2E path) → exit 0
• result: ReactNativeDependencies (0.87.0), zero pods left at 0.85.0

Worth knowing: the two pod install variants CI runs produce structurally different lockfiles — the prebuilt path adds React-Core-prebuilt throughout, the source path doesn't. Both resolve cleanly against this lockfile, so it doesn't block anything; whichever job runs just rewrites it locally. I committed the default (prebuilt) variant because the tracked project.pbxproj references Pods_RNApp.framework, so it stays internally consistent with what a plain pod install produces.

Not included

Nothing currently fails when the lockfile drifts, which is the reason this hid for three weeks. A guard would catch it immediately:

pod install
git diff --exit-code Podfile.lock

Left out to keep this PR to the fix — happy to add it here or separately.

🤖 Generated with Claude Code