Startup, connection, and update states

Customer App can show loading, connection, unavailable, or update information while it prepares the current experience. These states are conditional and source-only for this documentation wave. A message or visible control does not prove that startup finished or that an earlier action completed.

Startup stages and owners

Startup stage	Responsible owner	What the visible state does not prove
App release and experience scope	Release and Customer App owners	That the installed app, project, business scope, or build is current or authorized
Local account and saved app state	Customer App and session owners	That stored account, cart, language, location, or project state is valid for this startup
Ordering startup information	Ordering-service and configuration owners	That every returned value is safe, complete, current, or deployed for this release
Device and external-service preparation	Operating system, privacy owner, and external service	Permission, consent, provider readiness, or successful handoff
Link or notification request	Customer App routing and Ordering authorization owners	Destination availability, resource ownership, or completion
Available customer screen	Customer App and the current product owner	That an order, payment, account change, or external action settled successfully

These stages can finish, fail, or become stale independently. The app needs one current startup generation before data or callbacks from a prior account, project, or attempt can be used.

While the app is loading

Wait for Customer App to show its next available state. If a customer screen does not appear, use only a clearly labeled in-app option or return later. Do not infer that a background request, provider setup, notification, order, payment, or account action completed because the loading state changed.

Connection, unavailable, and retry states

An interface connection does not prove that Ordering or an external service is reachable. If Customer App reports unavailable information:

1. Read the current message without treating earlier information as current.
2. Avoid repeating an action that could change an order, payment, account, preference, or provider state.
3. Use a retry only when the app identifies it as a status-safe read.
4. Return to an available customer screen only through the current in-app navigation.

A refresh, restart, foreground event, or reconnection is not proof that one failed action was retried safely.

Unknown outcomes

If the app lost a response after an action began, the result may be unknown. Unknown is not the same as failed, cancelled, unpaid, unchanged, or complete.

Keep the prior action pending until the current authorized Ordering state can be reconciled without repeating the effect. A result from a previous account, project, cart, session, or startup generation must not update the new one.

Update and store handoff

An update message can appear only in some Customer App experiences. Keep these stages separate:

Stage	Owner	Boundary
Update information	Customer App and release-policy owner	The message does not prove that an update is mandatory, current, or available in a store.
Store handoff	Operating system and approved store	Opening or leaving the app does not prove that the intended store page opened.
Download and installation	Operating system and store	A store result does not prove installation or relaunch.
Updated app startup	Customer App and Ordering compatibility owners	Relaunch does not prove that prior account, order, payment, or provider work settled.

This guide does not open a store, install an update, or promise whether an update is required. Use only the current labeled device option when you are ready to leave the app.

Project and experience changes

Some Customer App source variants can include a project-selection concept, but project selection, persistence, switching, restart behavior, and cross-project cleanup are not an accepted customer procedure.

Use the app release supplied for the intended experience. Do not enter, guess, reuse, or share a project or configuration value to change startup behavior. If the experience changes unexpectedly after restart, stop and confirm the intended release with the app owner.

Troubleshooting observable states

Observable state	First responsible owner	Safe next step
Loading or the splash state does not finish	Customer App startup owner	Wait or use the labeled local option; do not repeat order-changing work.
The app reports no connection or unavailable information	Connectivity and Ordering-service owners	Treat prior information as stale and keep effectful actions pending.
A response disappeared after an action	Owning order, payment, account, or provider service	Treat the result as unknown and reconcile status without repeating it.
An update message appears repeatedly or changes	Release-policy and Customer App owners	Do not infer mandatory status or install progress; use only the current message.
A store handoff is unavailable or returns to the app	Operating system and store-handoff owners	Keep update installation unverified; do not repeatedly leave the app.
The experience changes after restart	Release, project, and bootstrap owners	Stop and confirm the intended release; do not guess or persist values.
The wrong account or prior project information appears	Session and project-isolation owners	Do not proceed; keep the startup blocked until the current context is restored.
A permission or provider prompt appears during startup	Privacy, native-platform, and provider owners	Treat it as a separate gate; it does not prove startup readiness.

Accessibility and safe recovery

Loading, unavailable, update, and unknown states need a readable heading, current status, and a named action when an action is available. Status must not depend only on animation, color, vibration, or a disappearing alert. Focus and screen-reader announcements should move to the new state without repeatedly opening a provider or store.

Recertification triggers

Repeat this review after changes to App, shared-components, Ordering-service or release pins; startup/project/configuration ordering; stored session or cart restoration; connectivity/restart/foreground behavior; consent or provider initialization; link/notification handling; update policy or store handoff; native build identity; accessibility semantics; or cleanup after logout, account/project change, failed startup, or app update.

For related states, see Use the app offline and reconnect, Checkout status and retry guidance, Consent and privacy choices, Customer App experience variants, and Language, device, and accessibility considerations.