Business App architecture and configuration

Use this contract to decide where a Business App integration or configuration change belongs. The app combines a native shell, shared Ordering Components, Ordering API services, and device or third-party providers. A value visible in one layer does not prove that another layer supports it.

Before you start

• Identify the project and environment that the build is intended to use.
• Confirm whether the build uses a fixed project or allows an operator to choose a project before signing in.
• Treat API, socket, push, map, and device-provider settings as environment-owned configuration. Do not copy values between environments without their owner’s approval.
• Test with synthetic data and a build whose source, configuration, and backend relationship are known.

Scope and version

Authority	Supported public boundary	Version or pin limitation
Business App	Owns native startup, bundled theme and assets, project selection, navigation composition, and device handoffs.	This article reflects the release-facing source reviewed for the current documentation set. It is not proof of a particular installed binary.
Ordering Components	Owns the shared provider graph and client state for API access, configuration, language, session, orders, businesses, and realtime connections.	The app consumes an exact Components revision. A moving Components branch can behave differently.
Ordering API	Owns server authorization, validation, returned configuration, and data effects.	Source was reviewed, but its relationship to a deployed API environment is not attested.
Device and third-party providers	Own permissions, delivery, connectivity, and operating-system behavior outside the JavaScript application.	Availability varies by platform, provider setup, device state, and operator permission.

Inputs and configuration

Input or configuration	Owner	Validation and availability	Failure boundary
Project identity and project-selection mode	Build and deployment owner	The build must identify a project, or explicitly enable project selection before authenticated work begins.	A missing or stale project can prevent configuration, session, and data contexts from becoming usable.
API base, language, and API version	Deployment owner and Ordering Components	Components use these values to create the client used by shared contexts. The selected API environment must support the build.	A syntactically valid value does not prove reachability, authorization, or deployment compatibility.
Remote project configuration	Ordering API and project administrator	The API returns only configuration available to the current project and requester. Components merge supported defaults and feature values for the app.	Missing, protected, unavailable, or stale values must be handled as unavailable; they are not an entitlement signal.
Realtime and push configuration	Deployment owner and provider	The project, authenticated session, provider application, and device permission must all align.	Provider initialization or token registration can fail independently of ordinary API reads.
Theme, assets, and native capabilities	App release owner	These are bundled with the build and constrained by platform manifests and installed native modules.	A remote value cannot add a native capability that the installed binary does not contain.

Configuration flags are client-availability evidence only. They do not, by themselves, prove a commercial plan, permission, provider delivery, or server support.

Lifecycle and outputs

1. The native shell loads its bundled settings, theme, and assets.
2. When project selection is enabled, the shell waits for the stored project choice; otherwise it uses the project packaged with the build.
3. The shell gives the resulting settings to Ordering Components. Components create API, configuration, session, language, order, business, and realtime contexts around the application.
4. Remote configuration is loaded for the selected project. Authentication and project state then determine which workspace the navigation layer presents.
5. Device and provider integrations initialize only when their configuration, platform, session, and permission conditions are met.

The expected output is a configured application context, not a guarantee that every provider or backend action is available. Integrators should observe each boundary separately: build configuration, project selection, API response, session state, realtime connection, and device-provider result.

Native product scope

The reviewed native application registers operator workflows for orders, messages, businesses, profile and sessions, and printing-related tasks. It does not establish native destinations for general reports, broad administrative settings, a customer directory, or a general file manager.

Do not infer native support from a shared component, API capability, historical work item, or web feature. Keep unsupported work outside the native navigation contract unless a later release registers a destination and its authorization, runtime behavior, and documentation are independently verified.

Platform and provider limits

• iOS and Android package different permission declarations and operating-system behavior. Permission text or a linked native module does not prove that a workflow is reachable.
• API and realtime connectivity can initialize during normal startup. Launching the app is therefore not a read-only source check.
• Push, sockets, maps, files, printers, external applications, audio, vibration, and the clipboard cross provider or device boundaries. Test them only under a separately approved scenario with an effect and cleanup budget.
• Local project selection and other saved preferences are device state. Changing them can redirect subsequent API and realtime activity.

Troubleshooting and escalation

Observable behavior	Owning boundary	Next action
The app cannot finish startup after a project change.	Build/project configuration	Confirm the intended project-selection mode and selected project, then restart with a known non-production fixture.
The shell loads but project features are absent.	API configuration boundary	Verify the selected project and API environment. Treat a missing value as unavailable and ask the API or project owner to confirm it.
API data loads but realtime updates do not.	Realtime provider boundary	Check authenticated session state, network availability, and the environment’s realtime configuration separately from the API.
A device action is unavailable on one platform.	Native build or operating system	Confirm that the installed build includes the capability and that the required permission or provider is available.
A shared component exists but there is no native destination.	Business App navigation owner	Do not expose it as a native feature. Request a release-specific reachability and authorization review.

Related articles

• Business App navigation and push boundaries
• Business App overview

:::note Visual status Visual guidance is deferred. Architecture imagery requires a separate authorized and reviewed visual program. :::