---
title: "Manage Customer App startup and updates"
description: "Configure the documented app-version check and understand Customer App loading, connection, and update states."
canonical: https://docs.ordering.co/docs/products/customer-app/app-behavior/startup-updates/
---

# Manage Customer App startup and updates

Customer App can show loading, connection, unavailable, or update information while it prepares the current experience. Use the documented **App version check** setting when it is available in your Dashboard to configure update behavior for the intended Customer App release.

A message, loading change, store handoff, or visible control does not prove that startup finished, that an update is installed, or that an earlier account, order, payment, or provider action completed.

## Configure the app-version check

The screenshots show the documented Dashboard path:

1. Open **Settings**.
2. Open **Advanced settings**.
3. Find **App version check**.
4. Enable the setting for the intended project through the current Dashboard workflow.

The setting's availability, location, label, saved value, and enforcement can vary by Dashboard release and project. Confirm the current control before changing it. Select an image to enlarge it.

[![Ordering.co Dashboard Advanced settings with App version check highlighted](https://docs.ordering.co/img/help-center-import/96520cc310b812147bee1348.jpg)](https://docs.ordering.co/img/help-center-import/96520cc310b812147bee1348.jpg)

Before expecting a customer update path, make sure the intended Customer App release has been submitted and is available through the applicable app store. Uploading or re-uploading a release is a separate store process. The Dashboard setting does not prove that a store listing is live, that the correct device can install it, or that the installed app is compatible with the current project.

## What customers may see

When the configured update behavior applies, Customer App can present an update message and an action such as **Update**. The example asks the customer to update the app before continuing.

[![Customer App update message with Update action](https://docs.ordering.co/img/help-center-import/841433de253aee12e2299df1.png)](https://docs.ordering.co/img/help-center-import/841433de253aee12e2299df1.png)

The update action can hand the device to its app store. Opening or leaving the app does not prove that the intended store page opened, that the download finished, that installation succeeded, or that the updated app relaunched. Use only the current device option when the customer is ready to leave the app.

## Verify the update path without overclaiming

Use a controlled check for the intended project, platform, and release:

1. Confirm the current Dashboard setting and the intended Customer App build.
2. Confirm that the correct iOS or Android store listing is available to the test device.
3. Open the app with an eligible test context and observe the current update state.
4. If the app presents an update action, verify the immediate store handoff without assuming installation or relaunch.
5. After a normal installation and relaunch, confirm the current customer state again. Do not infer that prior account, order, payment, or provider work settled while the app was updated.

An update message can be conditional. It is not a promise that every customer, release, device, project, or store will show the same message or behavior.

## 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.co startup information         | Ordering.co 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.co 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.co 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.

## Keep unknown outcomes pending

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.co 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.

## Project and experience changes

Some Customer App 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.

## Troubleshoot 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.co 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.

For related states, see [Use the app offline and reconnect](https://docs.ordering.co/docs/products/customer-app/app-behavior/offline-reconnect/), [Checkout status and retry guidance](https://docs.ordering.co/docs/products/customer-app/cart-checkout/failures-retries/), [Consent and privacy choices](https://docs.ordering.co/docs/products/customer-app/app-behavior/consent/), [Customer App experience variants](https://docs.ordering.co/docs/products/customer-app/app-behavior/deployment-variants/), and [Language, device, and accessibility considerations](https://docs.ordering.co/docs/products/customer-app/app-behavior/platform-accessibility/).