Handling App Store Rejections

Getting rejected is normal. Most first-time submissions get rejected at least once. It’s not a permanent block — it’s feedback. Here’s how to read the rejection, fix the issue, and get approved.

Reading the rejection

App Store (Apple)

When Apple rejects your app, you’ll receive an email. The detailed rejection reason is in App Store Connect:

1. Go to App Store Connect → your app → the version that was rejected

2. Read the Resolution Center message

   Apple tells you exactly which guideline was violated. The message usually includes:

   • The specific guideline number (e.g., “Guideline 2.1 — App Completeness”)
   • A description of the issue they found
   • Sometimes a screenshot of the problem

3. Reply if you need clarification

   You can respond directly in the Resolution Center if the rejection is unclear. Apple’s reviewers will reply — usually within 1-2 business days.

Google Play

Google sends an email with the policy violation. You can also see details in the Google Play Console:

1. Go to Google Play Console → your app → check the notification banner or the “Policy status” section

2. Read the policy violation details

   Google identifies which policy was violated and usually includes a brief explanation.

3. Check the linked policy page

   The notice links to the specific policy documentation. Read it to understand what’s required.

Common rejections and how to fix them

Broken functionality / app crashes

What the reviewer saw: The app crashed, froze, or had a feature that didn’t work during their testing.

How to fix:

1. Test your app on a real device — not just the web preview. See Testing on Real Devices
2. Try to reproduce the exact scenario described in the rejection
3. Fix the issue in Primio by describing the crash: “The app crashes when I tap the Save button on the profile screen. Fix this crash.”
4. Rebuild and test again on a real device before resubmitting

Missing privacy policy

What the reviewer saw: The privacy policy URL is missing, broken, or returns a 404.

How to fix:

1. Check your privacy policy URL in an incognito browser window — does it load?
2. If the URL is broken, re-host the policy or fix the link
3. Update the URL in App Store Connect or Google Play Console
4. Make sure the policy is also accessible from inside the app (Settings → Privacy Policy)
5. See Privacy Policy & Legal for the full setup guide

Placeholder or test content (Apple)

What the reviewer saw: “Lorem ipsum” text, test data, “coming soon” labels, placeholder images, or other temporary content.

How to fix:

1. Open your app on a real device and go through every screen
2. Look for: default placeholder text, test images, “TODO” or “coming soon” labels, template content from Primio that wasn’t customized
3. Tell Primio to replace placeholders: “Replace all placeholder text and dummy data with real content. Remove any ‘coming soon’ or ‘TODO’ labels.”
4. Rebuild and verify every screen has real content

Missing demo credentials (Apple)

What the reviewer saw: The app requires login, but the reviewer couldn’t sign in to test features.

How to fix:

1. Create a test account in your app that works reliably
2. In App Store Connect, go to your app version → “App Review Information” → “Sign-In Information”
3. Check “Sign-in required” and enter the test account credentials
4. Verify the credentials work by signing out and signing back in yourself

Caution

Make sure the test account has access to all features. If certain features are behind a paywall, the test account should have those unlocked. Apple needs to test everything.

Guideline 4.2 — Minimum Functionality (Apple)

What the reviewer saw: The app is too simple — it doesn’t provide enough functionality beyond what a website could offer.

Common triggers:

• Single-screen apps with minimal interaction
• Apps that are essentially a website in a wrapper
• Very basic utilities with no unique value
• Apps with only static content (just text or images, no interactivity)

How to fix:

1. Add more screens and meaningful features. Aim for at least 3-4 screens with real user interaction.
2. Add features that justify being a native app: data persistence, offline capability, push notifications, device-specific features
3. Ask Primio to expand: “Add [specific features] to make the app more complete. It needs more screens and user interaction.”
4. Rebuild and test

Note

This is one of the harder rejections because it’s subjective. If you genuinely believe your app provides enough value, you can appeal in the Resolution Center and explain your use case. But usually, adding more features is faster than arguing.

Misleading metadata (both stores)

What the reviewer saw: The app description, screenshots, or name don’t match what the app actually does.

How to fix:

1. Re-read your store listing alongside the actual app
2. Remove any features from the description that aren’t implemented yet
3. Update screenshots to show the current app (not an earlier or planned version)
4. Don’t claim features your app doesn’t have
5. Don’t use competitor names or trademarked terms in your metadata

Data Safety / App Privacy incomplete (both stores)

What the reviewer saw: The data declarations don’t match the app’s actual behavior. For example, the app uses Firebase Analytics but the Data Safety form says it collects no data.

How to fix:

1. Review what SDKs and services your app uses (Firebase Auth, Analytics, AdMob, Supabase, etc.)
2. Update your declarations to accurately reflect all data collection
3. See Data Safety walkthrough and App Privacy walkthrough

Content policy violations (Google Play)

What the reviewer saw: The app violates Google’s content policies — this could be anything from inappropriate content to undeclared permissions.

How to fix:

1. Read the specific policy cited in the rejection
2. Common issues: requesting unnecessary permissions, missing content warnings, not having an age-appropriate rating
3. If permissions are the issue, ask Primio to remove unnecessary permission requests: “Remove the camera permission — the app doesn’t use the camera.”
4. Update your content rating if needed

The fix-and-resubmit workflow

1. Read the rejection carefully

   Understand exactly what the issue is. If it’s unclear, ask for clarification (Apple Resolution Center) or re-read the linked policy (Google).

2. Fix the issue in Primio

   Describe the problem to Primio and ask it to fix the underlying issue.

3. Rebuild

   Build a new APK/AAB (Android) or IPA (iOS). Each new build gets an incremented version number automatically.

4. Test on a real device

   Verify the fix works on an actual phone. Don’t skip this step — it’s how you avoid a second rejection.

5. Upload the new build

   Upload the new AAB to Google Play Console, or the new IPA via Transporter.

6. Resubmit

   Submit the new build for review. Re-review is usually faster than the first review — often 24 hours or less.

When to appeal vs. when to fix

Fix and resubmit (recommended in most cases):

• The rejection identifies a legitimate issue
• You can fix it in less time than arguing about it
• The guidelines are clear about what’s required

Appeal (only when warranted):

• You believe the reviewer made a mistake (e.g., they missed a feature that is in the app)
• The rejection cites a guideline that doesn’t apply to your app
• You can clearly articulate why your app complies with the guideline

To appeal on Apple, reply in the Resolution Center with a clear, respectful explanation. To appeal on Google, use the appeal form linked in the rejection email.

Tip

Be respectful and specific in appeals. “I disagree with the rejection” won’t get you anywhere. Instead: “The reviewer mentioned Feature X is missing, but it’s accessible from the Settings tab → Advanced → Feature X. I’ve attached a screenshot showing the feature in action.”

How long does re-review take?

Platform	First review	Re-review after rejection
Apple App Store	24-48 hours (sometimes longer)	Usually 24 hours or less
Google Play	Hours to days (up to 7 days for first apps)	Usually 1-3 days

Re-reviews are generally faster because the reviewer has context from the first review. They focus on whether the specific issue was fixed rather than doing a full review from scratch.

Next steps

• Pre-Submission Checklist — Catch issues before they cause a rejection
• Testing on Real Devices — The best way to prevent crash-related rejections
• Google Play Submission Guide
• App Store Submission Guide