16 Reasons Apple Could Reject Your App (And How to Avoid Them)

One of the worst things that can happen, after days, weeks, or months of development effort, is to find out the app store won't publish your app.

It's not necessarily the end of the road - but it's a very real speedbump. We've seen this over the years, through 13 years of building mobile apps and over 2,000 app store submissions successfully navigated.

Apple may reject an app if it's incomplete, unstable, misleading, unsafe, too limited, or doesn't follow its business, design, privacy, or legal rules.

Many rejections are preventable. Before submitting, check that the app works on supported devices, the reviewer can access every important feature, the listing accurately represents the experience, and your payments, privacy disclosures, permissions, and account flows follow the current rules.

Apple organizes its App Review Guidelines into five areas: Safety, Performance, Business, Design, and Legal. The guidelines are a living document, so use this article as a practical checklist, then confirm any rule that applies to your app against Apple’s current wording.

Here are 16 common reasons an app can be rejected.

1. The App Crashes or Contains Obvious Bugs

Apple expects a submission to be a finished product, ready for customers to download.

Crashes, frozen screens, broken navigation, failed purchases, missing content, and obvious visual errors can all trigger a rejection under Guideline 2.1 on app completeness.

Test the release build on real supported devices, not just a simulator. Cover fresh installs, updates, login, logout, account creation, purchases, deep links, notifications, poor network conditions, and any feature controlled by your backend.

Also test the exact build you submit. Just because the staging build works doesn't mean the App Store build will.

2. The Submission Is Incomplete

Placeholder content, empty pages, demo products, unfinished screens, temporary URLs, and “coming soon” core features make the app look unready.

Apple says App Review submissions should be final, with complete metadata and functional URLs. Beta and trial distributions belong in TestFlight, not in a public App Store submission.

Before submitting, remove placeholder copy, test data, inactive buttons, and temporary assets. If a feature isn't ready, take it out of the release instead of asking the reviewer to ignore it.

3. The Reviewer Cannot Access the App

An app can work for your team and still be impossible for Apple to review.

If the app requires an account, provide an active demo account or a fully featured demo mode. If it depends on hardware, location, a QR code, a subscription, or a specific setup, provide what the reviewer needs and explain it clearly in App Review notes.

Keep backend services running throughout review. Test the supplied credentials immediately before submission and check that two-factor authentication, one-time codes, or regional restrictions won't block access.

4. App Review Notes Are Missing Important Context

Non-obvious behavior needs an explanation.

Use the Notes for Review field to explain:

• Where the reviewer can find important features
• How to access paid or account-gated areas
• Why a permission is needed
• How external hardware or services work
• Any in-app purchase that is not immediately visible
• Significant changes in the submitted version

Avoid generic notes such as “bug fixes” when the build adds meaningful functionality. Apple asks developers to describe new features and product changes with specificity.

5. The Store Listing Is Inaccurate or Misleading

The app name, subtitle, description, screenshots, preview video, age rating, privacy information, and “What’s New” copy all need to match the current app.

You can run into problems when the listing:

• Promises a feature that is not available
• Shows an outdated or different interface
• Hides that featured content needs an additional purchase
• Uses an inaccurate price or promotional claim
• Selects an unrelated category
• Includes unsupported or unverifiable claims

Apple also requires screenshots to show the app in use rather than relying only on title art, a splash screen, or a login page.

6. Links, Support Details, or Contact Information Do Not Work

Broken links are a simple way to make a finished app look incomplete.

Check every in-app link and all App Store Connect URLs, including the support URL, marketing URL, privacy policy, terms, account-management pages, and any link used during authentication or checkout.

Your support information needs to give users and App Review a practical way to contact you. Keep the developer contact details in App Store Connect current as well.

7. Privacy Disclosures Do Not Match Data Collection

Apple requires a privacy policy link in App Store Connect and an easily accessible privacy policy within the app.

