Workout Window — John's own iOS + Android app (plan)

Status: PROPOSED — meeting-prep doc for John Rowley (2026-07). Nothing built toward this flavor yet. The point of this doc: John will be far more impressed by a real app he can download from the App Store / Play Store with his brand on it than by another web page — and we can give him that without building a new app, because the mobile codebase already exists and already contains the Workout Window screens.

Related: COACHING_BRAND_MAP.md (Workout Window = the fitness skin, name locked 2026-07-13, John = channel owner) · DREAMPRO_COACHING_SYSTEM.md (the engine + channel override) · WORKOUT_WINDOW_WALL_BREAKER.md (the nudge loop) · ../mobile/MOBILE_WEB_GAP.md.

The headline for the meeting

We can put a Workout Window app — John Rowley's brand, his icon, his name — on the App Store and Google Play, running on the code we've already built. It's the same engine that powers the platform, wearing his skin. He gets a native app to hand to every client and show at every talk; we get a branded front door that funnels into his coaching channel (he earns the override on every subscriber).

The demo we can put in his hand first: a TestFlight build of the current mobile app, rebranded to Workout Window, that he installs on his own phone in the meeting. Native, real, his — before we've written a store listing.

Why this is cheap (the code already exists)

apps/mobile is a shipping React Native / Expo app (com.hivejournal.app, EAS project, owner jurowski). It already has the entire Workout Window surface wired: setup, check-in, dashboard, chain, mosaic, battle (apps/mobile/src/navigation/MainNavigator.tsx). It talks to the same production backend the web app does. So "John's app" is not a new app — it's a branded flavor of the one we have, with a fitness-first navigation that foregrounds Workout Window and tucks the general journaling surfaces behind it.

Architecture — one codebase, two flavors (recommended)

Add an APP_FLAVOR switch (hivejournal | workoutwindow) resolved at build time via app.config.js. The flavor drives four things and nothing else forks:

Same repo, same API, same maintenance. Two eas.json build profiles, two store listings. A journaling feature we ship shows up in both; a fitness-only screen is gated behind flavor === 'workoutwindow'.

Rejected: a separate fork of the codebase (doubles every future change).

What the app IS to John (business, not just tech)

• His branded front door: every client downloads Workout Window, not "HiveJournal." Credibility at talks, in his book, on his channel.
• A funnel into his coaching channel: signups tagged brand=workoutwindow attribute to John; he earns the channel override on every subscriber (the engine's Stripe Connect split — DREAMPRO_COACHING_SYSTEM.md).
• The accountability loop already built — check-ins, chains, battles, the Wave, and the circle-nudge → coin loop — now in his clients' pockets with push nudges.

Phases

• Phase 0 — "hold it in your hand" demo (do before/at the meeting). Rebrand the current build (name, icon, splash, color, com.workoutwindow.app), fitness-first home, ship to TestFlight + Play internal testing. John installs it in the meeting. No store review needed for internal builds. This is the whole "impress John" play and it's mostly config + assets.
• Phase 1 — the flavor system. Land APP_FLAVOR + app.config.js variants + the two EAS profiles + the fitness-first nav gating, so both apps build from one codebase reproducibly (not a hand-hacked one-off).
• Phase 2 — store submission. The real long pole is logistics, not code (see below). App icons/screenshots, hosted privacy policy + support URL on a Workout Window domain, store listings, review.
• Phase 3 — monetize + engage in-app. In-app coaching subscribe (mind the Apple IAP rule below), push nudges (the roll-in marble / the Wave), own-voice encouragement, and voice-first check-ins (see the voice-entry scope — ../mobile/VOICE_ENTRY_MOBILE.md; talking about how a workout felt is a perfect fitness-app interaction).

The real long pole is App Store logistics (decide these WITH John)

1. Whose developer accounts? Apple Developer ($99/yr) + Google Play ($25 once). Options: (a) our accounts, John's brand — fastest, we control builds, transfer later; (b) John's own accounts — max credibility ("by John Rowley"), he owns the listing, but he must create + verify them (D-U-N-S for org accounts can take days). Recommend (a) now, path to (b) via Apple's app-transfer.
2. Workout Window domain — RESOLVED: we own workoutwindow.com (confirmed 2026-07-15). Store listings need a privacy policy URL + support URL on a real domain; workoutwindow.com is it. This unblocks submission and also gives John's brand a real front door (the app's App Store/Play links, the associated-domains deep-link entry, and the signup funnel all point here instead of dreampro.io). Remaining work: stand up workoutwindow.com/privacy + /support before Phase 2.
3. v1 scope. Workout-Window-only, or "fitness journal + Workout Window"? Recommend fitness-first but keep journaling — Apple rejects thin single-purpose wrappers; the journaling depth is what makes it a real app, not a web shortcut.
4. In-app payments (the Apple 30% trap). Apple requires IAP for digital subscriptions (30% cut). AI-coaching content likely counts; in-person human coaching services can bill outside IAP. This shapes how the coaching subscription is sold inside the app — flag it early, it affects John's economics. (Web signup sidesteps IAP; the app can drive to web for the subscribe step where allowed.)

What we reuse vs. build

• Reuse (already shipped): the entire mobile app, all Workout Window screens, the backend API, the coaching engine + channel override, the circle-nudge loop, the Wave. No backend changes for Phase 0–2.
• Build: the APP_FLAVOR flavor system + fitness-first nav gating; Workout Window brand assets (icon, splash, wordmark, palette); the two EAS profiles; store listings
  • hosted legal pages; (Phase 3) push nudges, in-app subscribe, voice check-ins.

Recommendation

Ship the Phase 0 TestFlight demo first — it's config + assets over code that already exists, and a real app in John's hand is worth more than any deck. The domain decision is already resolved (workoutwindow.com), so the meeting only needs to lock three: accounts, v1 scope, IAP. Then land the flavor system so both apps build cleanly from one codebase.

Concrete Phase-0 steps: ../mobile/WORKOUT_WINDOW_PHASE0_TESTFLIGHT.md.