Store Submission
Production builds go to the app stores, and the stores review them.
Where to find it
Architect Panel → Mobile Apps:
- Mobile Canvas — the app, its screens and its settings
- App Builds & Releases — building and submitting
- Mobile Devices — the devices that have installed it
Credentials live on the build host
Apple and Google credentials are read from the build host’s own configuration rather than being held in the app definition. That is deliberate — store credentials are among the most sensitive things an organisation holds, and they are not kept in the app record.
What gets apps rejected
- Vague permission purpose strings. The commonest cause and the easiest to fix.
- Declared permissions the app never uses — usually left over from something you tried.
- Background location without a compelling written justification.
- An app reviewers cannot sign in to. Provide working test credentials.
- An app that is mostly a website, with no native value.
- Missing privacy information, or information that does not match what the app does.
Give reviewers an account that works
The single most common avoidable delay. A reviewer who cannot get past your sign-in screen rejects the app, and you lose a week.
Provide credentials, and check them yourself the day you submit.
Write purpose strings for a reviewer
They are read by a person deciding whether your request is reasonable. Describe the specific job: not "to access your camera" but what the photograph is for and what happens to it.
Allow real time for the first submission
First submissions take longer than later ones and are rejected more often. Two or three rounds is normal. Do not schedule a launch on the assumption of a first-time pass.
Privacy declarations must match
Both stores ask what data the app collects and what it is used for. That declaration should match what the app actually does — the capability set is a good checklist, and an inconsistency is both a rejection and a compliance problem.
Releases are not instant
Even after approval, a release rolls out over hours and users update on their own schedule. Assume a long tail of old versions, which is what the minimum app version setting is for.
Plan the update path
Some users will not update for months. Decide what happens to them: keep working, be prompted, or be blocked below a minimum version. Blocking is occasionally right and should be a decision rather than an accident.
Worked example
An organisation was rejected twice on its first submission — once for a vague camera purpose string, once for an unused microphone permission left from a trial. Both were fixed in one rebuild. Later releases have passed first time, with test credentials checked on the day of submission.
Recommendations
- Provide working test credentials and verify them.
- Write purpose strings for a person, not a checklist.
- Remove permissions you abandoned before submitting.
- Allow for two or three rounds on a first submission.