← mobile

Workout Window — Phase 0: the TestFlight demo (concrete build steps)

Goal: a Workout Window–branded native build John installs on his own phone in the meeting. Native, real, his icon — before any store review. This is config + assets over the existing apps/mobile codebase; no backend change, no new features. Strategy: ../product/WORKOUT_WINDOW_APP.md.

Phase 0 proves it's real. The APP_FLAVOR refactor (Phase 1) makes it reproducible. For the demo you can take the fast path (a branded build off a branch) and do the clean flavor system right after.

Prerequisites (accounts + assets)

  • Apple: an Apple Developer account + an Ad Hoc / TestFlight distribution path (EAS handles signing). Internal TestFlight needs the app registered in App Store Connect but no review for internal testers.
  • Google: Play Console + an internal testing track (also no review; installs via an opt-in link).
  • Assets — first pass DONE (Direction A "Sunrise Window", approved 2026-07-15): icon / adaptive-icon / splash PNGs + SVG masters live in apps/mobile/assets/workout-window/ (see that folder's README). Remaining polish before store launch (not needed for the demo): a real wordmark typeface.
  • Domain: workoutwindow.com (owned) — used for deep links + the eventual privacy/support URLs.

Fast path (branded build, ~half a day once assets exist)

  1. Branch wo-window-phase0 off apps/mobile.
  2. Identity in app.json (expo):
    • name: Workout Window
    • slug: workout-window (note: a new slug = a distinct EAS project; either create it under the jurowski owner or keep the slug and just change the display name for the very first demo — display name is what shows on the home screen)
    • ios.bundleIdentifier: com.workoutwindow.app
    • android.package: com.workoutwindow.app
    • scheme: workoutwindow
    • ios.associatedDomains + android.intentFilters host → workoutwindow.com (deep links; fine to leave hivejournal for the very first internal build).
  3. Assets — already built. Point the config at the Workout Window files in apps/mobile/assets/workout-window/ (icon / adaptive-icon / splash), and set splash.backgroundColor + android.adaptiveIcon.backgroundColor to #0d121a. Exact config snippet in that folder's README.
  4. Fitness-first home (minimum for the demo): default the app to the Workout Window Dashboard screen instead of the journal Dashboard — it already exists (screens/workout-window/WorkoutWindowDashboardScreen.tsx), so this is a landing route change, not new UI. Optional: hide the story/graphene tabs for the demo.
  5. Env: point EXPO_PUBLIC_API_URL / Supabase vars at production (same backend the web app uses) so John's demo shows real data.
  6. Build + distribute: 
    cd apps/mobile
eas build --platform ios --profile preview      # internal/simulator or device
eas build --platform android --profile preview
# then: eas submit (TestFlight internal) / upload AAB to Play internal testing
    For the in-meeting install, a TestFlight internal link (iOS) + Play internal testing opt-in link (Android) is the smoothest — John taps the link, installs the real app.

The flavor system — ALREADY BUILT ✅ (2026-07-15)

The clean path is landed, so you don't need the hand-hacked branch:

  • apps/mobile/app.config.js reads process.env.APP_FLAVOR. Base config stays in app.json (HiveJournal, untouched); APP_FLAVOR=workoutwindow overrides name / slug / com.workoutwindow.app bundle id
    • package / scheme / icon / splash / adaptive-icon / workoutwindow.com deep links, and exposes extra.appFlavor for runtime. Verified: the HiveJournal build is byte-for-byte unchanged when the flavor is unset.
  • apps/mobile/eas.json adds preview-workoutwindow and production-workoutwindow profiles (they extends the base profiles and set APP_FLAVOR).

Build John's app:

cd apps/mobile
APP_FLAVOR=workoutwindow npx expo start          # local dev (Expo Go / dev client)
eas build -p ios     --profile preview-workoutwindow
eas build -p android --profile preview-workoutwindow

The runtime gate — DONE ✅ (2026-07-15). src/lib/flavor.ts reads Constants.expoConfig.extra.appFlavor and exports isWorkoutWindow + BRAND_ACCENT. src/navigation/MainNavigator.tsx uses it so the Workout Window build: opens the first tab straight on the Workout Window dashboard (initialRouteName), relabels that tab Workout 🌅, hides the Graphene (story/audiobook) tab, and tints the tab bar coral. The full journaling stack stays reachable behind the WW dashboard (keeps the app's depth). HiveJournal flavor is unchanged. So a preview-workoutwindow build now opens as the coaching app — Phase-0 is code-complete; only the account/asset logistics remain.

Before store submission: create a dedicated EAS project for Workout Window (eas init) and set its own projectId — the shared one is fine for the first internal build but EAS warns on the slug mismatch.

Gotchas

  • New slug/bundleIdentifier = a new EAS project + a new App Store Connect / Play app. Fine — that's what a separate app is — just don't expect the HiveJournal project's build history/credentials to carry over.
  • ITSAppUsesNonExemptEncryption: false is already set — keep it (avoids the export-compliance prompt on every TestFlight upload).
  • Apple rejects thin wrappers, but this isn't one — it's a full native app; the journaling depth is a feature, not a liability. Keep enough of it visible.
  • Don't ship the fast-path branded build to the public stores — it reuses the HiveJournal EAS project loosely. Public submission goes through the Phase-1 flavor system so identity/signing are clean.

Definition of done (Phase 0)

John taps a link in the meeting, installs Workout Window (his icon, his name), opens it to the Workout Window dashboard, and sees real accountability data — a native app in his hand, running on the code we already built.

WORKOUT WINDOW PHASE0 TESTFLIGHT — Docs | HiveJournal