Common App Store rejection reasons and when to appeal them

Apple rejects roughly 1 in 4 app submissions. Most rejections come down to a handful of repeat issues, such as a crash or broken flow, a missing privacy policy, unlicensed content, an app that reads as too thin to stand on its own, or a paywall that isn't clear about what it charges. This guide walks through the most common reasons, how to find the exact one behind your own rejection, how to fix it, and when an appeal makes more sense than a fix.

More than 1.7 million apps have been built on the Median platform, and Median boasts a 98% app store approval rate. The patterns described below come from watching many submissions go through Apple's review process, not from guesswork.

TRY IT FOR FREE

Enter any URL to build an iOS app now

Build now

How often does Apple reject App Store submissions

Apple reviewed 7.77 million app submissions in 2024 and rejected 1.93 million of them, close to 1 in 4, according to its own App Store Transparency Report. Of the rejected apps, 295,109 were approved once the developer fixed the issue and resubmitted them.

Performance problems, meaning crashes, broken flows, and incomplete builds, were the single biggest cause, accounting for more than 1.2 million rejections on their own. Legal issues, design problems, business model violations, and safety concerns rounded out the top five, in that order.

Tip: A rejection honestly isn't that rare, and it isn't usually a sign your app has a fundamental problem. Most rejected apps get approved on the next submission once the specific issue is fixed.

Common App Store rejection reasons

1. Performance and app completeness (Guideline 2.1). This is the largest category by a wide margin. Crashes, dead-end flows, placeholder content, and builds pointed at dev or staging instead of production all trigger it.

2. Privacy and account deletion (Guideline 5.1.1). A missing or broken privacy policy link is an automatic rejection, no matter what else is right about the app. Apple also expects a clear in-app path to delete an account, not just a support email address to request it.

3. Intellectual property and content rights (Guideline 5.2.1, 5.2.3). Apps that let users access or download content they didn't create must show they have the rights to do so. This shows up most often with video streaming apps, reader apps, and anything that includes licensed audio or video.

4. Minimum functionality and template apps (Guideline 4.2, 4.2.6, 2.1). Apple rejects apps that read as too thin, a plain website wrapped in a shell with nothing native added. Template or white-label apps have an extra requirement. The developer account must belong to the business itself, not to the platform or agency that built it.

5. Design, metadata, and paywall clarity (Guideline 4.0, 3.1.2). Misleading subscription pricing, a Sign in with Apple button that doesn't meet the size and placement spec, or app metadata that doesn't match what the app does all fall here.

Tip: Apple's Info.plist errors show up as specific ITMS codes rather than guideline numbers. ITMS-90683, for example, means a required usage description, like NSPhotoLibraryUsageDescription, is missing from your app's configuration.

How to find the exact reason your app was rejected

The category is your starting point, but the Resolution Center in App Store Connect has the specific reason.

Open the Resolution Center and look for the line that starts with "Guideline X.X" followed by a title, plus anything under "Next Steps." Good news, that's the exact issue, not a general category!

Check whether it's a metadata rejection or a binary rejection. A metadata rejection means you can fix it in your app description, screenshots, or other listing details without touching the build. A binary rejection means you need new code and a new build.

Look closely at any screenshots or screen recordings the reviewer attached. These usually show exactly where the app runs into trouble, whether that's a paywall, a login failure, or a confusing flow.

If you're not sure your test conditions match the reviewer's, try to recreate them using the same device class, iOS version, language setting, and network type. A lot of rejections come down to something the developer couldn't reproduce because they tested under different conditions.

How to avoid App Store rejection before you submit

Here's how to catch most of the common issues before Apple does:

• Replace all placeholder content and stock images with the real thing. Apple flags "Lorem Ipsum" text and stock photos as a rejection reason on their own.

• Confirm that your privacy policy URL is live and accessible from both the app and the App Store listing, and that it actually describes what your app collects.

• Add an in-app account deletion flow if your app has accounts. A support email isn't enough anymore.

• Test on the same device class and iOS version a reviewer would use, not just your own phone.

• If your app is a website wrapped in a webview with nothing native added, expect a Guideline 4.2 or 2.1 rejection. Adding real native functionality, such as push notifications, biometrics, or offline access, is what moves an app from "thin wrapper" to "standalone app" in a reviewer's eyes.

