Submitting an app is not the same as publishing an app. That gap matters when founders, product teams, and marketers are coordinating launch dates, campaigns, investor updates, or customer announcements. This guide explains what happens after submission, what can block publishing, and how to prepare a release package that is less likely to get stuck.
Early proof: submission starts review, publishing makes the app available
The core distinction is simple: submission starts platform review, while publishing makes the app available to users. Apple manages submission through App Store Connect review workflows, while Google Play separates review, approval, release, and production availability in Play Console.
| App state | What it means | User impact | Team outcome |
|---|---|---|---|
| Draft listing | Metadata, screenshots, and build are still being prepared | No public access | Internal work only |
| Submitted for review | The build and listing are in Apple or Google review | No public access | Review queue has started |
| Approved for release | The platform accepted the submitted package | May still not be public | Release decision is pending |
| Live or published | Release settings allow users to install the app | Public or staged access | Launch is actually happening |
What this means: uploading a build and clicking submit does not mean users can install the app. It means the platform can now review the build, store listing, privacy claims, permissions, payments, and release setup.
Review timelines vary, and no review window is guaranteed. Some reviews move quickly, while others take longer because of account history, app category, policy signals, data use, monetization, or production review context.
| Submission round | Common delay pattern | Usual cause | Launch impact |
|---|---|---|---|
| First submission | Variable review window | Initial review queue | Launch date is still uncertain |
| Second round | Fix time plus re-review | Crash, missing credentials, or policy mismatch | Campaigns may need to move |
| Third round | More fix time plus new findings | Privacy, permissions, metadata, or payment issues | Launch planning gets harder |
The business impact is practical. One rejection can turn a planned launch into a moving target, especially if paid acquisition, press outreach, influencer posts, or customer emails are already scheduled.
Treat the first submission date as a review-start milestone, not the public launch date. If timing matters, build in several business days for Apple review, Google Play checks, and at least one possible resubmission.
What actually happens after you click Submit
When you submit an app, you hand a full package to the platform. That package usually includes the build, screenshots, app description, content or age declarations, privacy details, support links, and test credentials when the app requires sign-in.
Apple's Submit an app guidance and Google's Publish your app documentation both separate review from public availability. Review checks can include crash behavior, metadata accuracy, permission justification, platform policy compliance, payment rules, and whether the app matches the listing.
A technically stable build can still fail because of a listing, privacy, or payment mismatch. Review is partly automated and partly human, so your app is judged by how it runs and by what it promises.
Approval is good news, but it may not mean users can install the app yet. Release settings determine when the approved app becomes public.
- On Apple, you can choose manual release or automatic release after approval.
- Apple's publishing overview separates approval from store availability.
- On Google Play, production review and production rollout are related but not identical.
- Staged rollout can intentionally limit exposure after approval.
- Country availability, pricing, phased release, and production track settings can affect who can install the app.
In practice, "approved" is a platform decision. "Published" is the event your users experience.
The reviewer often sees your app name, screenshots, subtitle, description, privacy disclosures, and subscription language before they fully experience the product. Those assets create expectations that the build must satisfy.
Common mismatches include screenshots showing a feature that is not in the submitted build, an app name implying a service the app does not provide, or subscription copy that does not match the actual in-app purchase flow. The store listing should describe what the reviewer will find now, not what your roadmap promises later.
A pre-submit workflow that makes publishing more predictable
Before app submission, gather the materials that make review easier for both the platform and your own team. This can take 1-3 focused days for a simple app, and longer if privacy, payments, account deletion, regulated content, or third-party SDKs are still unresolved.
You do not need a perfect launch package. You need a consistent one.
- A stable release build tested on real devices, not only simulators
- First launch, sign-in, onboarding, core workflow, logout, and account deletion tested where applicable
- Review credentials with working demo data
- Subscription or payment test paths, including restore purchase where relevant
- Support contact details and a live privacy policy URL
- A map of every permission used by the app and its SDKs
One dependency worth checking early is third-party SDK behavior. Your own feature may not request sensitive data directly, but analytics, attribution, ads, crash reporting, or messaging SDKs can still affect Apple privacy labels and Google Play Data Safety answers.
Run a reviewer-path QA pass
Test the path a reviewer will take: install, launch, onboarding, sign-in, core feature completion, purchase flow if applicable, and logout or account deletion. Use a fresh install, a slow network, denied permissions, and a clean test account.
Align store metadata with the submitted build
Check screenshots, description claims, app name, subtitle, category, content rating, support links, and visible feature set. If the build does not contain a feature, the listing should not sell it as available.
Reconcile compliance forms
Match Apple privacy labels and Google Play Data Safety answers against actual SDKs, analytics, permissions, and data sharing. The reviewer should not see one story in your privacy policy and a different story in app behavior.
Verify monetization and account rules
Confirm that subscriptions, in-app purchases, external payment references, free trials, and account deletion flows follow platform rules. Payment mistakes can require product, copy, and configuration changes, so they are rarely quick fixes.
Set release controls deliberately
Decide whether approval should trigger automatic release, manual release, phased release, or staged rollout. Publishing an app should be a controlled decision, not a surprise side effect of approval.
Workflow snapshot: release build QA -> listing alignment -> privacy and permission checks -> platform review -> approval -> release setting -> public availability.
Common reasons apps get submitted but not published
The most common problem is not one huge mistake. It is a chain of small contradictions that review exposes one at a time.
| Pattern | Examples | Launch effect |
|---|---|---|
| Build instability | Crash on launch, blocked sign-in, broken demo credentials, frozen onboarding | Review cannot complete the core path |
| Metadata mismatch | Screenshots, descriptions, names, or feature claims do not match the build | Corrections are required before release |
| Compliance contradiction | Privacy labels, Data Safety, SDK behavior, permissions, and policy copy conflict | Legal, product, and engineering may need to coordinate |
| Payment confusion | Subscription copy, restore purchase, pricing, or cancellation expectations are unclear | Monetization review can delay release |
One thing worth noting: a resubmission can reveal a new issue. Fixing the first rejection does not guarantee the next review will only check that item.
Use this condensed checklist before submitting to Apple or Google, and use it again before any resubmission:
- Build stability: fresh install, first launch, slow network, denied permissions, and reviewer credentials all work.
- Store metadata: screenshots, description, app name, category, content rating, and support URL match the submitted build.
- Privacy disclosures: privacy policy, Apple privacy labels, Google Play Data Safety answers, and SDK behavior are aligned.
- Permission rationale: camera, location, contacts, microphone, notifications, tracking, and background access are requested only when needed.
- Payment flow: subscriptions, pricing, restore purchase, trial language, and cancellation expectations are consistent.
- Release controls: manual release, automatic release, staged rollout, country availability, and production track settings are intentional.
The value of this checklist is not perfection. It gives your team a launch gate, so Apple or Google is not the first serious reviewer of your release package.
How to plan launch timing without overpromising
A good launch plan separates the submission date from the public launch date. This gives your team room for platform review, bug fixes, copy updates, and release setting checks without forcing every other team to react at the last minute.
A realistic plan usually includes:
- A pre-submit review window for QA, metadata, privacy, and payment checks
- A submission window before the desired public launch date
- A hold period for review variability and possible resubmission
- A manual release or staged rollout option if timing needs control
- A backup communication plan if approval arrives later than expected
The tradeoff is that extra buffer can feel slower. The upside is that marketing, support, sales, and stakeholders get a launch date that is less dependent on first-pass approval.
If the launch is tied to a conference, funding announcement, seasonal campaign, or paid media spend, avoid making store approval the single point of failure. Submit earlier, use manual release when appropriate, and keep public messaging flexible until the app is actually available.
What to do if your app is approved but not visible
If your app is approved but users cannot find or install it, check release settings before assuming review failed. The issue may be availability, rollout percentage, territory settings, pricing, or production track configuration.
Start with these checks:
- Is the app set to manual release?
- Is phased release or staged rollout limiting access?
- Are the correct countries or regions enabled?
- Is the production release fully rolled out?
- Are pricing, agreements, tax, or banking requirements complete?
- Are there normal propagation delays after release?
Some visibility delays are normal after a release action. If the app still does not appear after platform settings look correct, document the configuration and contact platform support with screenshots and timestamps.
The takeaway is simple: submission is a review event, while publishing is an availability event. Treat them as separate milestones and your launch plan becomes more honest, more manageable, and easier to explain to the rest of the team.
