How to appeal to App Store review after App Store rejection
If your iOS app is rejected, only appeal if you believe the reviewer misunderstood your app or misapplied guidelines. Submit your appeal through App Store Connect with clear, factual evidence referencing the specific guideline. Avoid emotional language, keep it concise, and attach any supporting documents like screenshots or licenses. If the rejection is due to clear issues like crashes or missing policies, fix and resubmit instead. Monitor responses carefully, and stop appealing if repeated attempts fail. Then, focus on making necessary changes before resubmitting.
Your iOS app got rejected. Now you need to decide: appeal or fix and resubmit?
This guide walks you through the entire appeal process in App Store Connect, from understanding your rejection message to writing an effective appeal that the App Review Board will actually consider.
Enter any URL to build an iOS app now
How to tell if your App Store rejection can be appealed
Not every app rejection should be appealed. Some issues require a fix and resubmission. Before appealing, confirm your case has merit.
Appeal makes sense when: The reviewer misunderstood your app’s concept, misapplied a guideline to your app functionality, or ignored evidence you already provided in review notes. These are legitimate disputes where the app complies with the cited rule.
Do not appeal when: Your app has a clear crash, broken login, missing privacy policy, placeholder content, broken links, or an obviously unfinished build. If there’s a clear guideline violation, fix it instead of arguing.
Compare rejection to guidelines: Open the rejection email in App Store Connect and cross-reference it against the current App Store Review Guidelines (check the revision date—latest updates were in November 2025). If the guideline clearly prohibits what your app does, an appeal will fail.
Appeals are slower than fixes: The App Review Board handles appeals, and processing takes longer than a standard review process. Use appeals only for genuine disputes, not as a delay tactic when you should be building apps that actually comply.
You get only one appeal per submission: Apple limits you to only one appeal per rejected build. Make it count by gathering evidence before submitting.
Tip: Apps should not include placeholder content like 'Lorem Ipsum' or stock images, as this can lead to rejection.
How to submit an appeal in App Store Connect: A step-by-step process
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.
Understand why your app was rejected before appealing
Misreading the rejection message is the most common mistake developers make before appealing.
Read the full rejection message: Open the Resolution Center in App Store Connect. Look for the “Guideline X.X – Title” line and any text under “Next Steps.” This tells you exactly what Apple found wrong.
Identify rejection type: A “metadata rejection” means you can fix issues (app description, screenshots, app metadata) without uploading a new binary. A “binary rejection” requires uploading a new build with code changes.
Map guidelines to official documentation: Take each cited guideline (e.g., 2.1 App Completeness, 4.2 Minimum Functionality, 5.2.1 Intellectual Property) and find the relevant section in the official App Store Review Guidelines. Understand what Apple expects before you argue.
Check Apple’s attachments: Reviewers often attach screenshots or screen recordings showing exactly where your app appears to violate guidelines—paywall design issues, login failures, confusing user flows. Review these carefully.
Recreate the reviewer’s environment: Test on the same device class (e.g., iPhone 15 Pro), iOS version, language setting, and network state (Wi-Fi vs. cellular). Many rejections stem from issues developers couldn’t reproduce because they tested differently.
Want to learn more about our plugins?
Launch a full-feature native app without native development!
Common rejection types that often 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 attach business registration, incorporation documents, authorization letters, or franchise agreements proving 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.
Fact: Apps that do not include a privacy policy will be rejected.
How to write an effective appeal message
Open your appeal by clearly restating the rejection using Apple’s own terminology. For example: “Our app was rejected under Guideline 4.2 – Minimum Functionality. The reviewer noted insufficient features for a standalone app.”
Follow a clear, review-friendly structure to keep your focused, factual, and easy for reviewers to assess quickly:
Begin with: a brief overview of your app, highlighting its main features and target audience.
Next: address the specific rejection reason, citing the exact guideline Apple referenced.
Then: back up your case with evidence such as screenshots, logs, test credentials, or an updated build that resolves the issue.
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.
Include detailed user journeys to guide the reviewer through your app’s functionality. For example: “From the home screen, tap ‘Courses’ → ‘Free Lessons’ to access fully functional content without a subscription. The health app features are available without in-app purchases.”
Maintain a neutral and professional tone throughout your appeal. Avoid emotional language such as “unfair,” “devastating,” or “frustrated.” Instead, use factual statements like “We believe the app complies with Guideline 4.2 because…” and provide specific supporting details relevant to app approval.
Keep your appeal concise, ideally between 400 and 600 words. Use short paragraphs and bullet points where appropriate to make your message easy to scan, as reviewers handle many appeals.
If you made any changes to the app after the rejection, clearly list them in your appeal. For example: “1. Added in-app account deletion per Guideline 5.1.1 requirements. 2. Moved privacy policy link to Settings → Legal. 3. Updated app review information with demo account credentials.”
Tip: Use clear, professional language and avoid emotional language or marketing fluff in appeals.
Timeline, follow-ups, and when to stop appealing
Set realistic expectations about response times and know when to change strategy.
Normal response times: Standard appeal responses often arrive within 24-72 hours on business days. App Review Board escalations can take up to a week or longer. Plan your release timeline accordingly.
Check notifications daily: Monitor App Store Connect notifications and your registered email. Do not submit multiple appeals unless Apple explicitly requests more information. Spamming appeals won’t help your app get approved.
Recognize when to stop: If Apple cites the same guideline twice without providing new detail, it’s a signal to change the app rather than keep arguing. The human review team has made their interpretation clear.
Parallel submissions are allowed: You can submit a new build while an appeal is in progress. Use the review notes field to explain how the new submission addresses the earlier rejection. This keeps your options open.
Keep an internal rejection log: Track date rejected, guideline cited, build number, changes made, appeal date, and outcome. This prevents your team from cycling through the same mistakes on new apps or apps submitted later.
Two strikes, redesign: If two appeals on the same issue both fail, treat Apple’s guideline interpretation as final. Redesign the feature or flow to comply rather than continuing to dispute.
Tip: Apps must not use private APIs, as this can lead to rejection during the review process.
Examples of guideline-specific appeals
These anonymized patterns show 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 the guidelines regarding video streaming and audio content were followed, with 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 stand alone apps built on templates.
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.
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.
4.0 Apple Login design guidelines rejection
An app was rejected because it did not 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 being approved upon reconsideration.
Note: The examples and cases discussed above are illustrative scenarios based on common types of app rejections and appeals. They are not specific real-world cases but are designed to help you understand how to approach similar situations effectively.
Where to research past rejections and clarify vague responses
Apple’s rejection message can be brief. External resources help decode ambiguous responses.
Apple Developer Forums and Stack Overflow: Search these platforms for developers sharing rejection texts and successful appeal patterns. Many include the exact wording they used to get their app approved.
Search by guideline number: Use queries like “Guideline 4.2 rejection appeal” combined with a short phrase from your rejection message. Focus on posts from 2022-2025 for relevant examples.
Ask precise questions: When posting your own question, copy the rejection text (removing private info like app name) and ask specific questions: “What concrete changes resolved a 4.2 Minimum Functionality rejection for a content aggregator?”
Cross-check with current guidelines: Apple’s interpretation evolves. Anything older than 2-3 years may reference outdated rules. Always verify against the current guideline revision date on developer.apple.com. The review status of guidance changes, so what worked in 2022 may not apply to medical apps or new apps in 2025.
Consider Google Play comparisons: If you also publish your app on Google Play, note that Google Play Console handles rejections with a different approach—often providing more direct messaging and faster resubmission cycles. Apple’s process, on the other hand, may involve more formal documentation and structured appeals. Both platforms have their own procedures and requirements for addressing app rejections.
Resubmitting after a failed appeal: Process checklist
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.
Note: If you believe the rejection was based on a misunderstanding, you can escalate your appeal to the App Review Board.
Summary
The app review process may seem complex, but most rejections have specific, fixable reasons.
Before appealing, critically evaluate if your app truly violates the cited guideline. If it does, fix the problem immediately—don’t waste time appealing.
If you believe the rejection was in error, compile clear, factual evidence and submit a single, well-prepared appeal.
Keep a detailed rejection log to avoid repeating mistakes. Remember, if two appeals on the same issue fail, stop arguing and redesign your app to comply with the guidelines.
Want to know how it all works?
Get hands-on with Median’s comprehensive documentation, and build your app with ease.
Frequently asked questions
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 lead to rejection under the App Store Review Guidelines. To increase approval chances, consider using a platform like Median.co that offers a native plugins library to add valuable features beyond your website content, ensuring your app provides a richer, more engaging user experience.
How do I get my UDID to assist with App Store review or testing?
Your UDID (Unique Device Identifier) 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.co 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.
How long does it take to get a response after submitting an appeal to the App Review Board?
Typically, Apple responds to appeals within 24 to 72 hours on business days. However, more complex cases or escalations to senior reviewers can take up to a week or longer. It's important to monitor your App Store Connect notifications and email regularly during this period for updates.
What types of evidence should I include when appealing an App Store rejection?
When appealing, include clear and relevant evidence such as screenshots demonstrating app functionality, demo videos showing user flows, licenses or permissions proving content ownership, and detailed explanations referencing specific App Store Review Guidelines. Providing thorough, factual documentation improves your chances of a successful appeal.
to top
Related articles
