iliv.fit → PWA Migration — Implementation Spec

Repo A — FitProTracker (backend) BACKEND

Branch off latest origin/main (production). No business-logic changes — config + email templates + retiring one project.

A1 · Config flip Client.Web.Api/Web.Api/appsettings.json + per-env App Service / Key Vault

One value drives every client callback URL (register + reset-password, via AuthController) and the waiver URL (via WaiverService). No code touches it — only config. Current file uses local dev values:

// CURRENT (appsettings.json, dev defaults)
"ClientAppDomain": "localhost:4200",
"CorsAppDomain": "http://localhost:4200, https://localhost:4200, http://localhost:8100, ...",

// PROD today (App Service config): ClientAppDomain = app.myfitprotracker.com ; CorsAppDomain includes https://*.iliv.fit

// UPDATED — set per environment (App Service / Key Vault holds the real prod values)
"ClientAppDomain": "mobile.fitprotracker.com",
"CorsAppDomain": "https://*.fitprotracker.com,https://*.myfitprotracker.com"
//                 ^ add mobile.* (under *.fitprotracker.com); drop https://*.iliv.fit after cutover

A2 · Email cleanup Fpt.Models/Models/Email/* + config

// THE ONE REAL FIX — IlivFitUserEmail.cs (email-changed notice; reuse the existing Cloudinary logo)
src="https://iliv.fit/assets/images/logo/ilivfit_logo.png"                                   // line 199
src="https://res.cloudinary.com/fitpromaster/image/upload/v1665700762/Emails/FPTlogo.png"
You have recetly updated your email address on your iliv.fit account                        // line 293
You have recently updated the email address on your account
Thank you for using iliv.fit                                                              // line 297
Thank you.

// HYGIENE (stale seeds, not shipping) — same repoint/reword in IlivFitWelcomeEmailBody.cs + IlivFitResetPwd.cs

A3 · Retire the portal Client.Web.Client (project)

The Angular client portal served at iliv.fit. After cutover + the token grace window (A-step in §E), remove the project / its pipeline and deploy. No consumer remains once the PWA + redirect are live.

Repo B — FitProTracker.Mobile / FPT.Client (client app) MOBILE

Branch off main. This holds the real code. All of B ships in the one store release the migration needs (item B5 forces it) — so B7's dormant hook rides along for free.

What it's for: when a member taps the confirmation link, they land straight on "set your password" — no typing a code by hand.

B1 · Register page reads code + sta from the link src/app/pages/auth/register/register.page.ts

Today the page only does manual code entry (validateCode() → getContactRegisterUrl → /set-password with router state). Add a query-param short-circuit so the emailed/universal link lands straight on set-password. Inject ActivatedRoute (not currently injected).

// constructor — add ActivatedRoute
constructor(public authService: AuthService, private formBuilder: UntypedFormBuilder, private router: Router,
  public alertController: AlertController, private translateService: TranslateService, private route: ActivatedRoute) {
  addIcons({ keyOutline });
}

ngOnInit() {
  this.logo = "/assets/image/brand/logo.svg";
  this.art  = "/assets/image/brand/bg_art.png";

  // deep link / PWA URL: /register?code=..&sta=..  → skip manual entry
  const qp = this.route.snapshot.queryParamMap;
  const code = qp.get('code'), userId = qp.get('sta');
  if (code && userId) {
    this.router.navigate(['/set-password'], { state: { code, userId } });
    return;
  }

  this.registerForm = this.formBuilder.group({ code: ['', Validators.required] });  // manual entry stays as fallback
}

No change to set-password.page.ts — it already reads code/userId from router state and calls authService.doRegister({Code,UserId,Password}).

What it's for: when a link launches the app, this makes it open the right screen and keep the ?code&sta intact instead of dropping it.

B2 · Fix the deep-link listener src/app/app.component.ts

The listener splits the URL on '.com'. That happens to work for mobile.fitprotracker.com, but it's brittle and drops the fragment/edge cases. Parse it properly so path + query always survive:

// lines 76-83
App.addListener('appUrlOpen', (event: URLOpenListenerEvent) => {
  this.zone.run(() => {
    const slug = event.url.split('.com').pop();
    if (slug) {
      this.router.navigateByUrl(slug);
    }
    const url = new URL(event.url);
    this.router.navigateByUrl(url.pathname + url.search); // e.g. /register?code=..&sta=..
  });
});

What it's for: the short invite link (e.g. from an SMS with just a contact code) — expands it to the full registration link so short codes still work.

B3 · Port the /r/:code invite redirect src/app/app.routes.ts + new page

The short invite link. Mirror the web's RedirectToRegisterComponent: resolve the full URL from the backend and forward. Add the route (follow the existing loadComponent pattern) and a tiny standalone page.

// app.routes.ts — add (param-route pattern already used by account/reset-password/:id)
{ path: 'r/:code', loadComponent: () => import('./pages/auth/redirect-to-register/redirect-to-register.page')
    .then((m) => m.RedirectToRegisterPage) },

// new: src/app/pages/auth/redirect-to-register/redirect-to-register.page.ts
export class RedirectToRegisterPage implements OnInit {
  showSpinner = true;
  constructor(private route: ActivatedRoute, private router: Router, private authService: AuthService) {}
  ngOnInit() {
    const code = this.route.snapshot.paramMap.get('code');          // contactId
    this.authService.getContactRegisterUrl(code).then(
      res => {
        const u = new URL(res.callBackUrl);                          // .../register?code=..&sta=..
        this.router.navigateByUrl(u.pathname + u.search);           // stay in-app (not window.location)
      },
      () => { this.showSpinner = false; }                            // error → offer "go to login"
    );
  }
}

What it's for: confirms password reset still works after sunset. It does — the app already has its own self-contained reset, so nothing needs building.

B4 · Reset-password — NO ACTION (verified) app uses its own mobile reset flow

Retiring iliv.fit doesn't touch the app flow — it stops triggering the web link flow (nothing calls the web endpoints once the portal is gone). App and PWA users keep resetting via the 4-digit code exactly as today.

Only leftover = dead code. The web forgotPassword/resetPassword endpoints + the link-style ResetPassword email template become orphaned — remove them when deleting Client.Web.Client (A3). 2-min check: confirm nothing besides iliv.fit calls /api/auth/forgotPassword.

What it's for: the piece that makes a tapped link open the branded native app instead of a browser. This is the only part that requires a store release.

B5 · Native universal / app links ios entitlements · AndroidManifest · /.well-known · × brands

So the native apps (all brands) open the shared link. All point at the same domain, so the entitlement/manifest are identical across brands; only the association files enumerate every app.

iOS — ios/App/App/App.entitlements (currently only aps-environment):

<dict>
  <key>aps-environment</key>
  <string>development</string>
  <key>com.apple.developer.associated-domains</key>
  <array><string>applinks:mobile.fitprotracker.com</string></array>
</dict>

Android — android/app/src/main/AndroidManifest.xml, add a verified VIEW filter to MainActivity (keep the existing LAUNCHER filter):

<activity android:name=".MainActivity" android:launchMode="singleTask" android:exported="true" ...>
  <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter>
  <intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="mobile.fitprotracker.com" />
  </intent-filter>
</activity>

Association files served from mobile.fitprotracker.com/.well-known/ — list all brand apps (bundle IDs verified from clients/*/):

