Chromeria iOS app ships to TestFlight #205

What: The Chromeria iOS app, built from our main, reaches the user's iPhone through TestFlight, and each new upload arrives over the air.
Why: The user's servers run Chromeria main (orchestration protocol 2); the App Store T3 Code 1.4.1 speaks protocol 1 and shows "Client not supported".
So what: An agent adds a fork-owned Chromeria build identity for apps/mobile, builds and uploads on rocky, and opens a PR; the user installs TestFlight and accepts the invite.

Contribution to the Objective

Supporting work: it lets the user drive Chromeria servers, where the Promachos, Wight mode, Drafters and Spectrum run, from the phone. It adds no new Objective item.

Outcome

• apps/mobile can be built as Chromeria: name Chromeria, bundle md.toolbox.chromeria.mobile, Apple team MCBD97AVW6, the existing Chromeria icon, OTA updates off (no upstream EAS project, channel or update URL), build number from the environment.
• A build of main is uploaded to App Store Connect app 6821081912, processed, export compliance answered, and available to the internal TestFlight group "Chromeria" with the account holder as tester.

Acceptance criteria

• With the Chromeria switch set, expo config resolves the identity above, including md.toolbox.chromeria.mobile.widgets, .sharing and group.md.toolbox.chromeria.mobile, updates.enabled: false, and no extra.eas.projectId, owner or updates URL.
• Without the switch, the resolved config is unchanged.
• bash scripts/fork-check.sh --base 12069eefd707f78eafc27812027c994eea0613cf passes; new and edited files are registered in docs/fork-features.md and scripts/fork-upstream-edits.txt.
• App Store Connect shows the build VALID, usesNonExemptEncryption=false, in internal group "Chromeria" with the account holder as tester.
• Reusable build and upload steps, and the certificates, profiles and rocky build clone created, are recorded in ~/dev/runbook.

Non-goals

• App Store release or external TestFlight testing.
• Android builds.
• T3 Connect (Clerk) sign-in for the fork; direct pairing over the LAN or Tailscale does not need it. The Clerk risk is checked and reported only.
• Push notifications through upstream's infrastructure.
• CI automation of iOS builds, or a Chromeria OTA channel.

Blockers

None known. Risk: non-interactive Apple signing over SSH on rocky (distribution certificate, profiles for the app and its widget and share extensions, App Group registration).

Proof

• expo config --type public output with and without the switch.
• fork-check.sh output.
• App Store Connect API read-back of the build processing state, encryption answer, beta group and tester.

Elon record

Requirements and who asked: The user asked for the Chromeria iOS app on their iPhone through TestFlight with over-the-air builds, named Chromeria, bundle md.toolbox.chromeria.mobile, team MCBD97AVW6; the brief requires that our app never pulls upstream's EAS OTA bundles; App Store Connect requires a higher CFBundleVersion per upload.
Deleted: EAS Build and Submit and an Expo account (local Xcode on rocky builds and uploads); a Chromeria OTA channel (TestFlight delivers new builds); new icon artwork (reuse assets/chromeria/chromeria-icon-1024.png); Android; Clerk setup; a new URL scheme (widget deep links and linking prefixes hardcode t3code://).
Bottleneck: Apple signing on rocky: an Apple Distribution certificate, App Store profiles for three targets and App Group registration, all non-interactive over SSH.
Checked myself: apps/mobile/app.config.ts hardcodes upstream team ARK85ZXQ4Z, EAS project d763fcb8-… and its update URL; rocky has Xcode 27 with the iOS 27 SDK, CocoaPods 1.17 and no code-signing identity; the fork checkout has no Clerk or relay env, so cloud sign-in stays hidden in fork builds; upstream pingdotgg/t3code has only the personal-team identity hook (#3643, #4943), no fork identity hook.