Median's free publishing guide is built around avoiding this exact list of rejection reasons and more. Get your free guide.

How to fix a rejected app and resubmit

List the exact changes you're making before you touch Xcode. For example: "Added an account deletion flow, replaced placeholder content with production data, removed external links to payment pages, and added a way to block abusive users or report content."

Run regression testing across current iOS versions and device sizes. Use TestFlight with reviewer-style demo credentials and confirm that push notifications, demo mode, and account creation still work.

Turn the rejection into a checklist inside your review notes. For example: "Per Guideline 5.1.1, added account deletion at Settings, Account, Delete. Per Guideline 2.3, removed inaccurate data and placeholder content."

Update the build number and version in Xcode and App Store Connect before uploading. Apple tracks submissions by build number, so the new one needs to be distinct from the rejected one.

Keep your review notes short and specific. Include a demo account if your app requires login to review, and confirm any user-generated content has moderation in place.

When to appeal an App Store rejection instead of fixing it

Appealing only makes sense in a narrower set of cases, for example, the reviewer misunderstood your app's concept, misapplied a guideline to what your app actually does, or ignored evidence you already gave them in your review notes. If the rejection points to a real issue, such as a crash, a missing privacy policy, or placeholder content, fixing it is faster than appealing it.

You get one appeal per rejected build, through App Store Connect's Resolution Center or Apple's direct appeal form. In the form, state the guideline number, explain in factual terms why you believe your app complies, and attach evidence, screenshots, licenses, a demo video, whatever backs up your case. Skip the emotional language.

The evidence Apple actually wants varies by guideline. IP rejections need license agreements or ownership documents. Template app rejections need business registration and proof the developer account belongs to the business, not the platform vendor. Minimum functionality rejections need a demo video showing real content and working flows across platforms. You get the idea.

Appeals typically get a response in 24 to 72 hours, though escalations to the App Review Board can take a week or more. If Apple cites the same guideline twice without new detail, that's a sign to change the app rather than appeal again.

Common rejection types that require evidence in an appeal

Different guideline violations require different types of evidence. Here’s what to prepare for appealable rejections:

• Guideline 5.2.1 / 5.2.3 (Intellectual Property, Audio/Video Downloading): Apple demands proof you have rights to content. Prepare license agreements, broadcast licenses, written permission from rights holders, or ownership documents in PDF format. This applies to video streaming apps, reader apps, and any app that lets users access content they didn’t create.

• Guideline 4.2.6 / 5.2.1 (Template-Based Apps): Apple expects the business owner to hold the developer account for white-label or template apps. Your appeal should include business registration, incorporation documents, authorization letters, or franchise agreements that prove the entity owns the Apple Developer Program membership.

• Guideline 4.1 (Copycats): If accused of copying other apps, your appeal must highlight unique features, original design decisions, and differentiators. Include a feature comparison (written, not visual) showing how your app differs from what Apple thinks you copied.

• Guideline 4.2 (Minimum Functionality) / 2.1 (App Completeness): Apple reject apps that lack features. A demo video showing real content, functional flows, and the same app working across multiple platforms often convinces reviewers. Show that your app works as intended.

• Guideline 5.1.1 (Privacy) / Account Deletion Requirement: For privacy and account deletion rejections, specify the exact navigation path (e.g., Settings → Profile → Delete Account). Attach updated screenshots showing the app’s privacy policy link and account deletion flow. Ensure your app’s privacy policy URL is valid and accessible.

Examples of guideline-specific appeals

If you still need more help, these anonymized patterns provide more details on how developers successfully appealed specific guideline rejections:

5.2.3 Audio/video downloading rejection

A podcast app was rejected because Apple believed it enabled unauthorized downloading of copyrighted audio.

The developer attached broadcast licenses dated 2024 from each content partner, explained the server-side DRM enforcement that prevents offline redistribution, and clarified that downloaded episodes are tied to authenticated accounts.

The appeal emphasized that all guidelines regarding video streaming and audio content were followed, and that the service published contact information for rights verification.

4.2.6 Template-based app rejection

A restaurant chain submitted a branded ordering app built on a white-label platform. Apple rejected it, citing that template apps must be submitted under the content owner’s account.

