What is actually shared in a white-label app?
The strongest candidates for sharing are product behaviours that should remain consistent: authentication, navigation, booking or ordering flows, API access and common interface components.
Brand identity, customer-specific content and configuration can sit above that shared foundation.
Branding should be configuration, not a fork
Creating a new source-code branch for every customer feels simple at first and becomes difficult as fixes and features need to be repeated. A better model defines the parts allowed to vary and builds them into a controlled brand or tenant configuration.
Tenant data must remain distinct
A shared application does not mean shared customer data. The backend architecture needs an explicit tenancy model so the app loads the correct organisation, content, permissions and data for the branded product.
App-store distribution changes the operational model
Publishing several branded applications means managing bundle identifiers, icons, screenshots, store metadata, signing and release coordination for each app. That overhead should be planned rather than treated as a one-off launch task.
When one multi-brand app may be better
If separate app-store identities do not create meaningful customer value, one app that switches organisation or brand context can be simpler to distribute and maintain.
The choice should follow how customers discover and understand the product, not only what is technically possible.