---
title: "App Store Review Time: How Long Does Apple Take? | WAA"
description: Learn how the app store approval process works, what Apple reviewers check, how long review takes, and how to avoid rejections that delay your launch.
image: https://weareaffective.com/hubfs/learning-centre-images/how-does-the-app-store-approval-process-work-and-how-long-does-it-take.webp
---

[Skip to content](https://weareaffective.com/learning-centre/how-does-the-app-store-approval-process-work#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# How Does the App Store Approval Process Work? (And How Long Does It Take?)

 Table of Contents

The app store approval process cost one of our clients their entire product. We worked on a peer-to-peer currency exchange app where travellers could swap leftover foreign notes with other travellers at interbank rates, skipping the bureau fees. Apple rejected it. We fixed the thing Apple asked us to fix, resubmitted, and Apple came back with a fresh objection. That cycle ran until the budget was gone and the client walked away from the product.

> Review is mostly a formality, right up until the day it decides whether you have a business.

That's the far end of what can happen, and most apps never go anywhere near it. For the majority of submissions, review is a day or two of waiting and then a green light. The trouble is that founders plan for the average and get caught by the exception, usually because nobody told them what review actually looks at or who holds the keys to the developer account.

So this is the practical version. What Apple does with your build, how long apple app review time really runs, who should own the account, what gets apps rejected, and what to do when a rejection makes no sense. Much of it comes from projects where we got it wrong first and learned the hard way.

## What the App Store Approval Process Actually Is

Your developer uploads a build from Xcode into App Store Connect, which is Apple's web dashboard for everything to do with your app. Automated checks run first, looking at things like encryption declarations, private API usage and whether your privacy manifest lines up with the code. If that passes, the build becomes available to submit alongside your listing, and the submission goes into a queue.

Then a person opens your app on a real device and uses it. They work through it against the App Review Guidelines, which cover safety, performance, business model, design and legal obligations. They read your description, look at your screenshots, test your sign-up, and try the thing you say the app does. They also check your pricing, your subscriptions and your privacy answers.

#### Who actually looks at your app

It's a human reviewer with limited time and a checklist, and that shapes everything about how you should prepare. They're not hunting for reasons to fail you, and they're not going to work hard to understand a confusing product either. In 2024 Apple rejected 1,931,400 of 7,771,599 submissions, roughly a quarter of everything sent in, according to [Apple's 2024 App Store Transparency Report](https://www.apple.com/legal/more-resources/docs/2024-App-Store-Transparency-Report.pdf). Rejection is normal. Plan for it as a stage rather than a disaster.

## How Long Apple App Review Takes in Practice

For a straightforward app with no regulated functionality, review is fast. Apple app review time averages 24 to 48 hours from submission to decision, [according to Low/Code Agency](https://www.lowcode.agency/blog/app-store-review-time), with first-time submissions and big updates running longer, and September and December queues stretching past three days as everyone rushes around new OS releases and Christmas.

The number that matters to your launch date isn't the single review, though. It's the round trip. A rejection on Tuesday afternoon can mean a code change, a QA pass, a new build, a new upload and a fresh place in the queue, and suddenly a 36-hour process has eaten a week. Two rejections and you've lost a fortnight.

#### Planning around the app store approval process

As part of solid [app planning and strategy](https://weareaffective.com/app-planning-strategy), we tell clients to treat a first submission as a two to three week window of calendar time, not a two-day wait. That gives room for one or two rounds of back and forth without anybody having to move a campaign date or disappoint a retailer. If it clears in 24 hours, you've gained time. If it doesn't, nothing breaks.

Submit early in the week. A rejection that lands on Friday evening tends to cost you the whole weekend before anyone can act on it.

## Design built to *grow* your product

We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## Setting Up the Developer Account and Who Owns It

On a social football product we worked on, the client set up the App Store Connect account themselves, so it was registered in their name and they held the Account Holder role. They gave us admin access to the majority of the account, which was the right arrangement, and it's the one we'd recommend to anyone. The app is the client's asset, the developer programme fee comes off their card, and the legal agreements sit with their business.

> Whoever registers the developer account owns the app, so decide that name before anybody pays the fee.

What that structure does mean is that the client can do anything they like inside the account, including things you've asked them not to. Roles only work while everyone respects them. Agree in writing who submits, who releases and who talks to Apple, because the permissions alone won't settle it.

| Role | What it controls | Who holds it |
| --- | --- | --- |
| Account Holder | Legal agreements, renewals, the account | The client, named on the business |
| Admin | Users, roles, app settings | Client lead and build team |
| App Manager | Builds, metadata, submissions | Whoever ships |
| Developer | Build uploads and TestFlight | Engineers |
| Marketing | Listing copy and assets | Brand and content people |

## Preparing a Build That Passes First Time

Most first-time rejections are avoidable, and they come from small omissions rather than anything deep. The reviewer has to be able to see your whole product working, on their device, with no help from you beyond what you've written in the notes field.

We run through this before any submission goes in.

1. A working demo account with username and password in the review notes, kept live until you're approved.
2. Every feature reachable, including anything behind a paywall, an invite code or a location.
3. No placeholder copy, grey boxes, dead links or "coming soon" screens anywhere in the build.
4. Permission prompts that say why you want the camera, the location or the notifications.
5. Privacy labels that match what the app genuinely collects and sends.
6. A crash pass on older devices and smaller screens, not just the newest handset in the studio.

If your app has anything unusual in it, a hardware pairing, a physical product, an in-person step, record a short video walking through it and attach it. Reviewers can't buy your supplement subscription or visit your hotel, and a video answers the question before it's asked.

Write the review notes as if the reader has never heard of your brand, because they haven't, and they've got a queue behind you.

## What Apple's Reviewers Actually Check

The guidelines break into five areas and the reviewer moves through them in roughly that order. Safety covers user-generated content, moderation tools, and anything that can harm somebody. Performance covers crashes, broken features and incomplete builds. Business covers payments, subscriptions and what you're allowed to charge for outside Apple's system. Design covers whether the app does enough to deserve a place on the store. Legal covers privacy, data handling and category-specific regulation.

Plenty of the rules exist because teams kept doing things users hated. Ratings prompts are a good example. We had a client add a rating prompt that fired the moment somebody opened the app, before they'd done anything at all. Apple requires the official rating API, which limits how often that prompt can appear, and the limit is doing the user a favour.

#### The behaviour behind the rule

As Simon puts it, "people just haven't had chance to experience the value of the product", so a rating asked at launch is meaningless or actively misleading. [Ask after someone's had a positive moment or achieved something](https://weareaffective.com/learning-centre/what-the-first-30-days-of-a-lifestyle-subscription-should-actually-teach-a-custo) in the app. The guideline and the good design decision point the same way here, which is true more often than teams expect.

## The Most Common Reasons Apps Get Rejected

The single biggest cause is nothing to do with policy. Performance violations, meaning apps that crash, freeze or fail to show the features they claim, accounted for around 1.24 million of the 1.93 million rejections in 2024, more than every other category put together, [according to Apple's own transparency report](https://www.apple.com/legal/more-resources/docs/2024-App-Store-Transparency-Report.pdf). Most rejected apps are broken, not banned.

After that, the pattern is fairly consistent.

- A demo account that doesn't work, or features the reviewer can't reach.
- Screenshots and descriptions that promise something the build doesn't do.
- Privacy labels that don't match the SDKs inside the app.
- Payments taken outside Apple's system for digital goods.
- User-generated content with no reporting, blocking or moderation.
- Sign-up walls in front of content that doesn't need an account.

That last one carries a cost beyond review. [Forcing registration early is one of the clearest drivers](https://weareaffective.com/learning-centre/when-users-blame-themselves-for-your-confusing-app-youve-already-lost-them) of uninstalls inside the first couple of minutes, because people haven't seen anything worth handing over an email address for yet. Fixing it to satisfy a reviewer usually improves retention as a side effect.

## Regulated Categories: Finance, Health and Data

On the peer-to-peer currency exchange product, we built the core transfer mechanism properly and didn't factor in anti-money laundering requirements at all. Apple spotted it immediately and flagged the product as a possible vehicle for laundering, because transfers between two users were unlimited. We went back and retrofitted several layers of compliance, more stringent know your customer checks, tighter transfer security, and hard caps on how many transfers any two parties could make.

Partway through we also discovered that direct peer-to-peer payment transfers of that kind weren't permitted, by law or by Apple's rules. The product had to become location-based and in person, where two travellers meet and physically swap notes.

> We built the transfer mechanism beautifully and only then found out it wasn't allowed to exist.

Even after the pivot, Apple came back on money laundering again, and we imposed a limit of roughly €100 to €150 on any single exchange to close it down. Finance, health, dating and anything handling children's data all carry this risk. [Find the regulatory boundary in week one](https://weareaffective.com/learning-centre/why-80-percent-of-business-apps-fail-and-how-to-be-in-the-20-percent), with a lawyer, before a single screen gets designed.

## When Rejection Isn't Really About Compliance

Sometimes you fix the stated problem and a new one appears. On that currency exchange project, every objection we answered was replaced by another. The client spent real money on legal counsel and compliance work, met everything Apple had asked for in writing, and got rejected again. In Simon's words, "it was clear that there was something else going on, that Apple just didn't want to allow this on the store for whatever reason."

The client ran out of budget and the product died. Apple Pay and other payment services launched a little while afterwards, and we believe the timing wasn't a coincidence.

There's no effective way to challenge that behaviour. A well-funded incumbent can keep a compliant competitor off the store indefinitely, and the appeal routes assume good faith on both sides. So if you're building anything that sits close to a service Apple sells, do two things. Get the specific guideline number for every rejection in writing, so a pattern of moving targets is documented. And set a ceiling in advance on how much time and money you'll spend appealing before you look at the web, Android or a different model entirely.

## Using the Resolution Centre and Resubmitting

Every rejection arrives in the Resolution Centre inside App Store Connect, with a guideline reference and usually a screenshot. That thread is your conversation with the review team, and it stays attached to the app, so treat it as a written record rather than a support ticket.

The sequence that works for us goes like this.

1. Read the guideline they cited, in full, before touching any code.
2. Reply in the thread asking for the specific screen or behaviour if the reason is vague.
3. Fix the thing they raised and nothing else, so the next review has one change to assess.
4. Attach a short screen recording showing the fix in context.
5. Resubmit, and if the date genuinely can't move, request an expedited review.

You can also appeal to the App Review Board when you think the guideline has been applied wrongly. It's slower than a resubmission and worth saving for cases where you're confident the reviewer has misread the product. Expedited review works on real deadlines and on fixes for serious bugs. Ask for it twice in a month for no good reason and it stops working.

Keep replies short, factual and free of frustration. The person reading has no history with your project and no interest in the last reviewer's decision.

## Managing TestFlight and Build Access Before Launch

TestFlight is Apple's beta distribution system, and it's where the build lives before the store does. Internal testers are people with access to your App Store Connect account and get builds straight away. External testers can be anybody with an email address, up to 10,000 of them [according to Foresight Mobile](https://foresightmobile.com/blog/ios-app-distribution-guide-2026), and external builds go through a lighter Beta App Review first.

On the social football product, we set up three groups. One for our team, one for the client's internal people, and one external QA beta group for the client's testers. The structure let us control exactly which build went to which group during deployment, so feedback came back against a known version.

As launch approached, the client started going into the account and sending builds that were already uploaded to whoever they fancied in whichever group. It caused problems. Testers were reporting bugs from builds we'd already superseded, and because everything sat on the client's account, we had limited ability to stop it.

Agree the rule before you need it. One person pushes builds to groups, everyone else requests. Permissions won't enforce that on an Account Holder, so the agreement has to.

## Choosing Your Category, Pricing and Metadata

We worked on [a gifting and wishlist platform](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need) where the client was hesitant to put any money into App Store Optimisation. Their thinking was that the product was social and group-based, so word of mouth would carry it. Our view was that the listing still has to do its job, because referral only gets somebody to the page. The icon, the title, the first two screenshots and the opening line of the description are where they decide.

> The listing is where people work out they're not your user, which saves you an uninstall three days later.

People who download knowing exactly what the app does open it with correct expectations, and that alone pulls early abandonment down. The ones who'd have hated it never arrive. Simon's point is that you want people downloading in an informed way, already aligned to what the product is.

Practically, your category affects both discovery and the guidelines you're held to, so pick the one that describes the app rather than the one with the softest competition. Set up pricing, in-app purchases and subscriptions before you submit, because those products get reviewed alongside the build and a missing one holds up the whole submission.

## Getting Updates Through Review After Launch

Updates go through the same pipeline, and they're generally quicker because the app already exists and the reviewer has history on it. The live version stays on sale throughout, so a rejected update costs you time rather than revenue.

Two things surprise teams after launch. The first is that something which passed five times can fail on the sixth, usually because a guideline changed or a different reviewer read it differently. Arguing that it was fine last time rarely helps. The second is that changes to your description, keywords, screenshots and promotional text don't always need a new build, so listing work can move at its own pace.

Phased release is worth using for anything substantial. Apple rolls the update out to a growing percentage of users over seven days, and you can pause it if your crash rate moves. You get the same approval, with a smaller blast radius if something's wrong.

Never line a paid campaign up against an unapproved build. Get the approval, hold it as Pending Developer Release, then release on your date.

## Building Review Time Into Your Launch Plan

The projects that struggle with review are usually the ones that struggled with everything before it. On [a fitness and wellness product we worked on](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps), two co-founders who were new to app development kept signing off designs and then walking the sign-off back once we started building, saying they hadn't understood that was what would be built. There was no consensus between them, and approval seemed to come out of politeness rather than a decision.

We warned them repeatedly that the budget was going on design iterations with no material effect on the product. It fell on deaf ears. The work finished at the design and research stage, because the money ran out before anything was built. That app never reached review at all, let alone the store.

Review is the last gate in a long process, and [a team that can't make decisions](https://weareaffective.com/learning-centre/how-to-structure-a-two-week-pre-build-discovery-that-earns-its-fee) won't suddenly start making them under a rejection notice. Work in releases. Get a small, complete version through the app store approval process early, learn how your own product behaves in the queue, then build on top of something that already exists on the store.

## Conclusion

For most lifestyle apps, approval is undramatic. Build something that works on an old handset, give the reviewer a working account and clear notes, make your listing honest about what the app does, and you'll clear review in a day or two with everyone else. The preparation that gets you through is the same preparation that keeps users past the first week, which is why we don't treat it as a separate compliance exercise.

The exceptions are worth planning for honestly. If your product touches payments, health data, children or anything adjacent to a service Apple already sells, find the regulatory boundary before design starts rather than retrofitting it afterwards like we had to on the currency exchange app. Keep a written record of every rejection and the guideline behind it. And decide in advance how much you'll spend fighting before you change the plan.

Mostly, give yourself room. A fortnight of slack costs you nothing if you don't need it, and saves the launch if you do.

If you're heading towards a first submission and want a second pair of eyes on the build, the listing or the account setup, [let's talk about your app launch](https://weareaffective.com/get-started).

## Frequently Asked Questions

How long does the App Store approval process actually take?

For a straightforward app with no regulated functionality, Apple review typically takes 24 to 48 hours from submission to decision. First-time submissions and major updates tend to run longer, and queues in September and December can stretch past three days as developers rush around new OS releases and Christmas.

Why should I plan for two to three weeks rather than two days?

The number that matters to your launch date is the round trip, not the single review. A rejection means a code change, a QA pass, a new build, a new upload and a fresh place in the queue, so a 36-hour process can easily eat a week. Treating the first submission as a two to three week window gives room for one or two rounds of back and forth without moving campaign dates.

What actually happens to my build after it is uploaded?

Your developer uploads the build from Xcode into App Store Connect, where automated checks run first on things like encryption declarations, private API usage and whether your privacy manifest matches the code. If that passes, the submission joins a queue and a human reviewer opens the app on a real device and works through it against the App Review Guidelines.

Who reviews my app, and what are they looking at?

A human reviewer with limited time and a checklist opens your app and tests it against the App Review Guidelines, covering safety, performance, business model, design and legal obligations. They read your description, look at your screenshots, test your sign-up and try the thing you claim the app does. They also check your pricing, your subscriptions and your privacy answers.

How common is rejection?

Rejection is entirely normal. In 2024 Apple rejected 1,931,400 of 7,771,599 submissions, roughly a quarter of everything sent in, according to Apple's App Store Transparency Report. It is best treated as a stage in the process rather than a disaster.

Can the approval process genuinely kill a product?

It can, though it is rare. One client's peer-to-peer currency exchange app was rejected repeatedly, with Apple raising a fresh objection each time a previous one was fixed, until the budget ran out and the client abandoned the product. Most apps never come close to this, but founders who plan only for the average are the ones caught out by the exception.

What makes an app more likely to hit trouble in review?

Regulated or unusual functionality raises the risk considerably, as does anything a reviewer has to work hard to understand. Reviewers are not hunting for reasons to fail you, but they will not spend extra time deciphering a confusing product either, so clarity in your app, description and screenshots matters.

Who should own the developer account?

The account should sit with the business that owns the product, not with an individual developer or agency by default. Ownership determines who holds the keys to submissions, updates and the listing itself, which becomes critical if a working relationship ends or a rejection needs resolving quickly.

## Related Articles

[![How app developers can get their apps into the app store?](https://weareaffective.com/hubfs/learning-centre-images/how-app-developers-can-get-their-apps-into-the-app-store.webp)](https://weareaffective.com/learning-centre/how-app-developers-can-get-their-apps-into-the-app-store)

### [How app developers can get their apps into the App Store](https://weareaffective.com/learning-centre/how-app-developers-can-get-their-apps-into-the-app-store)

Getting an app into the Apple App Store or Google Play is one of those tasks that looks simple from...

by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee)

[![Why do updates get approved faster than new apps?](https://weareaffective.com/hubfs/learning-centre-images/why-do-updates-get-approved-faster-than-new-apps.webp)](https://weareaffective.com/learning-centre/why-do-updates-get-approved-faster-than-new-apps)

### [Why do updates get approved faster than new apps?](https://weareaffective.com/learning-centre/why-do-updates-get-approved-faster-than-new-apps)

If you have ever submitted a new app to the App Store and watched the clock, you will know the...

by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee)

[![How can you expedite your apps review process legally?](https://weareaffective.com/hubfs/learning-centre-images/how-can-you-expedite-your-apps-review-process-legally.webp)](https://weareaffective.com/learning-centre/how-can-you-expedite-your-apps-review-process-legally)

### [How can you expedite your apps review process legally?](https://weareaffective.com/learning-centre/how-can-you-expedite-your-apps-review-process-legally)

The App Store review process looks simple from the outside. You build something, submit it, and...

by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee)

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.