The appeal included the franchise’s business registration, a signed authorization letter from the platform provider, and proof that the Apple Developer Program membership belonged to the restaurant entity — not the template vendor.

This clarified that the submission followed all requirements for free standalone apps built on templates.

4.0 Apple Login design guidelines rejection

An app was rejected because it didn't comply with Apple’s Human Interface Guidelines for Apple Login integration.

The App Review team noted that the Apple Sign-In button was improperly sized, placed inconsistently with other UI elements, and lacked the required “Sign in with Apple” text as specified in the guidelines.

The developer responded by updating the UI to use Apple’s official button assets, ensuring the button met minimum size requirements (44x44 points), was positioned prominently on the login screen, and included the correct label and accessibility tags.

Screenshots of the updated login screen and a video demonstrating the sign-in flow were attached to the appeal. The clear reference to the Human Interface Guidelines and the demonstration of compliance led to the app's approval upon reconsideration.

3.1.2 Subscription paywall design rejection

An app was rejected because the subscription price display was deemed misleading.

The developer enlarged the price font, clarified the billing period (“$4.99/month, auto-renewing, cancel anytime”), and added explicit terms below the subscribe button.

The appeal included before/after screenshots and referenced the specific Human Interface Guidelines section on purchase methods and in-app purchases transparency.

5.1.1 Privacy policy rejection

A companion app was rejected for having no accessible privacy policy.

The developer added a working URL in App Store Connect metadata, placed a visible in-app link under Settings → Legal → Privacy Policy, and ensured the policy addressed how the app would access user data.

The appeal included screenshots showing the navigation path and confirmed the policy covered user-generated content handling and data retention for apps submitted to the kids category or that interact with children online.

The examples and cases discussed above are illustrative scenarios based on common types of app rejections and appeals. They're not specific real-world cases but are designed to help you understand how to approach similar situations effectively.

For more examples, search Apple Developer Forums and Stack Overflow for developers who share rejection texts and successful appeal patterns. Many include the exact wording they used to get their app approved.

How to submit an appeal in App Store Connect: A step-by-step guide

Step 1: Log in to App Store Connect. Go to https://appstoreconnect.apple.com and sign in with the Apple ID that owns the developer account. If you’re part of a team, ensure you have the Admin or App Manager role.

Step 2: Navigate to your rejected app. Click “My Apps,” select the rejected app by app name, then open the “Activity” tab or look for the Resolution Center section to see the exact rejection record with the guideline citation.

Step 3: Find the appeal option. In the rejection details, look for “Contact Us,” “Submit an Appeal,” or “Reply to App Review.” Alternatively, use Apple’s direct appeal form at: https://developer.apple.com/contact/request/app-review/appeal/.

Step 4: Fill required fields. Specify the app, platform (iOS, iPadOS, macOS), your Apple ID and team, App Store region(s), and the specific guideline number cited in the rejection (e.g., Guideline 4.2, 5.2.3, 2.1).

Step 5: Draft your appeal message. Paste the original rejection message into a local text editor. Write a concise appeal that references the exact guideline number and paragraph. Be specific about why you believe your app complies.

Step 6: Attach supporting evidence. Include PDF licenses, screenshots of working features, short .mp4 demo video files, contracts proving content or brand ownership, or any other documentation that supports your case.

Step 7: Keep the tone factual. Avoid emotional language. End with one explicit request: “Please reconsider this rejection under Guideline 4.2.”

💡 Did you know? Developers can request an App Review Appointment to discuss the results via Webex if written communication fails.

Appeal message tips

Follow a clear, review-friendly structure to keep your focused, factual, and easy for reviewers to assess quickly

1. Begin with a brief overview of your app, highlighting its main features and target audience.

2. Next, address the specific rejection reason, citing the exact guideline Apple referenced.

3. Then, back up your case with evidence such as screenshots, logs, test credentials, or an updated build that resolves the issue.

4. Conclude with: a straightforward request for reconsideration and clarity on any next steps. This approach keeps your appeal focused, factual, and easy for reviewers to assess quickly

Resubmitting after a failed appeal

Sometimes the fastest path forward is implementing Apple’s feedback and submitting a new build rather than continuing to appeal.

• Document exact changes: List the concrete modifications addressing the rejection. Example: “1. Added account deletion flow, 2. Replaced placeholder content with production data, 3. Removed external links to payment pages, 4. Added mechanism to block abusive users and report offensive content.”