// /.well-known/apple-app-site-association   (no extension, application/json)
{ "applinks": { "apps": [], "details": [
  { "appID": "<TEAM_ID>.com.fitprotracker.client",              "paths": ["/register","/set-password","/reset-password","/r/*"] },
  { "appID": "<TEAM_ID>.com.fitprotracker.client.fbbc",         "paths": ["/register","/set-password","/reset-password","/r/*"] },
  { "appID": "<TEAM_ID>.com.fitprotracker.everybodybootcamp",   "paths": ["/register","/set-password","/reset-password","/r/*"] },
  { "appID": "<TEAM_ID>.com.fitprotracker.fitprotrackerteam",   "paths": ["/register","/set-password","/reset-password","/r/*"] },
  { "appID": "<TEAM_ID>.com.fitprotracker.enclavetrainingclub", "paths": ["/register","/set-password","/reset-password","/r/*"] },
  { "appID": "<TEAM_ID>.com.fitprotracker.ladiesboutique",      "paths": ["/register","/set-password","/reset-password","/r/*"] },
  { "appID": "<TEAM_ID>.com.fitprotracker.upliftrevival",       "paths": ["/register","/set-password","/reset-password","/r/*"] }
]}}

// /.well-known/assetlinks.json  (one entry per Android package + its Play signing SHA-256)
[ { "relation": ["delegate_permission/common.handle_all_urls"],
    "target": { "namespace": "android_app", "package_name": "com.fitprotracker.client",
                "sha256_cert_fingerprints": ["<SHA256_client>"] } },
  // …fbbc(com.fitprotracker.fbbc), everybodybootcamp, fitprotrackerteam, enclavetrainingclub, ladiesboutique, upliftrevival
]

