How long does regulatory app review actually take?

Apple says the typical app is reviewed within 24 hours. That is true. And if that is the only number you are planning around, you are going to get badly surprised. The 24-hour figure describes what happens inside Apple's review queue. It says nothing about how long it takes to get there, or whether your app makes it through on the first attempt, or what happens when a reviewer flags something you did not anticipate.

The 24-hour review window is real. The assumption that it represents your full timeline is not.

The real timeline for a regulatory app review is rarely 24 hours. For a straightforward lifestyle app with clean permissions and no payment flows, it can be close to that. For anything involving financial transfers, health data, or user-generated content, the actual timeline from submission to live product is often weeks, sometimes months. Not because review is slow, but because developers rarely understand where the time actually goes.

We have seen this across a range of projects, and the pattern is consistent. Teams plan their launch around the clock speed of review, not around the compliance work that has to happen first, or the rounds of rejection that follow when that work was not done. This article walks through where the time goes, what causes it, and how to stop it from derailing your launch.

What the published timelines actually say

According to Apple's published data, around 90% of App Store submissions are reviewed within 24 hours. Apple also offers an expedited review for time-sensitive situations, though granting it is at their discretion and there is no guarantee. Google Play operates on a similar timescale for most standard submissions, though apps that trigger additional human review can take considerably longer.

What these figures describe is the time Apple or Google spends looking at a submission that is ready to be reviewed. They do not include the time it takes to prepare a submission, resolve a rejection, or gather the documentation an automated system or human reviewer asks for. Each of those steps can add days. Multiple rounds can add weeks.

The published timelines also do not account for rejections that require design or development changes, not just a revised metadata field or an updated screenshot. When a rejection touches the product itself, the clock resets entirely. You are not resuming a paused review. You are starting again, and the new submission goes into the queue fresh.

Why most delays happen before submission, not during review

The gap between building an app and submitting it is where most launch schedules fall apart. Teams spend months in development and then discover, in the final days before submission, that certain features require permissions they have not documented, entitlements they have not applied for, or compliance frameworks they have not designed around.

Privacy permissions are the most common version of this. Both Apple and Google require that any permission request, microphone, location, camera, health data, is accompanied by a plain-language explanation of why the app needs it. Writing that explanation sounds simple. But if the actual feature architecture does not match what you write, the reviewer will notice. And if the feature was built without any thought given to what a reviewer would see, the explanation and the feature often do not align cleanly.

Payment flows introduce another layer. Any in-app purchase must use the platform's own payment system, and any subscription must meet specific disclosure requirements around pricing, renewal terms, and cancellation. These cannot be added at the last minute. They have to be built in, and built correctly, from the beginning.

Compliance decisions that must be made at the design stage

Compliance is a design problem, not a legal one. The decisions that determine whether your app sails through review or gets flagged are made during product design, and changing them after the product is built is expensive in time, money, and often in user experience.

There are a handful of decisions that cannot be deferred. Age-gating logic, for instance, has to be real. If your app targets adults, the mechanism that checks age has to work and be documented. An honour-system checkbox will not satisfy a reviewer for anything with content or transactions. Data minimisation has to be considered at the feature level: if you are collecting information about users, you need to know why and be able to explain it.

The compliance decisions that matter most early on tend to cluster around four areas.

Compliance decisions made at the design stage cost almost nothing. The same decisions made after build can cost weeks and a resubmission.

• Permission architecture: what you need access to, when you ask for it, and what you say when you ask
• Payment and subscription structures: which platform mechanisms you use and how cancellation is handled
• User-generated content moderation: what reporting and removal mechanisms are in place
• Age verification and content classification: whether your classification matches what the app actually contains

These are structural decisions, and each one shapes what you build.

What happens when compliance is retrofitted

We built a peer-to-peer currency exchange product that let users swap leftover foreign currency with other travellers at interbank rates, cutting out commission entirely. The core transfer mechanism worked well. What we had not factored in was anti-money laundering requirements. Apple flagged the product as a potential vehicle for money laundering because there were no limits on how many transfers two parties could make between each other, and no meaningful identity verification beyond basic registration.

We had to go back and retrofit several layers of compliance. We added more stringent KYC checks, enhanced the transfer security, and put hard limits on the number of transfers permitted between any two parties. Each of these changes touched the product architecture. None of them were simple configuration changes. And each one required a new submission, which meant going back into the queue.

The lesson from that project is not that the product was bad. It was genuinely useful and the financial logic was sound. The lesson is that the compliance requirements for a financial transfer product were knowable before a single line of code was written, and designing around them from the start would have cost a fraction of what retrofitting them cost later.

Before writing any code for a feature that involves money, health data, location, or identity, map out what the platform reviewer will look for. Apple's App Store Review Guidelines are public and specific. Reading them at the design stage takes an afternoon and can save weeks of resubmission cycles later.