• Test thoroughly: Perform regression testing on current iOS versions and device sizes. Use TestFlight with reviewer-style demo account credentials. Verify that push notifications, demo mode, and account creation flows all work.

• Map changes to guidelines in review notes: Turn Apple’s rejection message into a checklist. In the Notes for Review field, briefly state: “Per Guideline 5.1.1 feedback: Added account deletion at Settings → Account → Delete. Per Guideline 2.3: Removed all inaccurate data and ensured no placeholder content remains.”

• Increment build and version correctly: Update the build number and version in Xcode and App Store Connect before uploading. Apple tracks submissions by build number, so ensure it’s distinct from rejected builds.

• Keep explanations brief: Use short bullet-style sentences in review notes. Avoid narrative explanations — just make the reviewer’s job obvious. Include a demo account if your app requires login to pass review. Confirm the app supports filtering objectionable material if it hosts user-generated content.

• Test on multiple devices: Ensure user safety flows work across iPhone and iPad. Verify that the app appears correctly regardless of device orientation or accessibility settings.

If you believe the rejection was based on a misunderstanding, you can escalate your appeal to the App Review Board.

Instant app store facelift. No designer required.

Unlock Median’s 500+ free Figma app store screenshot templates designed to meet iOS and Android guidelines. Your app will look its best across platforms, resulting in more downloads and a more powerful app store presence.

Choose your design now

How Median helps you avoid the most common App Store rejections

Median turns your existing website into a native iOS and Android app without the cost or timeline of building one from scratch. That includes the parts of the App Store submission that trip developers up most, meeting Apple's completeness and functionality bar and adding native features beyond a plain webview so your app doesn't read as too thin to reviewers.

If your rejection came from Guideline 4.2 or 2.1 because your app looks like a wrapper around your site, Median's plugin library adds real native functionality (e.g., push notifications, biometrics, offline access, etc.) so your next submission clears that bar without a custom build.

Frequently asked questions about App Store rejections

Can I convert my website to an app to avoid App Store rejection issues?

Yes, converting your website to an app using a webview app approach is a popular app development method. However, simply wrapping your website in a webview without adding unique native app functionality may still lead to rejection under the App Store Review Guidelines. To increase approval chances, consider using a platform such as Median.co that offers a native plugins library to add valuable features beyond your website content, ensuring your app provides a richer, more engaging, an app-like, user experience.

How do I get my UDID to assist with App Store review or testing?

Your Unique Device Identifier (UDID) is a unique code for your iOS device used for testing apps on physical devices before submission. You can get your UDID by connecting your device to a computer and using tools like Finder on macOS or iTunes on Windows. Additionally, Median offers a convenient UDID retrieval tool to help you easily find your device's UDID. Providing your UDID to testers or developers helps them install your app directly for review or debugging purposes.

Who can fix my App Store rejection?

It depends on the reason. Config-level issues, such as a missing privacy policy link or an account deletion flow, are usually a fast in-house fix. Rejections tied to Guideline 4.2 or 2.1, where the app reads as too thin or too close to a plain webview, require adding real native functionality, which is what a platform like Median or a mobile developer handles.

How can I avoid App Store rejection?

To avoid App Store rejection, test on the same device and iOS version that a reviewer would use, remove all placeholder content, keep your privacy policy live and accessible, add in-app account deletion, and ensure your app has real native functionality rather than reading like a wrapper around a website. Median's free publishing guide walks through this exact checklist in more detail.

What does an ITMS error code mean?

ITMS codes indicate a specific configuration issue, usually something missing from your app's Info.plist, such as a required usage description. ITMS-90683, for example, means a usage description like NSPhotoLibraryUsageDescription wasn't included.

How long does an App Store appeal take?

Most appeals get a response to their App Store appeal within 24 to 72 hours on business days. Escalations to the App Review Board can take a week or longer, so check App Store Connect notifications and your registered email regularly during that window.

What evidence should I include in an App Store rejection appeal?

Screenshots showing your app's functionality, demo videos of real user flows, licenses or permissions proving content ownership, and a clear explanation tied to the exact guideline Apple cited are usual best practices. Specific, factual documentation is what moves an appeal forward.