The policy, App Privacy answers, permission prompts, and the app’s real behavior need to agree. This includes data collected by analytics, advertising, authentication, payment, customer-support, and other third-party SDKs.

Map the data the app and its SDKs collect, why it's collected, whether it's linked to the user, and whether it's used for tracking. Don't copy privacy-label answers from another app or rely on an SDK vendor’s general statement without checking your configuration.

Apple holds the developer responsible for third-party code included in the app.

8. Permissions Are Unnecessary or Poorly Explained

Only request access to data or device capabilities that the app genuinely needs.

The purpose string should explain the user benefit in specific language. “We need your location” is weak; “Use your location to show stores that can deliver to your address” is clearer.

Ask when the permission becomes relevant, not immediately on launch without context. The app should still handle a “no” gracefully unless the permission is essential to the service.

Sensitive categories, including health, location, contacts, photos, camera, microphone, and tracking, deserve extra scrutiny.

9. Account Creation, Login, or Deletion Does Not Follow Apple’s Rules

If your app supports account creation, it generally needs to let users start the deletion process from within the app. Deactivation isn't the same as deletion.

Apps that use a third-party or social login as the primary account sign-in method may also need to offer an equivalent login option that meets Apple’s Guideline 4.8 requirements. There are exceptions, including some apps that exclusively use a company’s own account system or specific enterprise, education, or government arrangements.

Don't add Sign in with Apple just because you think Apple will like the app more. Follow the rule that matches the authentication methods you provide.

10. The Payment Flow Breaks App Store Rules

Payment rules depend on what is being sold, where the app is distributed, and which entitlement or exception applies.

The basic distinction is:

• Digital content, features, or subscriptions consumed in the app: Apple generally requires In-App Purchase, subject to current exceptions and storefront-specific rules.
• Physical goods or services consumed outside the app: Use another payment method, such as Apple Pay or card checkout. Ecommerce purchases fall into this category.

Don't assume a web checkout is allowed for digital access just because it works technically. And don't send ordinary retail purchases through In-App Purchase.

Because Apple’s external-link and alternative-payment rules vary by storefront and have changed significantly, check the current Business section of the App Review Guidelines before release.

11. Subscriptions or In-App Purchases Are Incomplete or Unclear

Every in-app purchase submitted for review needs to be visible, functional, and understandable to the reviewer.

Clearly communicate what the user receives, the price and billing period, whether a trial converts to a paid plan, and how the subscription renews. Restore-purchase and subscription-management flows should work where required.

If the listing shows content or features that need an additional purchase, state that accurately in the metadata. Explain any purchase that is difficult to find in the App Review notes.

12. The App Provides Too Little Functionality

Apple may reject an app that feels like a collection of links, a marketing brochure, a demo, or a repackaged website with little app-like value.

Guideline 4.2 focuses on minimum functionality. Apple doesn't automatically disallow website-based apps, but they still need to deliver a useful, app-quality experience.

That can include clear mobile navigation, persistent login, native menus, push notifications used appropriately, deep links, sharing, device integrations, app-specific content, account features, or other functionality relevant to the product.

The answer isn't to bolt on arbitrary native features. Give customers a good reason to install the app instead of simply opening the same page in Safari.

13. The App Is a Copycat, Spam, or a Repetitive Template

Apple rejects apps that copy another app’s name, branding, interface, or core experience, as well as apps that add little unique value to an already crowded category.

Its spam rules also cover repeated submissions of substantially similar apps. White-label and template-based products need particular care. Each app should represent a real business or service, use accurate ownership and branding, and provide a distinct, maintained experience.

Don't use a competitor’s name or trademark in your metadata to capture search traffic.

14. User-Generated Content Lacks Safety Controls

Apps with user-generated content or social features must provide safeguards against abuse.

Apple expects:

• A way to filter objectionable material
• A way for users to report content
• Timely responses to reports
• The ability to block abusive users
• Published contact information

If an app includes reviews, community posts, comments, profiles, chat, marketplace listings, or other user submissions, build moderation into the product. Don't wait until Apple rejects the app to add it.

15. Content, Rights, or Age Ratings Are a Problem

Apple can reject content that is illegal, harmful, excessively objectionable, or inappropriate for the selected age rating.

You also need the rights to every image, video, logo, trademark, article, stream, product asset, and other protected material distributed through the app. If the app accesses third-party services, be ready to show authorization where ownership is not obvious.

Answer age-rating questions honestly. Apps for children have additional limits covering links, purchases, advertising, analytics, privacy, and parental gates.

16. The App Uses Unsupported Technology or Performs Poorly on Apple Devices

Apps should use public APIs, run on the currently shipping operating system, and use device resources responsibly.

Problems can include:

• Reliance on private or deprecated APIs
• Excessive battery drain, heat, storage, or background processing
• Poor layouts on supported screen sizes
• Features that fail on a supported iPad or iPhone
• Downloading code that materially changes the app outside permitted cases
• Encouraging users to disable security or system features

Test the full supported device matrix and remove obsolete technology before submission.

A Special Note for Ecommerce Apps

Ecommerce apps combine several areas Apple reviews closely: account access, customer data, notifications, checkout, third-party SDKs, and minimum functionality.

The good news is that ordinary purchases of physical goods don't use Apple’s In-App Purchase system. Your existing ecommerce checkout can generally stay in place, as long as it works correctly and follows Apple’s other rules.

The larger risk for a website-based ecommerce app is presenting a thin wrapper with poor navigation, broken web states, or little reason to install. The app should feel intentionally designed for repeat mobile shopping, even when the storefront remains connected to the website.

What to Do if Apple Rejects Your App

A rejection isn't necessarily final.

Apple lets you communicate with App Review in the App Review section of App Store Connect. Read the cited guideline and the reviewer’s notes carefully before responding.

Then:

1. Reproduce the issue on the submitted build.
2. Identify whether the problem is technical, metadata-related, or a policy interpretation.
3. Fix the issue and explain exactly what changed.
4. If the app already complies, respond with concise evidence and clear steps for finding the relevant feature.
5. Ask a specific question if the rejection message is ambiguous.
6. Use the appeal process when you have a substantive disagreement that cannot be resolved through normal review communication.

Keep your response calm and specific. Make it easy for the reviewer to verify the fix.

Apple’s guide to replying to App Review messages explains where to manage the conversation.

Pre-Submission Checklist

Before submitting, confirm that:

• The release build has been tested on real supported devices.
• No placeholder content or broken links remain.
• Reviewer credentials work and backend services are live.
• Review notes explain gated and non-obvious features.
• Metadata, screenshots, privacy labels, and age ratings are accurate.
• Privacy policies and support contact details are accessible.
• Permissions have a clear purpose.
• Account deletion and login options meet current rules.
• Payments match what the app sells and where it is distributed.
• In-app purchases are visible and functional.
• The app provides meaningful value beyond a basic website view.
• User-generated content has moderation controls.
• You hold the rights to all content and branding.
• The app uses supported APIs and performs responsibly.

How MobiLoud Handles App Submission

MobiLoud helps established ecommerce brands turn their existing websites into iOS and Android apps. Our team prepares and manages the App Store submission, helps produce the listing assets and review information, and handles the normal back-and-forth with App Review.

No third party can guarantee Apple’s approval. An experienced submission team can still catch common problems before review and handle policy questions with the right technical and business context.

If you're planning an ecommerce app, book a consultation to see how the process works.

The Bottom Line

Most preventable App Store rejections come down to readiness, accuracy, access, privacy, payments, or app quality.

Treat the reviewer like a new user who needs a stable product, truthful listing, working account, and enough information to understand anything unusual. Then check Apple’s live guidelines before every submission, particularly if the app handles digital purchases, sensitive data, children, user-generated content, or regulated services.