How Apple's review process works in practice, and where it breaks down

Most App Store reviews are automated at first pass. Apple's systems check for known issues: API misuse, permission requests without corresponding entitlements, missing metadata, prohibited content categories. If the automated check passes, a human reviewer looks at the app. Human review is where subjective judgements enter the process.

Human reviewers follow Apple's guidelines, but those guidelines leave room for interpretation. Two reviewers can reach different conclusions about the same feature. A reviewer who is unfamiliar with a specific product category may apply a more cautious standard than one who has seen that category before. There is no appeal mechanism that is fast or guaranteed, and the reviewer's reasoning in a rejection notice is often brief.

Where the process breaks down

The clearest breakdown is when rejections accumulate without resolution. On the currency exchange project we ran, the app was rejected repeatedly. Each time we addressed the stated objection, Apple raised a new one. We capped transactions at €150 to address money laundering concerns, which should have removed the basis for that specific objection. The app was rejected again. The client ran out of budget and abandoned the product. It later became apparent that Apple Pay and other Apple payment services launched shortly after this period, and the rejections appeared to be tied to that rather than being genuinely compliance-based. There is no formal mechanism for challenging that kind of strategic gatekeeping.

What this means for planning

Build time into your schedule for at least one round of rejection, even if your product is clean. One round is realistic for a well-prepared submission. Two or three rounds happen on products that touch payments, health, or financial data. Planning for none is optimism that the timeline cannot afford.

When rejection is not about your product

Rejection notices are written in the language of compliance, but the underlying reason is not always compliance. Apple's guidelines give reviewers latitude that can be used to block products that compete with Apple's own services or with services Apple has a commercial interest in.

This is not a hypothetical risk. The currency exchange project is the clearest example we have seen of it directly. A product that was technically sound, financially useful to users, and not genuinely a money laundering risk was rejected across multiple rounds at a time that coincided with Apple's own payment product launches. The timing was not a coincidence, and we believe it was not.

There are also rejections that come from policy shifts Apple does not announce prominently. A guideline that was interpreted one way in January may be interpreted differently in March, and if your product sits in a grey area, the shift can hit you without warning. Monitoring Apple's developer news and guideline updates is not optional if you are in a category that Apple has any interest in owning.

If your app competes with or touches on a product category Apple has entered, build a longer runway into your approval timeline and have a contingency ready. This is especially relevant for payment products, health tracking, and streaming or content distribution.

What to audit before you submit

A pre-submission audit is not the same as a technical QA pass. Technical QA checks whether the product works. A pre-submission audit checks whether the product is ready to be seen by a reviewer who will look at it through the lens of Apple's guidelines, not through the lens of what it is meant to do for users.

The audit should work through a specific set of questions in order.

1. Does every permission request have a corresponding feature that a reviewer can find and test?
2. Does the App Store metadata, including description, screenshots, and age rating, accurately represent what the app actually contains?
3. If the app includes in-app purchases or subscriptions, are pricing, renewal terms, and cancellation clearly disclosed at the point of purchase?
4. If the app handles user data, is there a privacy policy, is it linked correctly, and does it describe what is actually collected?
5. If the app includes user-generated content, is there a reporting mechanism and a process for removal?
6. Does the app work fully on a device with no existing account and no pre-loaded content, the way a reviewer will test it?

The final point catches more teams than any other. Reviewers test apps on clean devices. Features that depend on existing data, previous sessions, or account states that reviewers cannot replicate will look broken, and a broken feature is a rejection reason, regardless of whether the feature works correctly for real users.

Create a dedicated reviewer account with a clean state before submitting. Walk through the app as that reviewer would, including any flows that require account creation or initial setup. If anything looks ambiguous or requires context a reviewer would not have, fix it before it becomes a rejection note.

Conclusion

The 24-hour review window is a real number, and it applies to what happens inside Apple's queue. Planning a launch around that number alone is where timelines go wrong. The time that actually governs a launch is the time it takes to prepare a compliant submission, and the time lost to rejection rounds when compliance decisions were not made early enough.

On the currency exchange product, retrofitting KYC checks and transfer limits after Apple flagged the app took far longer than designing those features into the product from the start would have. On products where Apple has a commercial interest in the category, no amount of compliance preparation fully removes the risk of strategic rejection, which is a different problem and requires a different kind of contingency planning.

What this comes down to is treating review readiness as a design constraint rather than a final check. The teams who move fastest through App Store review are the ones who invested in thorough app planning and strategy before writing the brief, built permissions and payment flows correctly the first time, and tested their submission on a clean device before it went anywhere near a queue.

The 24-hour stat is achievable. Getting there reliably takes work that starts months earlier than most people expect. If you are planning a regulated or payment-adjacent app and want to work through what that preparation looks like for your specific product, let's talk about your app launch.

Frequently Asked Questions