ci: pin every version CI depends on

[dsnsgithub]

CI was breaking on changes nobody made here: an upstream MMKVCore release, a new Xcode on the macOS image, a floating action tag. Pin everything CI depends on so a green run stays reproducible.

Workflows

• Pinned runner images instead of the *-latest aliases, which follow new OS releases and swap Xcode, simulator runtimes and CocoaPods underneath an unchanged build: macos-26 for iOS, ubuntu-24.04 elsewhere.
• Actions pinned to exact patch tags (@v6.1.0) instead of floating majors (@v6). futureware-tech/simulator-action only publishes major tags, so @v4 is the most specific pin available there.
• Tool versions written inline at their use site: Bun 1.3.14, Temurin 21.0.11, Xcode 26.6, CocoaPods 1.17.0, Maestro 2.8.0.
• Xcode is selected explicitly rather than inherited from the image default. xcode-select --switch exits non-zero on a missing path, so a retired Xcode fails the job outright instead of silently falling through to whatever the image ships.
• CocoaPods is installed at the pinned version rather than taken from the image.
• Maestro is fetched as an immutable release asset instead of piping get.maestro.mobile.dev, which installs whatever is newest from a script that can itself change.
• The iOS simulator runtime (26.5) is pinned alongside the device model.

JavaScript dependencies

• Exact versions everywhere, no carets or tildes. bun ci is already frozen, but ranges still let a plain bun install drift, and they silently break patchedDependencies: react-native-mmkv floating to 3.3.4 would drop the app-group path patch with nothing failing until a widget misbehaved.
• turbo: latest → 2.7.1, the version the lockfile had already resolved.
• EAS CLI pinned to 22.0.0 in the mobile scripts and eas.json.
• bun.lock workspace ranges updated to match; no resolutions changed.

Native dependencies

Audited every podspec and build.gradle in the tree for versions resolved from a remote registry rather than from node_modules.

• PostHog was the one real gap. posthog-react-native-session-replay's podspec asks for PostHog ~> 3.21, satisfied by 115 published versions and currently resolving to 3.69.8. Now pinned in the app target's Podfile, same mechanism as MMKVCore.
• Everything else was already deterministic: react-native-mmkv compiles MMKV from vendored source, NotifeeCore builds from a local subspec, and Quick/Nimble/OHHTTPStubs/ExpoModulesTestCore are test_spec-only so they are never installed.
• On Android, app.notifee:core:+ resolves against notifee's bundled file repo, which ships exactly one version and is published to neither Maven Central nor Google Maven; com.facebook.react:react-native:+ is substituted by the RN Gradle plugin to the exact react-native version; org.webkit:android-jsc:+ has a single Maven Central artifact from 2015; and the Kotlin/Compose/Coil/Fresco interpolations read properties fixed inside their own packages.

Merge with main

main moved android builds to ubuntu (#14) and setup-java to v5 (#15) while this was open. Both decisions are kept, with the pinning re-applied on top: android runs on ubuntu-24.04 rather than ubuntu-latest, and setup-java is @v5.7.0 rather than the floating @v5.

Verification

Every job is green on this branch: lint, typecheck, test-web, test-android on ubuntu-24.04, and the full iOS run on macos-26 including the Maestro suite. Between them they exercise the Xcode select, the CocoaPods pin, the Maestro download, the simulator runtime pin, and the PostHog pod resolving during pod install.

What still isn't pinned

• CocoaPods binds only while the image ships nothing newer. gem install cocoapods -v 1.17.0 guarantees that version is present, but pod resolves to the newest installed, and EAS calls pod from PATH. Today macos-26 ships exactly 1.17.0 so the pin holds; a future image shipping newer CocoaPods would win.
• Node.js comes from the runner image. Pinning the image label pins it in practice, but patch bumps land.
• Ruby likewise; only the CocoaPods gem on top of it is pinned.
• Runner images are eventually retired. When macos-26 or ubuntu-24.04 goes, the job fails immediately with an unknown-label error rather than drifting — that is the intended failure mode, but it does mean re-pinning Xcode and CocoaPods to whatever the next image ships.
• Android SDK components Gradle downloads come from what the generated android/ project requests, which is set by the pinned Expo/React Native versions.

Claude-Session: https://claude.ai/code/session_01QRXxEuKNzgWvK2RxJjQ8TC

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
scheduli	Ready	Preview	Aug 20, 2026 11:36pm