feat(mobile): run the dev client on EAS simulators from a cloud sandbox

Merged
SA
17d ago
+378-1839

What this does

Makes EAS the way to run apps/mobile from a cloud sandbox, and removes the Limrun tooling it replaces.

  1. apps/mobile/scripts/eas-dev.sh: one command brings the dev client up on an EAS cloud simulator. It installs the finished simulator build whose fingerprint matches the checkout (building one only when none exists), forwards Metro and the API over local egress, loads the app from Metro, and tags the session with the workspace id so the desktop Mobile pane (#8351) can find it.
  2. EAS resolves the runtime version this repository does. A build submitted from a development checkout failed at "Configure expo-updates". Three causes, all fixed:
    • bun version. The fingerprint includes bun's store paths. EAS installed with its default 1.3.14; the repository pins 1.4.2. eas.json pins bun on every build profile, and the EAS workflows pin it through defaults.tools.bun.
    • The dev .env. app.config.ts loaded the repository-root .env, which EAS does not have. Every build profile sets MOBILE_EAS_BUILD, and app.config.ts skips the .env when it is set.
    • A sandbox's shell. A sandbox already has the dev values exported, so eas-dev.sh removes EXPO_PUBLIC_* from the build and fingerprint commands.
  3. Native Sentry starts only when a DSN is set. The EAS development environment has none, and native init without one crashed every development build at launch (SIGSEGV in SentrySDKInternal startWithOptions).
  4. Limrun is removed: limrun-dev.sh, the four Limrun skills and mobile-limrun-dev, and the lim CLI from the Superset environment's setup. mobile-eas-dev and the notes in apps/mobile/AGENTS.md describe the EAS flow. The environment installs agent-device.

apps/mobile/eas-runtime-version.test.ts fails when a build profile or workflow differs from .bun-version, or a profile lacks the marker.

Verification

  • On a cloud sandbox, from this branch: eas-dev.sh built a simulator build that passed the runtime version check (build f0491d3f), then on a second run took 128 s to the sign-in screen with the app loaded from the sandbox's Metro. The dev sign-in reached Home against the sandbox's API. The egress log shows the simulator reaching ports 8081, 3001 and 3013.
  • Before the Sentry fix: the app crashed at launch on the simulator; the crash report names SentrySDKInternal startWithOptions.
  • bun pin: two throwaway EAS workflows on the same code returned fingerprint 37d39e6e… without the pin and 5825d3b7… with it, the same two values as local installs with bun 1.3.14 and 1.4.2.
  • .env fix: a build from a Mac checkout with a dev .env passed the check (build ad4fa529); without it the check failed on ios.associatedDomains and the Sentry dsn.

Before merge

  • This changes the runtime version. On merge, deploy.yml finds no build for the new fingerprint, builds preview and production, and uploads production to App Store Connect. Updates published after that reach only the new builds.
  • Gone with Limrun, not replaced: building on remote Xcode from a sandbox (an EAS build takes its place), Maestro flows against a remote simulator from a sandbox, and signed device builds through lim.
  • Not covered: eas update and eas fingerprint:generate run by hand from a development checkout still read the dev values. The workflows are not affected.
  • LIM_API_KEY is still set on the Superset environment and can be deleted there.

Summary by CodeRabbit

  • New Features
    • Mobile development can now start or reuse an EAS iOS simulator session connected to local app services. A simulator build is created when no matching build is available.
    • A development-simulator build profile is available for iOS simulator testing.
  • Improvements
    • Mobile build workflows now use Bun 1.4.2 consistently.
    • Native Sentry initialization now requires a mobile Sentry DSN, and EAS builds skip loading the local root .env file.
  • Documentation
    • Mobile simulator development guidance now covers the EAS workflow.