I Split Rork and Claude Code by Who Owns the Build Environment

Checking How Far the Config Reaches

Landing rate describes the past. For work that has not started yet, app.json gives you a preview. This script sorts configuration keys into "closes inside a generation prompt" and "requires agreement on the native side."

#!/usr/bin/env node
// Read app.json / app.config.json and separate configuration keys into
// "resolvable inside a generation prompt" and "requires native-side agreement."
// Usage: node config-reach.mjs [path to app.json]
import { readFileSync, existsSync } from "node:fs";
 
const path = process.argv[2] ?? "app.json";
if (!existsSync(path)) {
  console.error(`Config file not found: ${path}`);
  process.exit(1);
}
const expo = JSON.parse(readFileSync(path, "utf8")).expo ?? {};
 
// Keys that require native-side agreement: signing, capabilities, review answers
const NATIVE_BOUND = {
  "ios.entitlements": "Requires enabling the capability and regenerating provisioning",
  "ios.infoPlist.UIBackgroundModes": "Declares background execution; you explain the use case at review",
  "ios.infoPlist.LSApplicationQueriesSchemes": "Pre-declares schemes you may query; capped at 50 entries",
  "ios.associatedDomains": "Only works paired with apple-app-site-association on your server",
  "android.permissions": "Propagates into runtime rationale and Play declaration forms",
  "android.blockedPermissions": "Cancels permissions a dependency injects on its own",
};
 
const get = (obj, dotted) =>
  dotted.split(".").reduce((o, k) => (o == null ? undefined : o[k]), obj);
 
const bound = [];
for (const [key, why] of Object.entries(NATIVE_BOUND)) {
  const v = get(expo, key);
  if (v == null) continue;
  const count = Array.isArray(v) ? v.length : Object.keys(v).length;
  bound.push({ key, count, why });
}
 
// Purpose strings are a recurring rejection cause, so count them separately
const info = expo.ios?.infoPlist ?? {};
const purposeStrings = Object.entries(info)
  .filter(([k]) => k.startsWith("NS") && k.endsWith("UsageDescription"))
  .map(([k, v]) => ({ key: k, length: String(v).length }));
 
// A config plugin referenced by local path means you are editing native generation
const plugins = (expo.plugins ?? []).map((p) => (Array.isArray(p) ? p[0] : p));
const localPlugins = plugins.filter((p) => typeof p === "string" && p.startsWith("."));
 
console.log(`# Configuration reach for ${expo.name ?? path}\n`);
 
console.log("## Requires native-side agreement");
if (bound.length === 0) console.log("  none (everything closes inside generation)");
for (const b of bound) console.log(`  - ${b.key} (${b.count}) ... ${b.why}`);
 
console.log("\n## Purpose strings");
if (purposeStrings.length === 0) console.log("  none");
for (const p of purposeStrings) {
  const flag = p.length < 20 ? "  <- too short; state the use and the outcome" : "";
  console.log(`  - ${p.key} (${p.length} chars)${flag}`);
}
 
console.log("\n## Local config plugins");
if (localPlugins.length === 0) console.log("  none");
for (const p of localPlugins) console.log(`  - ${p} ... verify it survives each regeneration`);
 
const score = bound.length + localPlugins.length;
console.log(
  `\nVerdict: ${score} concern(s) sitting on the native side.` +
    (score === 0
      ? " Generation alone can carry this."
      : score <= 2
        ? " Generation primary, native secondary works."
        : " Putting the native side first will cost you less rework."),
);

Pointed at a project using background audio, HealthKit, and the photo library:

# Configuration reach for wallpaper-demo

## Requires native-side agreement
  - ios.entitlements (1) ... Requires enabling the capability and regenerating provisioning
  - ios.infoPlist.UIBackgroundModes (1) ... Declares background execution; you explain the use case at review
  - ios.infoPlist.LSApplicationQueriesSchemes (2) ... Pre-declares schemes you may query; capped at 50 entries
  - android.permissions (1) ... Propagates into runtime rationale and Play declaration forms

## Purpose strings
  - NSPhotoLibraryAddUsageDescription (13 chars)  <- too short; state the use and the outcome

## Local config plugins
  - ./plugins/withAudioBackgroundMode ... verify it survives each regeneration

Verdict: 5 concern(s) sitting on the native side. Putting the native side first will cost you less rework.

The length check on purpose strings exists because short ones draw rejections. "Saves to your photo library" is a restatement of the API name. It never says why you collect it or what happens to the user, and automated review analysis flags exactly that gap. Twenty characters is a deliberately loose warning line; in practice I read each one and ask whether both the reason and the outcome are present.

