[Due for payment 2026-06-25] [$250] Upgrade rock before RN 0.85 upgrade

[roryabraham]

Problem

We can't upgrade RN 0.85 until we upgrade rock

Solution

Upgrade rock

Issue Owner

Current Issue Owner: @mananjadhav

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022066622404758915209
• Upwork Job ID: 2066622404758915209
• Last Price Increase: 2026-06-15

[MelvinBot]

Issue Analysis

Summary: This is a prerequisite/tooling task, not a runtime bug. The App builds React Native through Rock (Callstack's RN build CLI), currently pinned to 0.12.10, while react-native is on 0.83.1. Rock 0.12.x predates RN 0.85's headline change — prebuilt React Native — so the RN 0.85 bump must be unblocked by first moving Rock onto the 0.13.x line, which added that support (feat: support prebuilt React Native, rock#696, shipped in v0.13.1).

Recommended fix: Bump all Rock packages from 0.12.10 to the latest 0.13.x (currently 0.13.4 on npm) as a standalone PR, ahead of the RN 0.85 upgrade:

• package.json:257-260 — @rock-js/platform-android, @rock-js/platform-ios, @rock-js/plugin-metro, @rock-js/provider-s3
• package.json:356 — rock
• Regenerate the lockfile and smoke-test npx rock start, rock run:ios, and rock run:android (the start script and CI build flows all go through Rock).

Investigation details

• Current pins (verified in package.json): react-native 0.83.1; rock, @rock-js/platform-android, @rock-js/platform-ios, @rock-js/plugin-metro, @rock-js/provider-s3 all at 0.12.10.
• npm rock dist-tag latest = 0.13.4. Available 0.13.x: 0.13.0 → 0.13.4.
• Rock v0.13.0 release notes also include feat: use metro config from plugin-metro; make config optional (rock#676) — relevant since the App uses @rock-js/plugin-metro and a custom metro config.
• No hard react-native peerDependency is declared on the Rock packages, so the constraint is functional (prebuilt-RN/template compatibility) rather than a semver gate — meaning the Rock bump can and should land independently first, then the RN 0.85 PR layers on top.
• This bump is build-tooling only; verification is "does the app still build and start via Rock," not a feature test.

Alternative considered: Bumping Rock and RN together in one PR. Not recommended — the issue explicitly scopes Rock as a blocker to de-risk, and a combined PR mixes two large dependency surfaces, making build regressions harder to bisect.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93629) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[lorretheboy]

Proposal

What is the root cause of that problem?

Rock is the build orchestrator that replaced the React Native CLI in this repo (npx rock start, @rock-js/* platform/bundler plugins). The pinned version 0.12.10 is hard-wired to the RN 0.83-era toolchain, so it cannot drive an RN 0.85 build.

The repo currently runs RN 0.83.1 and pins rock + its plugins at 0.12.10:

App/package.json

Line 175 in faeb512

"react-native": "0.83.1",

App/package.json

Lines 257 to 260 in faeb512

	"@rock-js/platform-android": "0.12.10",
	"@rock-js/platform-ios": "0.12.10",
	"@rock-js/plugin-metro": "0.12.10",
	"@rock-js/provider-s3": "0.12.10",

App/package.json

Line 356 in faeb512

"rock": "0.12.10",

The blocker is what those @rock-js 0.12.10 packages depend on internally. @rock-js/platform-android / platform-ios resolve @react-native-community/cli-* at ^20.0.0, and @rock-js/plugin-metro resolves metro* at ^0.83.3 — both are the versions that ship with RN 0.83. RN 0.85 ships a newer Community CLI (21.x) and Metro (0.85.x), so bumping react-native to 0.85 while keeping rock at 0.12.10 leaves the build running RN 0.83's autolinking/config and Metro internals against RN 0.85 source → autolinking and bundling break. The chain: rock 0.12.10 pins CLI 20 + Metro 0.83 → those drive rock start/native builds via pluginMetro() and the platform plugins in rock.config.mjs → RN 0.85's expected CLI/Metro version never gets used → the upgrade can't proceed.

This is exactly the toolchain wired in here:

App/rock.config.mjs

Lines 1 to 23 in faeb512

	import {platformAndroid} from '@rock-js/platform-android';
	import {platformIOS} from '@rock-js/platform-ios';
	import {pluginMetro} from '@rock-js/plugin-metro';
	import {providerS3} from '@rock-js/provider-s3';
	const isHybrid = process.env.IS_HYBRID_APP === 'true';
	const isPublicAccess = !process.env.AWS_ACCESS_KEY_ID || !process.env.AWS_SECRET_ACCESS_KEY;
	/** @type {import('@rock-js/config').Config} */
	export default {
	remoteCacheProvider: providerS3({
	bucket: 'ad-hoc-expensify-cash',
	region: 'us-east-1',
	acl: 'public-read',
	accessKeyId: process.env.AWS_ACCESS_KEY_ID,
	secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
	publicAccess: isPublicAccess,
	}),
	bundler: pluginMetro(),
	platforms: {
	ios: platformIOS({sourceDir: isHybrid ? './Mobile-Expensify/iOS' : './ios'}),
	android: platformAndroid({sourceDir: isHybrid ? './Mobile-Expensify/Android' : './android'}),
	},

What changes do you think we should make in order to solve the problem?

Upgrade rock first, as a standalone PR before the RN 0.85 bump. Bump rock and all four @rock-js/* packages to a release that targets RN 0.85's CLI 21 + Metro 0.85:

App/package.json

Lines 257 to 260 in faeb512

	"@rock-js/platform-android": "0.12.10",
	"@rock-js/platform-ios": "0.12.10",
	"@rock-js/plugin-metro": "0.12.10",
	"@rock-js/provider-s3": "0.12.10",

App/package.json

Line 356 in faeb512

"rock": "0.12.10",

Then regenerate package-lock.json, confirm the nested @react-native-community/cli-* and metro* deps resolve to the 21.x / 0.85.x line, and verify rock.config.mjs still validates against the new @rock-js/config type (the providerS3, pluginMetro, and platform* options here):

App/rock.config.mjs

Lines 9 to 31 in faeb512

	/** @type {import('@rock-js/config').Config} */
	export default {
	remoteCacheProvider: providerS3({
	bucket: 'ad-hoc-expensify-cash',
	region: 'us-east-1',
	acl: 'public-read',
	accessKeyId: process.env.AWS_ACCESS_KEY_ID,
	secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
	publicAccess: isPublicAccess,
	}),
	bundler: pluginMetro(),
	platforms: {
	ios: platformIOS({sourceDir: isHybrid ? './Mobile-Expensify/iOS' : './ios'}),
	android: platformAndroid({sourceDir: isHybrid ? './Mobile-Expensify/Android' : './android'}),
	},
	fingerprint: {
	extraSources: ['android/gradle.properties', 'ios/Podfile', 'scripts/compute-patches-hash.sh', 'patches', ...(isHybrid ? ['Mobile-Expensify/patches'] : [])],
	env: ['USE_WEB_PROXY', 'PUSHER_DEV_SUFFIX', 'SECURE_NGROK_URL', 'NGROK_URL', 'USE_NGROK', 'FORCE_NATIVE_BUILD'],
	ignorePaths: ['Mobile-Expensify/Android/assets/app/shared/bundle.js'],
	},
	// Forces React Native to build from source to include our custom patches
	usePrebuiltRNCore: false,
	};

Smoke-test npx rock start plus an iOS/Android build (both standalone and HybridApp sourceDir paths) on the current RN 0.83 to prove the new rock is backward-compatible, so the later RN 0.85 PR only changes RN itself.

What alternative solutions did you explore? (Optional)

Bump rock and RN 0.85 in a single PR. Workable but riskier — a build break can't be attributed cleanly to either the tooling or the RN upgrade, which is why splitting rock out first is preferred.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022066622404758915209