What it's for: confirms the app lets members edit the same profile info the old portal did (address, emergency contact) so nothing is lost in the move.

B6 · Profile sub-pages — verify FPT.Client profile

iliv.fit had user/address + user/emergency-contact. Confirm the PWA profile (/dashboard/tabs/profile) covers both; add if missing. Likely present — verify only.

What it's for: ships now but stays off — lets the "install the app and it already knows who I am" experience be switched on later from the server, with no extra store release.

B7 · Dormant deferred-deep-link hook DORMANT new deep-link.service.ts + bootstrap call

// new: src/app/core/services/deep-link.service.ts
async fingerprint(): Promise<string> {
  const info = await Device.getInfo();                              // @capacitor/device (already installed)
  return [info.platform, info.osVersion?.split('.')[0],
          Intl.DateTimeFormat().resolvedOptions().timeZone].join('|'); // signals stable web→native
}

async resumeFromInstall(): Promise<void> {                          // call once on first cold launch, if no session
  try {
    const fp = await this.fingerprint();
    const p: any = await this.http.post(`${environment.authUrl}/api/deeplink/match`, {},
      { headers: { 'X-Device-FP': fp } }).toPromise();
    if (p?.code && p?.sta) this.router.navigate(['/register'], { queryParams: { code: p.code, sta: p.sta } });
  } catch { /* endpoint absent or no match → normal flow (fail-safe) */ }
}

// app.component.ts initializeApp() — gated so it fires only on a genuine fresh install
if (Capacitor.isNativePlatform() && !this.authService.isAuthenticated /* + a first-run Preferences flag */) {
  await this.deepLink.resumeFromInstall();
}

Repo C — FitProTracker.Front-Office (staff SPA) FRONT-OFFICE

Branch off dev. Trivial: 4 hardcoded iliv.fit links in 2 staff onboarding help files. Same content in the modern lib and its AngularJS-era duplicate.

// libs/dashboard/.../migration-check-list/steps-migration/step.sessions.html   (lines 22, 39)
// libs/legacy/src/app/billing/migration/onboarding/steps/step.sessions.html    (lines 14, 31)
…via our <a href="https://iliv.fit" target="_blank">booking app</a>.
…via our <a href="https://mobile.fitprotracker.com" target="_blank">booking app</a>.

Not touched (intentionally): the isIlivFitUser flag (cosmetic field name; doesn't break) and myfitprotracker.com hits (the staff SPA's own domain config, unrelated).

D — Deferred-deep-link: deploy-later parts DEPLOY-LATER

Server + web only — never touch the app store. Ship whenever you decide to light up B7. Reuses existing Redis.

D1 · Stash + match Functions FitProTracker · public-fpt-functions/DeepLink/DeepLinkFunction.cs

[Function("StashDeepLink")]     // PWA "Get the app" calls this before the store bounce
public async Task<HttpResponseData> Stash(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "deeplink/stash")] HttpRequestData req) {
  var payload = await req.ReadFromJsonAsync<DeepLinkPayload>();       // { code, sta }
  await _redis.GetDatabase().StringSetAsync($"dl:{Fingerprint(req)}",
      JsonSerializer.Serialize(payload), TimeSpan.FromHours(1));      // short TTL, single-use
  return req.CreateResponse(HttpStatusCode.NoContent);
}

[Function("MatchDeepLink")]     // app B7 calls this on first launch
public async Task<HttpResponseData> Match(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "deeplink/match")] HttpRequestData req) {
  var db = _redis.GetDatabase(); var k = $"dl:{Fingerprint(req)}";
  var val = await db.StringGetAsync(k);
  if (!val.IsNullOrEmpty) await db.KeyDeleteAsync(k);                 // single-use
  var res = req.CreateResponse(HttpStatusCode.OK);
  await res.WriteStringAsync(val.HasValue ? val.ToString() : "{}");
  return res;
}

private static string Fingerprint(HttpRequestData req) {             // must match B7's recipe
  var ip = req.Headers.TryGetValues("X-Forwarded-For", out var f) ? f.First().Split(',')[0].Trim() : "";
  var fp = req.Headers.TryGetValues("X-Device-FP",     out var d) ? d.First() : "";
  return Convert.ToHexString(SHA256.HashData(Encoding.UTF8.GetBytes($"{ip}|{fp}")));
}
// ponytail: fingerprint is best-effort (gym Wi-Fi shares one IP); SMS numeric code is the safety net. Rate-limit these anon routes.

