Review itself is usually fast now, often a day or two. What costs time is a rejection, because it puts you back in the queue with a fix in between. Budget for one bounce on a first submission and you will rarely be wrong.
The common rejections
- 01Missing demo account. If any part of the app needs a login, reviewers need working credentials in the review notes. This is the most common and the most avoidable.
- 02Broken or incomplete functionality. A placeholder screen, a dead link, a feature that errors. Reviewers do open things.
- 03Payments outside the platform. Selling digital content or subscriptions has to use the platform's purchase system, with narrow exceptions.
- 04Privacy declarations that do not match behaviour. If the app requests a permission, the declaration must cover it and the reason must be visible to the user.
- 05Not enough app. A thin wrapper around a website gets rejected as offering no more than a browser would.
- 06Account creation with no way to delete the account, which is now required.
Before you submit
- Working demo credentials in the review notes, tested from a fresh install.
- Every permission prompt explained in plain language at the point it is requested.
- Privacy declarations completed accurately, including third-party SDKs, which collect more than people expect.
- Screenshots for every required device size, showing real screens rather than marketing renders.
- Support URL and privacy policy URL live and reachable. Both get checked.
- A test on a real device from a clean install, not just the simulator.
Timeline to plan for
| Stage | Realistic |
|---|---|
| First submission to first response | 1 to 3 days |
| Fixing a typical rejection | 1 to 5 days |
| Resubmission | 1 to 3 days |
| Total, first release | 1 to 2 weeks after the build is finished |
One thing that matters more than the rest
Accounts must be in your company's name, not a developer's personal account. Apps published under an individual's account become a serious problem the moment that relationship ends, and transferring is not always straightforward.
Set both developer accounts up in the company's name before the build finishes. It costs an annual fee on one platform and a one-off on the other, and it prevents a category of problem that is genuinely painful to unwind.
Working on something like this?
We build websites, stores and custom applications, and we will tell you honestly if the thing you are describing does not need one.