Getting an app rejected by App Store review the week you planned to launch is painful, and it often feels more final than it is. Most rejections are fixable in one to three days. Start by reading the cited guideline closely and reproducing exactly what the reviewer saw.

The exceptions are rejections under guideline 4.2 or 4.3. These question whether the app should exist in its current form. This guide shows how to tell the difference, which fixes work, and how to protect yourself if your agency is the real problem.

Diagnose an app rejected by App Store review in under an hour

Start in App Store Connect, not in the code. Open the rejection message and write down three things: the guideline number, the device the reviewer used and the iOS version. Then work through these checks in order.

  1. Look up the guideline. Find the exact clause in Apple's App Store Review Guidelines. If your team can't quote the clause, they are guessing.
  2. Check the attachments. Reviewers often attach screenshots or a screen recording. That shows you the failing screen faster than any log.
  3. Reproduce on the same device class. Reviewers often test iPhone apps on an iPad. Delete the app, install the exact build from TestFlight and follow the reviewer's path.
  4. Pull crash logs. Check Xcode Organizer and your crash tool, such as Crashlytics or Sentry. Filter by the submitted build number.
  5. Test the demo account. Log in with the credentials you entered under App Review Information. Expired passwords, two-factor prompts and empty test data cause many avoidable rejections.
  6. Test on IPv6. Apple requires apps to work on IPv6-only networks. Create a NAT64 network with macOS Internet Sharing and run the main flows.
  7. Scan Info.plist. Every permission needs a clear purpose string. For example, NSCameraUsageDescription should explain why you need the camera, not just say "Camera access".

What good versus bad looks like

  • Good: one guideline is cited, you reproduce it in minutes, and the fix touches one screen or one setting.
  • Bad: you can't reproduce it, or several guidelines are cited. Another warning sign is a message saying the reviewer "could not find" core features.

A free code or performance audit can tell you within days whether your rejection needs a fix or a rebuild.

The five most common causes, ranked

Apple's App Review page says over 40% of unresolved issues relate to guideline 2.1, App Completeness. The rest of this ranking comes from our own rescue work, not Apple data. Your mix may differ.

1. App completeness (guideline 2.1)

This covers crashes, dead links, placeholder text, "coming soon" buttons and broken demo logins. Fixes typically take hours to two days. The usual root cause is testing on a simulator with a warm cache instead of a clean device.

2. Privacy and data (guideline 5.1)

Common gaps include a missing privacy policy link and vague purpose strings. Another is account creation with no in-app account deletion. Since May 2024, Apple also expects privacy manifests for many third-party SDKs, so an outdated analytics or ads library can trigger this. Expect one to three days, longer if an SDK must be upgraded.

3. Accurate metadata (guideline 2.3)

Screenshots show features the build doesn't have. The description mentions Android, or the age rating doesn't match the content. These are mostly copy and asset changes. You can often fix them the same day without a new build.

4. Payments (guideline 3.1.1)

Digital goods and subscriptions sold in the app generally must use Apple's in-app purchase. A Stripe checkout for digital content is a common trigger. Moving to StoreKit takes typically one to three weeks, because receipts, entitlements and your backend all change.

5. Minimum functionality or spam (guidelines 4.2 and 4.3)

This is the rejection to worry about. Thin web wrappers, lightly reskinned templates and near-duplicates of your own apps land here. No single bug fix answers it. You need native features or a clear reason the app is different.

Fix or rebuild?

Most rejections are fixes. A small share point to a product or architecture problem that a patch won't solve.

Usually a fix

  • A crash in one flow, a broken demo login or a missing purpose string
  • Metadata, screenshots or age rating mismatches
  • Account deletion added to an existing settings screen
  • An outdated SDK that needs a version bump and a privacy manifest

Often a rebuild of part or all of the app

  • A 4.2 rejection for an app that mostly wraps a website in a WebView
  • A 4.3 rejection for a template app with no meaningful differences
  • A 3.1.1 rejection where payments are wired through the whole codebase
  • Repeated crashes with no tests, no crash reporting and no one who knows the code

A partial rebuild of the payment layer or core screens typically runs four to ten weeks. Rewriting everything is rarely needed. It makes sense when the codebase can't be built reliably by anyone outside the original team.

How to resubmit fast

Reply to the rejection in App Store Connect before you resubmit. State what you changed, which build fixes it and how to test it. Reviewers read these notes, and a clear test path cuts back-and-forth.

  • Add reviewer notes: step-by-step login, test data and any hardware the app needs.
  • Request an expedited review only for a critical fix or a time-bound event. Apple limits how often it grants them.
  • Appeal to the App Review Board if you believe the reviewer misread the app. Be specific and calm, and quote the guideline.

Apple says most submissions are reviewed within 24 hours. In practice, the slow part is usually your fix, not Apple's queue.

Protect yourself if the agency relationship is failing

Rejections often expose a deeper problem: an agency that has gone quiet or can't reproduce its own bugs. Before you raise the issue, make sure you control everything needed to ship without them.

Technical access to secure this week

  • Apple Developer account: your company should be the Account Holder. Give the agency a Developer or App Manager role, never Account Holder.
  • Source code: the repository should live in your GitHub, GitLab or Bitbucket organization, with full history.
  • Signing and keys: distribution certificates, the APNs .p8 push key and App Store Connect API keys. Store them in a password manager you own.
  • Backend and services: cloud accounts, domains, Firebase or Supabase projects, analytics and crash tools, all billed to you.
  • Build pipeline: CI configuration, environment variables and the steps to produce a release build.

Contract and documentation

Check that your contract assigns IP to you on payment. It should also include a handover clause requiring code, credentials and documentation on exit. Ask for a short README covering setup, environments and known issues. If they won't provide it, that tells you how the rescue will go.

What the first week of a rescue looks like

We keep the first week narrow. The goal is a passing build or a clear rebuild decision, not a long report.

  1. Day 1: confirm access to the repo, Apple account, backend and crash tools. Read every rejection message and reviewer note.
  2. Day 2: build the app from source on a clean machine. If that fails, it is the first finding.
  3. Days 3 to 4: reproduce the rejection on the reviewer's device class. Fix it, and run the full checklist above to catch the next rejection before Apple does.
  4. Day 5: resubmit with reviewer notes, or deliver a written fix-or-rebuild recommendation with a cost range.

FAQ

How long does App Store review take after I resubmit?

Apple says most submissions are reviewed within 24 hours. Resubmissions follow the same queue, though first-time apps and complex apps can take longer. An expedited review can shorten this for genuine critical fixes.

Can I appeal an App Store rejection?

Yes. You can submit an appeal to the App Review Board through Apple's developer site. Appeals work best when the reviewer clearly misunderstood a feature and you can show it with steps or a video.

Why was my app rejected for minimum functionality?

Guideline 4.2 targets apps that offer little beyond a website or a single simple feature. Adding native features usually helps, such as offline access, push notifications or device integrations. So does a clear reason someone would install the app instead of using the web.