The value here is less in the verdict line than in seeing the list and recognizing instantly that these items sit outside generation. Prompt for "add a feature that uses HealthKit" and the generator returns code. Enabling the capability and regenerating the provisioning profile stay on your side of the fence.

Pinning the Boundary So You Can Restore It

Once you decide to touch the native layer, the next thing you meet is regeneration. In Expo SDK 57, expo prebuild now discards and recreates ios/ and android/ by default. The line you added by hand disappears without a word.

The worst version of this is reaching submission without noticing, so I pin the diff as a patch and check whether it still applies.

#!/usr/bin/env bash
# Pin hand-made native diffs as a patch and verify they still apply after regeneration.
# Usage: ./pin-native.sh save   ... save the current native diff to native.patch
#        ./pin-native.sh check  ... report whether the saved patch applies (never applies it)
set -euo pipefail
PATCH="native.patch"
BASE="${BASE_REF:-$(git rev-list --max-parents=0 HEAD | tail -1)}"
PATHS=(ios android)
 
case "${1:-}" in
  save)
    git diff "$BASE" -- "${PATHS[@]}" > "$PATCH"
    lines=$(grep -c '^[+-][^+-]' "$PATCH" || true)
    echo "Saved $PATCH (${lines:-0} changed lines)"
    echo "-> the closer this is to zero, the safer regeneration becomes"
    ;;
  check)
    [ -s "$PATCH" ] || { echo "Patch is empty; generation covers everything"; exit 0; }
    if git apply --check --reverse "$PATCH" 2>/dev/null; then
      echo "Already applied (the diff is present in the current tree)"
    elif git apply --check "$PATCH" 2>/dev/null; then
      echo "Not applied, but it still applies cleanly"
    else
      echo "Conflict: generation rewrote your native settings"
      echo "-> move the affected lines into a config plugin"
      exit 1
    fi
    ;;
  *) echo "usage: $0 {save|check}"; exit 2 ;;
esac

I verified all three states in a scratch repository. Right after saving, it reports "Already applied." After resetting the native directories to their initial state, it reports "Not applied, but it still applies cleanly." Once generation rewrites the same lines, it reports a conflict and exits 1.

There is a fourth state the branch doesn't cover, though. expo prebuild --clean rebuilds ios/ from scratch, so by the time you run the check the directory itself may be gone. Run check in that state and you get this:

Conflict: generation rewrote your native settings
-> move the affected lines into a config plugin

It isn't a conflict. The raw message from git apply --check is error: ios/Info.plist: No such file or directory — there is simply nothing to apply the patch to yet. Read that as a conflict and you'll start a config-plugin migration for a problem that a single prebuild would have solved. I only avoided that because I happened to be watching the raw --check output; trusting the script's wording alone would have cost me the afternoon.

Telling the two apart takes one pass over the patch's target paths before the existing branch runs:

    # insert at the top of the check branch
    missing=0
    while IFS= read -r f; do
      [ -e "$f" ] || { echo "  missing target: $f"; missing=$((missing+1)); }
    done < <(grep '^+++ b/' "$PATCH" | sed 's|^+++ b/||')
    if [ "$missing" -gt 0 ]; then
      echo "Native directories not generated yet (${missing} missing). Run prebuild first."
      exit 0
    fi

Exiting 0 is deliberate, since this isn't a failure. Wired into CI, a pre-prebuild job shouldn't go red for it. What deserves to fail the build is moving forward without noticing something vanished — not the fact that it hasn't been generated yet. Blur that line and the check stops being taken seriously.

--check is there because not applying is the point. Auto-applying leaves you unable to tell whether you overwrote the generator's change or preserved your own. Report whether it applies; let a human decide. That one restraint saves the entire session you would otherwise spend asking why a setting vanished.

BASE_REF is overridable because the first commit in a repository is rarely the same thing as "the state right after generation." The commit where you imported the generated output is the value you actually want to pass.

The changed-line count doubles as a risk gauge. Zero means regenerate freely. A handful means moving them into config plugins is realistic work. Several hundred means the honest conclusion is that the build environment already lives with you — take ios/ and android/ out of .gitignore and track them properly.

Four Ways the Measurement Goes Wrong

Taking the three scripts above into your own setup, these are the traps I hit or nearly hit. Each one quietly turns the numbers into a lie, and none of them announces itself as a failure.

1. ios/ and android/ are still in .gitignore while you count

In the default Expo layout, native directories are treated as generated output and sit in .gitignore. Run native-landing.sh in that state and the native count comes back as zero. Reading a 0% landing rate as "generation covers everything" is the single most likely misreading of this article.