D2 · Web "get the app" stash trigger FPT.Client (PWA mode)

When the link opens in-browser and the user chooses to install: stash the payload, then redirect to the store. (Only needed the day you enable deferred deep linking; the PWA fallback works without it.)

const qp = this.route.snapshot.queryParamMap, fp = await this.deepLink.fingerprint();
await this.http.post(`${environment.authUrl}/api/deeplink/stash`,
  { code: qp.get('code'), sta: qp.get('sta') }, { headers: { 'X-Device-FP': fp } }).toPromise();
window.location.href = this.isIOS ? APP_STORE_URL : PLAY_STORE_URL;

E — Non-code (ops)

F — Sequencing

1. Backend (A1 config, A2 emails) → PR to Dev. Low risk, deploy first.
2. Mobile (B1–B3, B5, B6 + dormant B7) → PR to main; build all ~7 apps; submit to stores. This is the long pole (store review).
3. Front-Office (C) → PR to dev. Trivial.
4. Cutover: point the domain, flip config, set the 301. Verify a real membership purchase → link → app opens branded → confirm.
5. Grace window passes → retire iliv.fit + delete Client.Web.Client (A3).
6. Phase 2: SMS-first activation + app-first routing (section G) — reuses existing services; the app "enter code" screen rides the store release.
7. Later, optional: deploy D1/D2 to light up deferred deep linking (no store release).

G — SMS-first activation & app-first (Phase 2 design)

Locked design for the next phase; builds on Phase 0/1. Mostly wiring services that already exist.

G1 · SMS-first activation (OTP) Fpt.Standard ContactService + FPT.Client

Activation code texted from the gym's own SMS number (sender branded for free). Reuse the existing mobile code flow — ContactService.GenerateCode issues + stores the code (already used by ResetPasswordMobile).

• Backend: add POST /api/auth/mobile/activate that validates the code (reuse RecoveryInformation) and returns a JWT — mirror ResetPasswordMobile. ✅ pattern exists.
• App/PWA: new first-open "enter your code" screen — autocomplete="one-time-code" for iOS autofill + Android SMS Retriever hash in the message body. ➕ small new screen.
• Email = fallback only (deliverability backup + receipt/agreement).

G2 · App-first via the existing smart link reuse fitpro.io/a/{code}

