App update prompt

JS changes reach installed apps over the air. Native changes need a new binary from the App Store or Google Play. The update prompt tells a trainee on an older binary that a newer one is in the store. It is a soft prompt. The trainee can close it and keep using the app. The code is src/features/app-update.

File	Role
`data/appReleaseApi.ts`	`getAppRelease()`
`lib/updateDue.ts`	`dueUpdateOf()`
`store/appUpdatePrompt.ts`	The Zustand store and the three actions
`components/AppUpdatePrompt.tsx`	Mounted in `(app)/_layout.tsx`. Renders the dialog when an update is due
`components/AppUpdateDialog.tsx`	The modal

Endpoint

GET /v1/trainee/app-release returns:

export type AppRelease = { latestVersion: string | null; storeUrl: string | null };

The client sends X-App-Platform on every request, so the server can answer per platform. The latest version is server configuration. Releasing a new binary does not require an app change to announce it.

Is an update due?

export function dueUpdateOf(
  release: Partial<AppRelease> | null | undefined,
  installedVersion: string | undefined,
): DueUpdate | null {
  const version = release?.latestVersion;
  const storeUrl = release?.storeUrl;
  if (!version || !storeUrl || !installedVersion) {
    return null;
  }
  return isVersionAtLeast(installedVersion, version) ? null : { version, storeUrl };
}

installedVersion is Constants.expoConfig.version.
isVersionAtLeast from features/health/lib/runtime.ts compares dot-separated numeric parts. Missing parts count as 0, so 1.0 equals 1.0.0. Non-numeric parts count as 0.
If the server sends no version or no store URL, nothing is due. That is how the prompt is switched off.

When it shows

promptForAppUpdate() is the last of the three startup prompts, after push permission and health access. runStartupPrompts in src/lib/startupPrompts.ts runs them in sequence, so the dialog never appears on top of a system permission sheet. It runs once each time the trainee becomes signed in, which in practice means each cold start. The function returns without showing anything when:

Condition	Reason
`IS_PREVIEW` is true	The coach preview is not an installed app
Platform is not iOS or Android	No store
The dismissal file holds today’s date	Already closed today
`dueUpdateOf` returns null	Up to date, or the server has no release configured
A workout session is started	Never interrupt a workout

A failed request rejects the promise. runStartupPrompts catches errors from each prompt and moves on, so an offline launch shows no dialog and no error.

The dialog and the queue

When an update is due, the function sets it in the store and returns a promise that stays pending until the trainee acts:

await new Promise<void>((resolve) => {
  release = resolve;
  useAppUpdatePrompt.setState({ update });
});

Holding the promise keeps the startup queue open, so useStartupPrompts only reports settled once the dialog is gone. Because it is the last prompt, nothing else is waiting behind it. AppUpdatePrompt subscribes to update !== null and renders AppUpdateDialog, a transparent fade Modal with a title, a body and one filled button.

Action	Function	Effect
Tap the update button	`openAppUpdate()`	Clears the store, resolves the promise, opens `storeUrl` with `Linking.openURL`
Tap the close icon, the backdrop, or the Android back button	`dismissAppUpdate()`	Writes today’s date to the dismissal file, clears the store, resolves the promise

Tapping update does not record a dismissal. If the trainee opens the store and comes back without updating, the dialog shows again on the next cold start.

Dismissal

dismissAppUpdate() writes { day: todayIsoDate() } to app-update-dismissed.json through jsonFileStore. todayIsoDate() is the device’s local calendar date. The result is at most one prompt per calendar day after a dismissal. The first cold start on a later day shows it again for as long as the binary is behind. The file is not tied to a version. It only stores the day.

Strings

appUpdateTitle, appUpdateBody and appUpdateCta in every locale file, plus the shared close label for the icon button.

Relation to OTA updates

The two mechanisms are independent.

	OTA update	Store update prompt
Delivers	JS and assets	A new native binary
Trainee action	None	Install from the store
Controlled by	`eas update` on a channel	The server’s release configuration

The prompt component itself is JS, so it also reaches old binaries over the air. That is the point: an old binary can be told about a new one. See OTA updates.

Overview

Getting set up

Conventions

Backend architecture

Building backend modules

Backend security and access

Background work and delivery

Backend platform features

Backend operations

Backend packages

Data model

JSON shapes

Web app: basics

Web app: data and API

Web app: auth, organizations and billing

Web app: UI foundations

Web app: feature areas

Web app: quality and delivery

Trainee app: foundations

Trainee app: UI

Trainee app: workouts

Trainee app: nutrition

Trainee app: forms, content and tracking

Trainee app: device features

Trainee app: native, build and release

Messaging integrations

Platform integrations

External API and automation

Operations

App update prompt

Endpoint

Is an update due?

When it shows

The dialog and the queue

Dismissal

Strings

Relation to OTA updates

​Endpoint

​Is an update due?

​When it shows

​The dialog and the queue

​Dismissal

​Strings

​Relation to OTA updates

Endpoint

Is an update due?

When it shows

The dialog and the queue

Dismissal

Strings

Relation to OTA updates