The fix is trivial — confirm tracking before you measure:

git check-ignore -v ios android 2>/dev/null || echo "tracked"

If they are ignored, read the config and plugin layer instead: the volume of change in app.json and plugins/. The native reality is merely absent from git; it is not absent from your week.

2. You apply the patch and then run check

pin-native.sh check exists to tell you whether the patch applies. Run it right after a manual git apply and it will report "already applied," which removes the only chance you had to detect a conflict. The order is regenerate, check, decide, apply. Reverse it and this check protects nothing.

I very nearly did this myself, and did not notice until I reread why the --reverse branch is evaluated first.

3. The same setting lives in both app.json and a config plugin

This is the normal state halfway through a migration. Writing it in both places is not an error; one simply wins. Which one wins is invisible until you inspect the built Info.plist, and it typically surfaces as behavior that differs between a local run and a distribution build.

Once you finish moving a setting, delete it from app.json. I recommend putting that cleanup in the same commit as the move — deferred to a later commit, it stays forever.

4. Deleted files, and renamed ones, are still being counted

I found this one by going back and doubting my own script, and it's the worst-behaved of the four. What git log --name-only hands you is every path that ever appeared in the history — not the files that exist now. So once you've moved an ios/ setting into a config plugin and deleted the original, that path keeps counting as native work forever.

I reproduced it in a scratch repository: six JS screens, five native config files, a dozen screen updates, and then App.entitlements, Podfile and gradle.properties moved into config plugins and removed.

Ten points on the landing rate, but look at the native row on its own: five files reported, two real. Six out of ten are ghosts. And the error only ever runs one direction — the further along a migration gets, the more deleted paths pile up, so the projects that worked hardest to get out of the native layer keep reporting the highest landing rates. The number drifts toward "you should own the build environment" exactly when the opposite became true.

In the same experiment I renamed one screen file, and the JS row went from six to seven. The old path and the new one count as two separate files.

One change covers both. Intersect the history's paths with what git currently tracks:

# replace the input to the while loop in native-landing.sh with these two lines
git ls-files | sort -u > /tmp/alive.txt
git log -n "$LIMIT" --name-only --pretty=format: | grep -v '^$' | sort -u \
  | comm -12 - /tmp/alive.txt

comm -12 emits only the lines present in both. Deleted paths and pre-rename paths are absent from git ls-files, so they drop out on their own. That the rename double-count disappears too was not something I predicted.

The tradeoff is that you lose the view of how much native work you did historically. What I want to know is which layer I'll be maintaining from here, so I count the surviving files — but in a month where the migration progress itself is the question, I run both and read them side by side. The gap between them is how much you've put down.

How I Actually Split It

Working from all of that, I divide by feature rather than by tool.

New work starts on the Rork side and gets pulled in-house once the checks above show native concerns accumulating. Since adopting that order, the deliberation has essentially disappeared.

The reverse direction — moving something in-house back onto the generated side — I have never once done. A shipped app is a pile of accumulated decisions, and that pile does not travel. Moving it would not be moving it; it would be rebuilding it.

What Surprised Me

I started out assuming more freedom simply meant a superset. If owning the build environment lets you do anything, then handing it off must be a convenience for beginners.

Counting taught me otherwise: the cost of owning it accrues on the days you do not use it. SDKs update on their own schedule, certificates expire on their own schedule, and build-tool combinations break on their own schedule. A project that opens ios/ three times a year still pays maintenance every month.

For a low-landing-rate project, that maintenance is waste. For a high-landing-rate project, it is proportionate to the actual work. That framing never surfaces while you are arguing about "freedom."

One more thing, about where generation speed lands. It is fast at writing screen code — a layer that was not costing me much time to begin with. What costs time is isolating why a build fails and decoding why review sent something back. Neither tool shortens that layer. What tool choice changes is only whether you can reach it at all.

Where to Start

Run native-landing.sh against your own project. It takes a couple of minutes, and the number will probably differ from what you expect. Put the comm -12 lines in before you do — without them, the landing rate reads high by however much of the migration you've already finished.

That gap is the most reliable material you have for deciding whether to change tools. In my case it worked backwards into the arrangement I use now: new work on the generated side, maintenance in-house.

For where Companion stops and a paid Apple Developer account begins, I wrote that up separately in Rork Companion's free device testing ceiling and when the Apple Developer account becomes necessary. For the mechanics of moving native settings into plugins, managing native settings with Expo config plugins covers the steps.

Your split will reasonably differ from mine, and there is no need to adopt this one wholesale. The counting procedure, though, works the same way in anyone's repository. Thanks for reading.