The onboarding SMS carries fitpro.io/a/{code} (FPT.UrlShortener · AppDownload.cs) — already device-aware + per-brand (encodes contactId|locationId → resolves the gym's branded app + the right store). ✅ built, already in the Welcome email. No new store-routing code.

G3 · Drive to the native app for everyone (web = fallback) SMS content + runtime-skinned PWA

Every member's SMS leads with fitpro.io/a/{code}, which auto-routes to the right app for their gym — the branded app if the tenant bought it, else the default Fit Pro Tracker app. So there's no per-tenant SMS branching — the smart link resolves it. Include a "start in browser" option too. Do not hard-gate install — the PWA is the no-lose fallback.

The PWA fallback is runtime-themed per gym (§H3) so branded tenants stay branded on the web too — page skinned to the gym, URL shared (mobile.fitprotracker.com). Lead hard with the app; the web catches everyone who doesn't install. (A per-brand web URL is a further, separate DNS-per-tenant option if any tenant needs the address branded too.)

G4 · Shorten the waiver link + track opens FPT.UrlShortener + Digital Documents send path

Today the Digital Documents waiver SMS sends doc.fitprotracker.com/document/b/{token} (~90 chars → 2–3 SMS segments). Add a document route to the shortener (fitpro.io/d/{code} → encrypt/redirect to the doc URL; /f is the legacy forms route, so this is a NEW route on the same service) and point the document send at it.

• SMS credits: back to ~1 segment → ~50–66% cost cut on every waiver/link text.
• Tracking (bonus): shortener links are tracked (ShortLinkService) → open/click analytics per member — see who tapped the waiver / download link, resend to non-openers, measure activation drop-off. Funnel visibility we don't get from the raw doc.fitprotracker.com link.

H — Activation feasibility & the frictionless target (iOS vs Android)

Goal: from "I said yes" to "booked & cleared" in the fewest taps, on the surface they're already on. Best-in-class = remove every friction we control; the one step we can't delete is the OS's own app install for a brand-new user — so we don't require it (goal = native app; web is the no-lose fallback), and make the app a one-tap upgrade.

H1 · The frictionless path — SMS-first, zero password (web or app)

SMS code (from the gym's number) → PWA → OTP autofills → in → waiver (fitpro.io/d) → book → in-app / kiosk-QR check-in. OTP autofill works on the web and in the app:

H2 · The app as a frictionless upgrade (branded, push)

fitpro.io/a/{code} → right branded app + store → install → open → OTP autofills → in. To kill the "fresh install doesn't know me" re-identify step, add deferred deep linking (§D DIY, or Branch) — carries contactId through the install so the app opens already recognizing them. Deferred — OTP autofill covers the gap; add later only if the post-install re-tap measurably hurts. iOS match ~70–90% post-ATT; OTP autofill is the reliable fallback when the match misses.

H3 · Branded tenants stay branded on the web too DEFERRABLE

Runtime-theme the PWA (resolve org from the code/session → apply the brand's colors + logo) so branded tenants get a fully-branded web leg — no need to force an install just to look branded.

Investigated 2026-07-24 — two halves: theming today is 100% build-time (pipeline copies clients/<name>/theme/*, one bundle per brand). (a) CSS half — cheap (~1–2d): colors are already Ionic CSS custom properties (--ion-color-primary), so a runtime service can override them (setProperty) with no recompile. (b) Data half — net-new, the bulk: the API exposes no per-org brand colors/logo → add brand fields on org/location + expose on login/select-location · logo becomes a Cloudinary URL (not the hardcoded /assets/image/brand/logo.svg) · admin UI for owners · DB columns. Native identity (bundle IDs/icons/Firebase/Trapeze) stays build-time regardless. Since native apps are already branded and the goal is native, this only serves the branded-member-on-web edge case → defer until that web usage justifies the net-new data + admin work; ships PWA-first if pursued.

H4 · What we remove vs. the irreducible floor

• Removed (everything we control): passwords · the iliv.fit web detour · typing the code (autofill) · fast-expiring confirm tokens (~24h) · re-logins (biometric + persistent session) · branding leaks (gym SMS number + branded email/app + runtime-themed web) · long SMS links (shortener).
• Irreducible floor: a brand-new user must acquire the app somehow (OS install) — so we don't require it; the web fallback books them in seconds and the branded app is a one-tap upgrade after.

I — New-lead: public schedule → signup (design + complexity)

↓ new lead (no account) is redirected to ↓

Gym-branded throughout · lead-capture floor so no one dead-ends · web-first (Apple/Google Pay) then app hand-off for retention.

Best-in-class reference — Mariana Tek (mirror this)

UI patterns worth mirroring (adapted to each gym's brand):

• Location selector + filter chips in the header (Instructor · Class Type · Rooms · Clear All) — we already have the location dropdown; add lightweight filters.
• Horizontal day scroller — days with dates, "Today" emphasized, selected day underlined, ‹ › arrows (our calendar already has List/Week/Month + arrows; tighten toward this).
• Clean class row = time · duration │ instructor avatar │ class title (bold) + instructor + room │ single right-aligned CTA.
• One clear CTA per row — Mariana Tek uses RESERVE / JOIN WAITLIST. Our "Join class" maps to it: member → books; lead → opens the intro-offer sheet (the single-step buy).
• Monochrome, whitespace-heavy, uppercase buttons — but skinned per gym (their brand colors, not a generic look).

Embed on the gym's own website — feasibility demo: embed-demo.html

Competitors (Mariana Tek / Glofox) let a gym drop a widget on their own site. We can too — and we already have precedents (fpt-journey.js CDN loader + the anonymous public calendar + subdomain multi-tenancy). Live concept: embed-demo.html (a mock gym site with the widget iframed in).

Complexity — popup/modal on the public calendar T-shirt: M · ~5–8 dev-days

Assessed against the fresh main clones. Recommended approach = a custom modal on the public calendar (not the journey/funnel system — journeys can't carry class context without fighting the framework = VERY HIGH).

Top risks / unknowns: (1) ProxynizationAPI global stays reachable across modal destroy/recreate — keep the callback at page level; (2) server-side class-capacity enforcement on concurrent guest books (verify contactByClass checks capacity); (3) mobile modal UX — prefer a 3-step wizard (offer → info → pay) over one long form; (4) design the payment slot as a swappable binding so the SAQ hosted-iframe migration (FPT Pay) drops in without a rewrite.