How to Get Your App Approved on the App Store (Without the Rejections)

App Store rejection is a rite of passage for most first-time app launchers. It's also largely preventable. Apple's review process is not random or arbitrary — it follows documented guidelines. The problem is that most development teams treat the App Store Review Guidelines as something to worry about after the build is done, rather than a constraint that should shape the build from the start.

Here's how the process actually works, what gets apps rejected, and how to submit with confidence.

How Apple's Review Process Works

When you submit an app to App Store Connect, it enters a queue for human review. Apple does not use automated-only review — actual people download and test your app. This is important: they follow flows, tap on buttons, try to break things. If something doesn't work or doesn't make sense, they'll flag it.

Timeline: First-time submissions typically receive a decision within 1–3 business days. In practice, most apps see a response within 24–48 hours, though this varies during high-volume periods like holidays or just after major iOS releases. Resubmissions after a rejection can take another 1–3 business days, which is why a single rejection can add 5–7 days to your launch timeline.

App Review vs App Store Connect: There are two separate hurdles. App Review checks your binary and behavior. App Store Connect checks your metadata — screenshots, description, age rating, privacy policy URL, support URL, privacy nutrition labels. Both need to pass. Metadata issues are often caught before the binary review and can be resolved without a full resubmission.

Expedited review: Apple offers expedited review in cases of critical bug fixes affecting existing users or time-sensitive events. Expedites for initial app submission are rarely granted. Do not count on it for your launch.

The 8 Most Common Rejection Reasons

These are the actual categories that catch most first-time submissions. Knowing them before you build is how you avoid them.

1. Broken or incomplete functionality

If a reviewer encounters a crash, a broken flow, a non-functional button, or a feature that returns an error, your app gets rejected under Guideline 2.1 (App Completeness). This sounds obvious, but it's the most common rejection reason. Reviewers have limited time. They are not going to retry something that doesn't work the first time. Thorough QA on real devices — not simulators — before submission is non-negotiable.

2. Subscription terms not clearly disclosed

If your app offers a paid subscription, Apple requires that the subscription terms (price, duration, auto-renewal) be clearly displayed immediately before the purchase action. Burying this in a Terms of Service page or a small footnote is not enough. The disclosure must be "clearly viewable prior to purchase" per Guideline 3.1.2. We have seen apps rejected for having the disclosure text too small.

3. Login required without a demo account

Apps that require users to create an account before reviewers can evaluate functionality will be rejected (Guideline 5.1.1) unless account creation is the core purpose of the app (e.g., banking, healthcare, social networks). If your app has a login wall, you must provide demo account credentials in the App Review Notes field of App Store Connect.

4. Privacy manifest missing or incomplete

Since iOS 17.2, Apple requires a privacy manifest file (PrivacyInfo.xcprivacy) that declares all required reasons for using certain APIs — File Timestamp, System Boot Time, Disk Space, Active Keyboards, User Defaults. Many popular SDKs also require their own privacy manifests. If your app or any dependency uses these APIs without the required declarations, your submission will be rejected. React Native with Expo handles most of this automatically, but you still need to audit.

5. Use of private or restricted APIs

Using APIs that are not part of Apple's public SDK will get your binary rejected outright. This also includes accessing device hardware in ways that aren't documented — it's not just about calling private Objective-C methods.

6. Guideline 4.0 — Design: poor user experience

Apple can reject apps that they determine have significant UX issues — confusing navigation, interface elements that don't behave as expected, non-standard controls that confuse users. This is subjective, but it's invoked for apps that clearly haven't been designed with care. Apps that are essentially web views wrapped in a container shell are also commonly flagged here.

7. In-app purchase required for features that shouldn't require it

Apple expects that apps with meaningful free functionality have that functionality accessible without a purchase. If your app is essentially empty without a subscription, Apple may require that you offer some value first. Paywalling everything on the first screen is a rejection risk.

8. Inaccurate metadata or misleading screenshots

Your screenshots and App Preview videos must accurately represent the app's current state. Screenshots from mockups that look nothing like the actual UI, or that show features not yet implemented, will be flagged. Your app description must not reference features of other platforms or include placeholder text.

What to Do When You Get Rejected

First: don't panic. A rejection is not a ban. It's specific feedback on a specific issue.

Read the rejection notice carefully. Apple provides a rejection reason with a guideline reference. Look up that specific guideline. The rejection notice often includes a screenshot or a description of what the reviewer found.

Respond via the Resolution Center in App Store Connect. You can communicate directly with the reviewer to ask for clarification or to explain your intent. If you believe the rejection is in error, this is where you make that case — politely and specifically.

Fix the issue, then resubmit. Address only the stated rejection reason. Changing other parts of your app during a resubmission can surface new issues, so keep the delta minimal.

If you feel the rejection is incorrect and the reviewer isn't budging, you can file an appeal with the App Review Board. Appeals take longer but are occasionally successful, especially for edge cases where guidelines are ambiguous.

Google Play: Faster, But Not Easier

Google Play's automated review system typically processes submissions faster — sometimes within hours. But Google's policies have tightened considerably over the past few years.

The main differences:

• Data safety section is Google's equivalent of Apple's privacy nutrition labels. Incomplete or inaccurate declarations will get your app removed.
• Target API level requirements — Google enforces minimum target API levels aggressively. Apps that don't target a recent enough Android SDK version are removed from the Play Store.
• Policy enforcement is less predictable. Google's automated systems sometimes flag apps incorrectly, and their appeals process is slower and less responsive than Apple's.

For most apps, Google Play initial submission is faster and smoother than Apple's — but don't treat it as a sure thing.

Preparing for Submission

Metadata prep (do this first):

• App name, subtitle, and keywords locked down
• App description written (no keyword stuffing — Apple flags this)
• Screenshots for every required device size (6.5" and 6.7" iPhone are required; others can be inherited)
• Privacy policy URL live on a public URL
• Support URL live and functional
• Age rating questionnaire completed accurately
• Privacy nutrition labels completed for every data type your app collects

Before you submit the binary:

• Test on real devices across the device range you intend to support
• Provide demo account credentials in App Review Notes
• Include any special configuration Apple needs to reach your backend (e.g., if your API is behind a VPN or has IP restrictions)
• Review the current version of the App Store Review Guidelines — they update regularly

Build Review Risk Assessment Into Your Planning

The best time to assess App Store risk is before you write a single line of code. If your app involves subscriptions, user-generated content, health data, financial transactions, or any category Apple scrutinizes heavily, a review risk assessment during the discovery phase identifies these issues when they're cheap to fix — not after your engineering team has built around a problematic pattern. The cost of addressing these issues late can easily exceed the cost of discovery itself.

Our technical discovery engagement includes an App Store risk assessment for exactly this reason. If you're uncertain about how your concept will be received by App Review, talk to us before you build.

See our mobile app development service.

For a full overview of the mobile development process from start to finish, see our complete mobile app development guide.