The short answer
A mobile app does not "go live" the moment you finish building it. It has to pass through two gates first. The store gate is a human review at Apple and Google that decides whether your app is allowed on the store at all. The law gate is Singapore's Personal Data Protection Act (PDPA) plus the privacy declarations both stores now force you to fill in before you can even hit submit. Most first-time rejections happen because a team prepared the build but not the paperwork — the app works perfectly and still gets sent back.
This checklist puts both gates in one place: what the stores review and how long it takes, what you must declare about the data your app touches, and what Singapore law adds on top. Work through it before you submit, not after you are rejected.
How long store review actually takes
The single biggest planning mistake is treating "submit" as the launch date. It is not — review sits between them, and the two stores behave differently. Apple publishes a headline figure for its App Review; Google is deliberately vaguer and reserves the right to take much longer for accounts it wants to scrutinise.
| Store | Stated review time | Notes | Source |
|---|---|---|---|
| Apple App Store | On average, 90% of submissions reviewed in less than 24 hours | An average, not a guarantee; incomplete or complex submissions can take longer. Review runs seven days a week. | Apple Developer |
| Google Play — updates to existing apps | Processed and published "as soon as possible" | No fixed number published for routine updates. | Google Play Console Help |
| Google Play — new apps & certain accounts | Up to seven days or longer in exceptional cases | Newer developer accounts are reviewed more thoroughly to protect users. | Google Play Console Help |
Sources: Apple Developer — App Review; Google Play Console Help, retrieved July 2026.
The practical takeaway: if you have a hard launch date — a campaign, an event, a client deadline — submit with a buffer. For Apple, budget a few days even though most reviews are faster. For Google Play, and especially on a brand-new developer account, assume a week and be pleasantly surprised if it is quicker. Never schedule a marketing push for the day after you submit.
The build and listing checklist
Before either store will look at your app, the build and the store listing have to be complete. This is the mechanical part — nothing here is a judgement call, so there is no excuse to lose review days to a missing field.
The build itself
- A signed release build for each platform — a distribution-signed iOS build and a signed Android App Bundle (AAB) for Google Play.
- No crashes on the core flows, tested on real devices, not just simulators.
- A version number and build number that are higher than anything you have submitted before.
- All test scaffolding, debug menus and placeholder content removed.
The store listing
- App name, subtitle/short description and full description — accurate, with no claims the app cannot back up.
- App icon plus screenshots for the device sizes each store requires.
- Category, age rating/content rating questionnaire, and support contact details.
- A working support URL and a publicly accessible privacy policy URL — both stores require the privacy policy link, and a broken one is a fast rejection.
- Reviewer access: if any screen sits behind a login, supply a working demo account and notes, or the reviewer will reject what they cannot reach.
The privacy declaration checklist
This is the part teams underestimate. You can no longer publish an app without telling the store — and therefore the user — exactly what data it collects and why. Apple calls it App Privacy details (the "privacy nutrition labels"); Google calls it the Data safety section. Both must be completed before you submit, both cover data collected by third-party SDKs you have embedded (analytics, ads, crash reporting), and both make you responsible for accuracy — the store cannot verify your data practices for you.
| Requirement | Where | What you declare | Source |
|---|---|---|---|
| App Privacy details ("nutrition labels") | Apple App Store | Every data type collected by the app and its third-party partners, how it is used, whether it is linked to the user's identity, and whether it is used to track across apps. | Apple Developer |
| Data safety section | Google Play | What data is collected and shared, security practices (encryption in transit, a way for users to request deletion), and the purpose of each collection. | Google Play Console Help |
| Privacy policy URL | Both stores | A publicly accessible privacy policy link, kept current with the declarations above. | Apple / Google |
| Breach-notification readiness | Singapore PDPA | A process to notify the PDPC within three calendar days when a breach is likely to cause significant harm or affects 500 or more individuals. | PDPC |
Sources: Apple Developer — App Privacy details; Google Play Console Help — Data safety; PDPC.
Fill these in from the app's actual behaviour, not from memory. The most common accuracy trap is forgetting that an embedded SDK collects data on your behalf — an advertising or analytics library counts, and if your declaration says "no data collected" while the SDK quietly ships device identifiers, that is a misrepresentation the store can act on. Audit what every third-party library does before you tick the boxes.
PDPA: the Singapore law gate
Passing the store review does not make you compliant with Singapore law. If your app collects personal data from users in Singapore — a name, an email, a phone number, a location, a payment detail — the PDPA applies, and it runs on its own track regardless of what Apple or Google approved.
The obligation most app owners get caught by is data breach notification. Under the PDPA, a data breach is notifiable when it is likely to result in significant harm to the affected individuals, or when it affects 500 or more individuals. Once you have determined a breach is notifiable, you must notify the PDPC no later than three calendar days after making that assessment, and notify the affected individuals as well. This is not a store rule you can dodge by choosing the right checkbox — it is law, and the readiness has to exist before you launch, not after an incident.
Two more PDPA basics belong on the pre-launch checklist:
- Consent and purpose. Collect only the data you need, tell users what it is for, and get consent for it. This should match, word for word, what you declared to Apple and Google.
- A real privacy policy. The privacy policy URL both stores demand is also your PDPA-facing document. It should describe what you collect, why, how long you keep it, and how a user contacts you about their data.
Because the store privacy declarations and the PDPA duties describe the same data, the smart move is to write them once, from a single source of truth, so the nutrition label, the Data safety form, the privacy policy and your internal breach process all say the same thing.
Common rejection triggers
Most rejections are avoidable and mechanical. The ones we see repeatedly:
- Broken or missing links. A privacy policy URL or support URL that 404s is an instant bounce on both stores.
- Reviewer can't get in. Login-gated features with no demo account — the reviewer rejects what they cannot test.
- Privacy declaration that contradicts the app. Saying "no data collected" while an SDK collects identifiers.
- Crashes on first launch on the reviewer's device or OS version.
- Incomplete metadata — a placeholder description, a missing screenshot size, an unanswered content-rating question.
- Overclaiming. Description or screenshots that promise features the build does not actually ship.
After you hit submit
Submission is a state, not the finish line. After you submit:
- Watch the status. Both stores move the build through states (in review, approved, ready for sale/published). If a reviewer has a question, answer it quickly — a stalled reply restarts the clock.
- Stage a beta first where you can. Apple's TestFlight and Google Play's testing tracks let real users exercise the build before the public sees it, catching device-specific crashes early.
- Control the go-live. Approval does not have to mean instant release — both stores let you hold a release for a chosen date, so approval and launch are separate decisions.
- Plan the next update now. The same review runs on every update, so the buffer you built for launch applies for the life of the app.
How Namtech handles submission
At Namtech, submission is the last of our six steps — Discover, Design, Build, Test, Launch, Support — and it is planned from the start, not improvised at the end. We build cross-platform, so the same codebase ships to the App Store and Google Play in one coordinated release cycle rather than two separate scrambles. We complete the App Privacy details and the Data safety declaration from what the app actually does, and where Singapore's PDPA applies we scope the privacy policy and breach-notification readiness as an explicit line item rather than a hidden assumption.
Our published starting points are SGD 20,000 for a Starter/MVP, SGD 38,000 for a Business app and SGD 90,000 for an Enterprise platform, and after one scoping call you get a fixed quote that includes getting the app through review and onto both stores. If you would like a launch you can plan a date around, start with a scoping call or see the full breakdown on our pricing page.