fix(ci): unbreak mobile preview CD against eas-cli 22

continuous-deploy-fingerprint failed with "Cannot read properties of
undefined (reading 'ownerAccount')" after its builds had already
succeeded. eas-cli 22 renamed the build JSON fields (project -> app,
channel -> updateChannel, runtimeVersion -> runtime) and the action still
reads build.project.ownerAccount when posting its PR comment, so the
workflow installed the breakage by asking for `latest`.

Pins eas-cli to 21.8.0 for this workflow only; the production workflow
calls eas directly and stays current. Also pins the action itself to v9:
it was the one action reference in the repository tracking an unreleased
branch, so CI could change without a commit here.

Documents the mobile build path in the app README. EAS build servers read
the EAS-hosted environment, never this checkout, so a gitignored
.env.local reaches nothing. Missing PYLON_EAS_PROJECT_ID silently ships a
binary with over-the-air updates disabled, which cost a full rebuild
cycle to discover; missing Clerk values silently omit every Connect
surface. Both are now named alongside a command to verify a finished
artifact rather than assume.

Upstream issue: expo/expo-github-action#358

Author: rynfar

.github/workflows/mobile-eas-preview.yml

@@ -66,7 +66,15 @@ jobs:
         if: steps.expo-token.outputs.present == 'true'
         uses: expo/expo-github-action@v8
         with:
-          eas-version: latest
+          # Pinned below eas-cli 22 for continuous-deploy-fingerprint, which still
+          # reads `build.project.ownerAccount` when it posts the PR comment. eas-cli
+          # 22 renamed those build JSON fields (project → app, channel →
+          # updateChannel, runtimeVersion → runtime), so `project` is undefined and
+          # the step fails after the builds have already succeeded.
+          # See https://github.com/expo/expo-github-action/issues/358 — raise this
+          # back to `latest` once that issue closes. The production workflow stays
+          # on `latest` because it calls eas directly and never runs this action.
+          eas-version: 21.8.0
           token: ${{ secrets.EXPO_TOKEN }}
           # npm, not pnpm: this only installs eas-cli into the action's own
           # tool dir, and pnpm 11 hard-fails that install on dtrace-provider's
@@ -82,7 +90,11 @@ jobs:
 
       - name: Deploy with fingerprint check
         if: steps.expo-token.outputs.present == 'true'
-        uses: expo/expo-github-action/continuous-deploy-fingerprint@main
+        # Pinned to a release rather than @main: this is the only action reference
+        # in the repository that tracked an unreleased branch, so it could change
+        # under CI without a commit here. The sub-action does not exist in v8, which
+        # is why the setup action above is a different major.
+        uses: expo/expo-github-action/continuous-deploy-fingerprint@v9
         env:
           EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
         with:

apps/mobile/README.md

@@ -91,9 +91,70 @@ The native lint task runs SwiftLint for Swift plus ktlint and detekt for Kotlin.
 
 CI uses Expo fingerprinting with the `preview:dev` profile to reuse an existing compatible build when possible, or start a new internal EAS build when native runtime inputs change. Production and default local builds continue to use the `appVersion` runtime policy.
 
-For preview or production EAS environments, set `T3CODE_CLERK_PUBLISHABLE_KEY`,
-`T3CODE_CLERK_JWT_TEMPLATE`, and `T3CODE_RELAY_URL`
-as EAS environment variables. Expo config maps the canonical values into the mobile build.
+### EAS environment variables
+
+EAS build servers read the EAS-hosted environment, **not this checkout**. `eas build`
+archives the project with git, so every gitignored file — including the repository-root
+`.env` and `.env.local` — is absent on the builder. Anything `app.config.ts` needs must
+therefore exist in the EAS environment for `production`, `preview`, and `development`:
+
+| Variable                       | Missing it means                                                 |
+| ------------------------------ | ---------------------------------------------------------------- |
+| `PYLON_EAS_PROJECT_ID`         | `extra.eas.projectId` is null and **`updates.enabled` is false** |
+| `PYLON_EAS_OWNER`              | no `owner` in the manifest                                       |
+| `T3CODE_CLERK_PUBLISHABLE_KEY` | Pylon Connect UI is omitted entirely                             |
+| `T3CODE_CLERK_JWT_TEMPLATE`    | Pylon Connect UI is omitted entirely                             |
+| `T3CODE_RELAY_URL`             | Pylon Connect UI is omitted entirely                             |
+
+List or set them with:
+
+```bash
+eas env:list preview
+eas env:create --name PYLON_EAS_PROJECT_ID --value <id> \
+  --environment production --environment preview --environment development \
+  --visibility plaintext --type string --scope project --force
+```
+
+All of these are public identifiers — the project ID ships inside every app's update
+URL — so they are plaintext variables, not secrets.
+
+**Both failures are silent.** A build missing the Clerk or relay values renders no error
+and no empty state; `hasCloudPublicConfig()` simply omits every Connect surface, so the
+app reads as though it never had the feature. A build missing `PYLON_EAS_PROJECT_ID`
+installs and runs normally but can never receive an over-the-air update, because Expo
+disabled the update client at build time. In CI the project ID fails louder: every `eas`
+command reports "EAS project not configured".
+
+Verify a finished build rather than assuming, by reading the manifest baked into the
+artifact:
+
+```bash
+unzip -qo <build>.ipa -d /tmp/ipa
+node -e 'const c=require("/tmp/ipa/Payload/PylonPreview.app/EXConstants.bundle/app.config");
+  console.log("updates:", JSON.stringify(c.updates), "| projectId:", c.extra?.eas?.projectId);
+  console.log("connect:", Boolean(c.extra?.clerk?.publishableKey && c.extra?.relay?.url))'
+```
+
+### Installing a build on a device
+
+Internal-distribution builds install straight from the build page in **Safari** on the
+device — no Expo Go or Orbit needed — provided the device UDID is on the provisioning
+profile. Open the URL that `eas build` prints, or scan its QR code.
+
+### Over-the-air updates
+
+An update only reaches a binary whose `runtimeVersion` matches, so publish with the same
+policy the target build used. The `preview:local` profile pins `appVersion`, so:
+
+```bash
+APP_VARIANT=preview MOBILE_VERSION_POLICY=appVersion \
+  eas update --branch preview --environment preview --platform ios --message "..."
+```
+
+Publishing under the default `fingerprint` policy instead produces a runtime version no
+`appVersion` build will ever match, and the update silently never lands. `eas
+update:roll-back-to-embedded` reverts a channel to the bundle inside the binary, which is
+also the quickest way to test whether a published bundle caused a regression.
 
 Create a PR preview dev-client build manually: