App Store Review: Top Rejection Reasons

Submitting an application to the Apple App Store involves navigating a stringent review process. While the guidelines are publicly available, specific…

Submitting an application to the Apple App Store involves navigating a stringent review process. While the guidelines are publicly available, specific nuances often lead to rejections, consuming valuable development time. Understanding the common pitfalls and preparing thoroughly can significantly streamline your app's journey from development to deployment.

Common Rejection Reasons and How to Avoid Them

1. Incomplete Information and Metadata

One of the most frequent rejection reasons stems from inadequate or misleading information provided during the submission process. This isn't just about technical completeness but also about clarity for the reviewer.

Missing or inaccurate privacy policy: This is a critical point, especially with evolving data regulations (e.g., GDPR, CCPA). Your app must clearly link to a privacy policy from within the app and on its App Store product page. The policy must detail what data is collected, how it's used, stored, and shared, and how users can request data deletion. For apps targeting iOS 14.5+ or iPadOS 14.5+, ensure your App Privacy Details (nutrition label) in App Store Connect accurately reflect your policy and app behavior.
Inaccurate or insufficient app description: The description should clearly and concisely explain your app's functionality and purpose. Avoid keyword stuffing or including information irrelevant to the app's core features.
Outdated or irrelevant screenshots/previews: Screenshots and app previews must accurately represent the current version of your app running on the latest iOS/iPadOS versions. If your app supports both iPhone and iPad, provide screenshots for both form factors. Avoid promotional material or marketing text within the screenshots themselves.
Demo account credentials (if applicable): If your app requires a login, provide active, working demo account credentials (username and password) in the "App Review Information" section of App Store Connect. Ensure these credentials do not expire and provide access to all features reviewers need to evaluate. Specify any special setup steps if required.
Missing contact information: Provide up-to-date contact details where Apple can reach you for questions or clarifications.

2. Technical Instability and Performance

An app that doesn't function reliably or performs poorly will almost certainly be rejected. Apple emphasizes a high-quality user experience.

Crashes on launch or during use: This is an immediate show-stopper. Thoroughly test your app on various device models and iOS/iPadOS versions, especially the most recent major releases (e.g., iOS 17.x, 16.x) and potentially older, still-supported versions (e.g., iOS 15.x if your deployment target is set lower). Use Xcode's Organizer to analyze crash logs and address root causes. Implement crash reporting tools like Firebase Crashlytics or Sentry to catch issues during beta testing.
Bugs and unresponsive UI: Any major bug that impairs core functionality, UI elements that don't respond, or frozen screens will lead to rejection. Comprehensive QA testing is crucial.
Poor performance: Apps that are slow to load, frequently freeze, drain battery excessively, or use excessive network data may be rejected. Profile your app for CPU, memory, and network usage using Xcode's Instruments.
Broken links: All external links within your app (e.g., support pages, privacy policies, terms of service) must be functional and direct users to the correct content.
IPv6 Network Incompatibility: Apple's review network exclusively uses IPv6. If your app makes direct IP connections or relies on older networking frameworks that don't support IPv6 (e.g., some hardcoded IPv4 addresses), it will fail review. Ensure your app uses domain names and modern networking APIs like URLSession which inherently support IPv6. Test your app on an IPv6-only network.


// Example: Basic URLSession request, inherently IPv6 compatible
func fetchData(from urlString: String, completion: @escaping (Result<Data, Error>) -> Void) {
    guard let url = URL(string: urlString) else {
        completion(.failure(AppError.invalidURL))
        return
    }

    let task = URLSession.shared.dataTask(with: url) { data, response, error in
        if let error = error {
            completion(.failure(error))
            return
        }

        guard let httpResponse = response as? HTTPURLResponse,
              (200...299).contains(httpResponse.statusCode) else {
            completion(.failure(AppError.serverError))
            return
        }

        guard let data = data else {
            completion(.failure(AppError.noData))
            return
        }
        completion(.success(data))
    }
    task.resume()
}

enum AppError: Error {
    case invalidURL
    case serverError
    case noData
}

3. Design and User Experience (UX) Issues

Apple places a strong emphasis on apps that adhere to their Human Interface Guidelines (HIG) and provide an intuitive, high-quality user experience.

Poor user interface: Cluttered interfaces, inconsistent design elements, unreadable text, or UI elements that are difficult to tap will be rejected. Ensure your app looks good and functions well across all supported device orientations and screen sizes, including Dynamic Island and various notch designs.
Not optimizing for the target platform: An iOS app should feel like an iOS app, not a web page wrapped in a native container or an Android app ported directly. Leverage native UI elements and interaction patterns.
Incomplete or placeholder content: Apps submitted with "Lorem ipsum" text, placeholder images, or unfinished features will be rejected. The app must be fully functional and ready for public release.
Requiring unnecessary permissions: Only request permissions (e.g., location, camera, contacts) when and if they are genuinely needed for a core feature, and clearly explain why you need them. Request permissions at the point of need, not on launch.
Lack of perceived value or "junk" apps: Apps that merely replicate existing functionality with no added value, provide little utility, or are simply collections of links may be rejected under Guideline 4.2.
Misleading advertising: In-app ads should not interfere with the user experience, simulate system alerts, or be deceptive.

4. Guideline 2.1: App Completeness

This is a broad category encompassing various issues that indicate the app isn't ready for prime time.

Unfinished features: Any features that are advertised or appear in the UI must be fully functional. Disable or remove any "coming soon" or incomplete sections.
Beta or Test versions: Do not submit beta, demo, or trial versions unless explicitly designed as such and clearly labeled. The app must be a complete, shippable product.
Placeholder content: Ensure all content is final and relevant. No "lorem ipsum" text or temporary images.

5. Guideline 2.5: Software Requirements (Using Private APIs)

This is a critical technical rejection reason. Apple strictly prohibits the use of private APIs.

Using private APIs: Private APIs are undocumented Apple frameworks or functions that are not part of the public SDK. Using them can lead to app instability on future iOS versions and security vulnerabilities. Xcode will often warn you about private API usage, but static analysis tools (e.g., App Store Connect API validation, nm, strings, or third-party tools like class-dump combined with grep) can help identify them. The usual advice is to stick to public Apple documentation.

Example detection command for suspected frameworks:


        # Navigate to your compiled .app bundle
        cd YourApp.app
        # Search for private framework names within your executable
        grep -r "UIKitPrivate" .
        grep -r "GraphicsServices" .
        # Or check for specific symbols that are known to be private
        nm -gU YourAppExecutable | grep "UIKeyboardImpl"

If you encounter such symbols or framework names, you likely have private API usage and need to refactor your code to use public alternatives.

Binary size: While not a direct rejection reason unless excessive, bloated apps can lead to slow downloads and poor user experience, sometimes triggering performance-related rejections. Optimize asset sizes and use App Thinning.

6. Legal and Content Issues

These rejections relate to compliance with laws, Apple's terms, and content appropriateness.

Intellectual Property infringement: Do not use copyrighted images, trademarks, or proprietary content without explicit permission. This includes app names, icons, and content within the app.
Misleading or deceptive marketing: Your app's functionality must match its description and promotional materials.
Gambling, dating, or highly regulated apps: These categories have specific, very strict guidelines. Ensure full compliance, including necessary licenses and age ratings.
Objectionable content: Apps containing offensive, pornographic, defamatory, or hateful content will be rejected.
Spam and duplicate apps: Submitting multiple apps with similar functionality or content, or simply cloning other apps, is prohibited.

Common Pitfalls and Troubleshooting

Ignoring rejection messages: Always read the rejection message carefully. Apple provides specific guideline numbers and often screenshots or steps to reproduce issues. Don't just resubmit without addressing the identified problems.
Testing only on the simulator: Always test on physical devices, including older models if your deployment target allows. The simulator does not accurately reflect real-world performance or hardware interactions.
Last-minute submission: The review process can take several days. Plan accordingly. If rejected, it adds more time.
Not using TestFlight: Thoroughly beta test your app with a broad audience using TestFlight to catch bugs and usability issues before official submission.
Being vague in resolution responses: When appealing a rejection or providing clarification, be precise. Explain exactly what changes you made and why, or why you believe your app complies.
Forgetting App Transport Security (ATS): For apps targeting iOS 9.0+, ATS is enabled by default, requiring HTTPS connections. If your app connects to HTTP endpoints, you must either configure ATS exceptions (with justification) or ensure all connections are secured with TLS 1.2 or higher.