App Store / Google Play Rejection Casebook and a Practical Checklist to Pass Review

You are about to release your app, and the review sends it back. This is a wall that many developers run into at least once.

And the reasons reviews get blocked are not limited to crashes or broken builds. Permission descriptions, privacy policies, payment flows, store metadata, and missing review notes can all become causes. It is not unusual for operational issues outside the implementation itself to trigger the rejection.

In this article, I organize common rejection cases for App Store and Google Play by category and summarize the points you should verify before submission from a practical engineering perspective.

Target Audience

• People submitting an app to App Store / Google Play for the first time
• People who have been rejected before and want to organize the causes
• People developing with cross-platform stacks such as React Native or Flutter
• Teams that want to formalize a pre-release checklist

Terms to Understand First

Before we get into the article, here is a short glossary of terms that appear later. If you lock these in first, the rejection cases in the second half will be easier to read.

• reviewer: The person at Apple or Google who reviews the app. They do not only check the app binary, but also the store description, screenshots, disclosure information, and review notes.
• IAP (In-App Purchase): Apple's in-app purchase mechanism used to sell digital content or features inside an app.
• ATT (App Tracking Transparency): The iOS mechanism that asks the user for permission before tracking them across other companies' apps or websites.
• IDFA: An identifier used for ad measurement. If your setup uses it, you will often need to verify ATT and App Privacy.
• Data safety / App Privacy: Self-disclosure forms in Google Play / App Store about data collection. If you add an SDK but do not update the disclosure, the information becomes inconsistent.
• target SDK: The value that indicates which Android API level the app is designed to target. minSdkVersion means the minimum supported OS, so it is a different concept.
• store metadata: The full set of information shown or submitted in the store, such as screenshots, description text, subtitle, category, age rating, and disclosure items.
• WebView: A component that displays a web page inside an app. It is useful, but if most of the screen depends on WebView, the native value can look weak.
• UGC (User Generated Content): Content posted by users, including comments, image uploads, profiles, and reviews.
• restore purchases: The flow that restores a previously purchased entitlement. It is important for verifying subscriptions and one-time purchases.
• entitlement: A permission setting used to enable Apple capabilities or specific features. Most are available to regular apps, but some special entitlements require Apple approval or extra conditions.

The Reviewer's Perspective You Should Understand First

To reduce rejections, reading the guidelines is not enough. It is more useful to understand what the reviewer is checking in a short amount of time, because that makes it easier to prioritize fixes.

The states that most often get blocked are these:

• The implementation exists, but the explanation is weak.
• The app requests a permission, but the connection to the feature is unclear.
• The app has payments, but pricing or cancellation guidance is vague.
• The screenshots or description do not match the actual app.
• The reviewer cannot log in and confirm the main features.

Before visual polish, review focuses on safety, consistency, and completeness.

Organize the Differences Between App Store and Google Play First

Both platforms care that the app is safe, not misleading, and not unfinished, but the points that commonly block review differ slightly.

Roughly speaking, App Store tends to block on the strictness of the app experience, payments, and privacy explanations, while Google Play tends to block on technical requirements and consistency of self-disclosure.

That is why even for the same app, the order of preparation changes slightly.

• App Store: tighten device behavior, the payment screen, permission copy, and review notes first.
• Google Play: tighten target SDK, permissions, Data safety, and ad declarations first.

Case Studies Based on Actual Rejection and Publishing-Block Messages

Here I quote App Store review messages and Google Play publishing-block messages that are common in practice, then explain what each line usually means and what you should fix first. The later categories work well when read as detailed explanations of these cases.

Case 1: App Store crash immediately after launch

"We discovered one or more bugs in your app when reviewed on iPhone running iOS 17.0 on Wi-Fi. Specifically, the app crashed immediately upon launch."

This is not treated as a temporary failure. It is treated as a major defect that reproduces on the review device. The first thing to do is verify reproduction in airplane mode, on a fresh install, with an empty account, and on a slow network, then enumerate the processing that runs right after launch.

Case 2: Missing Privacy Policy on App Store

"Your app collects user or usage data but does not have a privacy policy URL."

This means the app handles some kind of data through SDKs or custom APIs, but the user-facing public explanation is missing. The first thing to do is publish one public URL and clearly describe the collected data, purpose of use, third-party sharing, and contact point, then align the App Store Connect settings with App Privacy.

Case 3: Digital purchases are not using IAP on App Store

"Your app includes the ability to purchase digital content, but the purchase mechanism does not use in-app purchase."

This is not about how the price is displayed. It means the billing method is wrong for the type of thing being sold. The first thing to do is break down what is being sold by feature and move anything consumed as digital value inside the app toward an IAP-first design.

Case 4: Google Play target API requirement is not satisfied

"When you publish a new app, you must target Android 15 (API level 35) or higher."

Google Play sometimes shows conditions as a publishing prerequisite rather than as a classic rejection email. When you see this, the issue is not app quality yet. You have failed a publishing requirement. The first thing to do is create an update plan that covers not only targetSdkVersion, but also dependent libraries, permission differences, notifications, and background behavior.

Case 5: A new Google Play personal account cannot move to production

"You must run a closed test for your app with a minimum of 12 testers who have been opted-in for at least the last 14 days continuously."

For a first release, you can get blocked by an account-type production gate unrelated to the app's quality. A new personal account cannot proceed to publication unless it satisfies the closed test and production access conditions. In addition, the account owner may have to complete Android device verification on a physical device.

The first thing to do is confirm whether the target account is a new personal account, then complete the 12 testers / 14 days closed test, continuous tester opt-in, and device verification with the Play Console mobile app as early as possible.

App Store often pushes these issues back as review notes, while Google Play often blocks you through Console requirements or disclosure mismatches. But the substance is shared. Most issues fall into one of these buckets: unfinished app, missing explanation, inconsistent disclosure, or unmet publishing requirement.

Category 1: App Completeness

1. The app crashes immediately after launch

API errors on first launch, local DB initialization failures, and nil access are among the most typical reasons for rejection. Here, nil access means the app tries to read an object before it actually has a value. Since the reviewer's device environment will never perfectly match yours, it is better to defend launch safety more aggressively than you think you need.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onAppear {
                    setupApp()
                }
        }
    }

    private func setupApp() {
        do {
            try initializeDatabase()
        } catch {
            print("DB init failed: \(error)")
        }
    }
}

Things to verify:

• The app does not crash on first launch even if no account exists yet.
• The app itself can still launch even when the network is unavailable.
• If fetching required data fails, the app can still move to a fallback screen.

One effective fix is to divide launch processing into these two classes:

• Processing that absolutely must succeed before anything can be shown.
• Processing that can fail and be retried later.

For example, there is no need to block the entire app on fetching remote config or preloading recommendations. If you first show the home screen or at least a minimal shell and only retry the failed work, the app becomes far less likely to break under review-environment differences.

In practice, you can usually fix this fastest in the following order:

• Collect the crash log.
• List every initialization step that runs at launch.
• Reduce the amount of synchronous must-succeed processing.
• Test on a physical device in airplane mode, on a fresh install, and with empty data.

2. Features are unimplemented or placeholders remain

Screens that only say "Coming Soon", buttons that do nothing, and dead links are all points that can make the app look unfinished.

Right before submission, it is safer to prioritize these tasks over adding new features:

• Remove unimplemented features that only have navigation entry points.
• Delete dummy text and test copy.
• Bring error screens and empty states up to at least a minimal acceptable level.

3. Nothing can be verified without logging in

Even for login-required apps, the app is more likely to be rejected if the reviewer cannot reach the main features.

What you need is not just account credentials, but the shortest possible verification path.

• Provide a demo account.
• If 2FA is required, write the steps.
• If some features are only visible for a specific role, add a note.
• If sandbox data is necessary, explain the initial state.

The basic response is to create a situation where the reviewer can verify the app's value through the shortest path. Ideally, you provide a read-only review account that can reach the main screens without requiring sign-up or contact with support.

Here, sandbox data means dummy data prepared for review and verification that does not affect production users. Order history, posts, subscription states, and map-based store data are all easier to review if they are preloaded instead of empty.

If the app uses SMS verification or an invite-only flow, it is safer not to throw that problem at the reviewer unchanged.

• Issue a review account with a long expiration window.
• If 2FA is required, attach a backup code or an alternate procedure.
• If an empty initial state hides the app's value, preload test data.
• Use the template in the later section on review notes and write the exact steps to reach the feature.

Category 2: Privacy and Permissions

4. There is no privacy policy URL

If the app handles user data or usage data but has no Privacy Policy URL, that is a serious risk. This is less a problem with the app binary itself and more a deficiency in the submission information.

At minimum, the privacy policy should clearly state the following:

• Types of data collected
• Purpose of use
• Whether data is shared with third parties
• Retention period
• How users can request deletion or correction

What is easy to confuse here is that Privacy Policy and App Privacy / Data safety are different things.

• Privacy Policy: A public document that users can read.
• App Privacy / Data safety: A self-disclosure submitted to the store.

Only having one of them is not enough. Their contents need to match.

The shortest solution is usually to publish one public page that says what you collect, what you use it for, and how to contact you. Then compare that page against your SDK inventory and update the disclosures in App Store Connect / Play Console.

5. The app requests permissions it does not use

Permissions such as location, contacts, microphone, and camera can create distrust if they are not strongly tied to a specific feature. In many cases, unnecessary permissions get pulled in indirectly by a library.

import { Alert } from 'react-native'
import * as Location from 'expo-location'

async function requestLocationForMap() {
  const { status } = await Location.requestForegroundPermissionsAsync()
  if (status !== 'granted') {
    Alert.alert('Location access is required to show nearby stores on the map')
    return
  }

  // Map rendering flow
}

The key point is to request only the permissions you use, at the moment you use them.

The practical trick is to check not only permission requests in code, but also declarations introduced by dependencies. On Android, you need to look at AndroidManifest.xml; on iOS, you need to look at Info.plist and the installed SDKs together, or unintended permissions can remain.

6. The permission description is too abstract

Explanations like "used to improve the experience" do not communicate what the permission is actually for. The wording needs to be tied to a concrete feature.

Good examples:

• To show nearby stores on the map
• To take a profile picture
• To use the camera to scan barcodes

Weak examples:

• To improve the experience
• To improve convenience
• To improve service quality

<key>NSLocationWhenInUseUsageDescription</key>
<string>Used to show nearby stores on the map</string>

<key>NSCameraUsageDescription</key>
<string>Used to take a profile photo</string>

7. App Tracking Transparency is not handled

If the app uses IDFA, you need consistency between the ATT dialog and the App Privacy disclosure. The app should also be designed to work even if the user does not grant tracking permission.

Here, ATT is the mechanism that asks the user for permission before accessing IDFA, which is commonly used for ad measurement and attribution. In practice, it is enough to understand it like this: if you added an ad SDK, if an analytics SDK reads IDFA, or if you track users across third-party data, review is more likely to examine this area.

import AppTrackingTransparency

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            break
        case .denied, .restricted, .notDetermined:
            break
        @unknown default:
            break
        }
    }
}

In practice, the realistic order of fixes is this:

• Inventory which SDKs use IDFA or tracking.
• Re-evaluate whether tracking is truly necessary.
• If it is unnecessary, remove the SDK settings or dependency so ATT itself becomes unnecessary.
• If it is necessary, align the ATT dialog, App Privacy, and the in-app explanation.
• Confirm that the main features work even without permission.

Category 3: Payments and Business Model

8. The app steers digital content to external payments

If the app sells digital goods or feature unlocks inside the app, App Store generally expects you to use IAP. Steering users to web payments or purchases on an external site is highly likely to get blocked.

The important understanding is this:

• Physical goods and in-person services can usually use external payment.
• Digital content and premium features should generally use IAP.
• If a Reader App shows account creation or management links to an external site, it needs the External Link Account Entitlement.
• Even where the Reader App exception exists, the eligible categories and implementation conditions are quite limited.

When you are unsure whether to use IAP, it helps to ask whether the thing being sold is digital value consumed inside the app.

• IAP-leaning examples: ad removal, premium features, game currency, unlimited articles, unlimited video access
• Often okay with external payment: physical products, ride hailing, in-person lessons, food delivery, hotel reservations

If the app already steers users to external billing and got blocked, you usually need to move in one of these directions:

• Redesign the billing flow around IAP.
• Check carefully whether the app truly qualifies for the Reader App conditions.
• Separate digital goods from physical services and reorganize the in-app purchase flow.

9. The subscription explanation is weak

For subscriptions, vague pricing, renewal timing, auto-renewal behavior, or cancellation guidance all look weak from a user-protection perspective.

At minimum, the paywall or store description should make these points clear:

• The plan name, duration, and what is included
• The total amount billed is shown clearly; for yearly plans, the annual amount should be the most obvious number
• The renewal cycle and the fact that it is auto-renewing are clear
• The regular price after a free trial is clear
• There are links to the Terms of Service and Privacy Policy
• There is a sign-in or restore purchases path for existing subscribers
• The cancellation method is understandable

One common mistake is making the monthly equivalent look large and prominent while making the real billed amount and renewal conditions hard to understand. For a yearly plan, it is safer to show the yearly total prominently and put the monthly equivalent below it as supplementary information.

It is often easiest to review a subscription screen by checking these elements:

• Plan name
• Billing timing
• Total billed amount
• Regular price after the free trial
• Restore path
• Terms of Service and Privacy Policy
• Management screen or cancellation path

For example, a sentence like "7-day free trial, then auto-renews at JPY 7,200 per year" is less likely to be misunderstood in review because it explains what happens after the free period in a single sentence.

To make the purchase screen harder to block in review, it also helps to answer the questions users most often get confused by directly on the screen:

• Which plan is currently selected?
• How much will be charged now?
• How much will it cost after the free period ends?
• By when does the user need to cancel to stop the next charge?
• Where can an existing subscriber restore the purchase?

// React Native alone cannot open StoreKit's system-provided UI directly,
// so this is a fallback example when you cannot bridge a native iOS implementation.
import { Linking, Text, TouchableOpacity } from 'react-native'

function SubscriptionSettings() {
  return (
    <TouchableOpacity
      onPress={() => Linking.openURL('https://apps.apple.com/account/subscriptions')}
    >
      <Text>Manage subscription</Text>
    </TouchableOpacity>
  )
}

If native iOS implementation is available, it is more natural to open the system-provided management UI with showManageSubscriptions(in:) as Apple documents.

10. The Reader App exception is interpreted too broadly

The Reader App exception looks convenient, but the target is quite limited. The main function must truly be one of magazines, newspapers, books, audio, music, or video, and the app is expected to let users view or play content or subscriptions that were purchased outside the app.

In addition, showing account creation or management links to an external site requires the External Link Account Entitlement. Apps that provide IAP on iOS / iPadOS / tvOS are not eligible for that entitlement, so it is incorrect to assume that being a Reader App means you can freely steer users to external payments.

Video, music, and books are treated differently from app features or in-game currency. If you submit without clearly classifying what category your app belongs to, the judgment is more likely to become inconsistent.

If you are unsure, it is safer to organize whether you are selling content or functionality, and where the purchase path exists, then supplement that explanation in the store description and review notes.

As a practical check before submission, these three Yes / No questions make the decision easier:

• Is the main function truly to provide magazines, newspapers, books, audio, music, or video?
• Is the structure centered on letting users access content purchased outside the app?
• Does the iOS version avoid offering IAP?

If any one of these three is ambiguous, it is safer not to design around the Reader App exception.

Category 4: Design and Experience Quality

11. The UI diverges too far from platform expectations

Completely custom navigation systems, missing back paths, and low-contrast unreadable text all reduce the perceived usability of the app. In review, it is usually better to prioritize platform-aligned usability over visual uniqueness.

12. It looks like the app is only wrapping a WebView

An app that is effectively just showing a website can be seen as offering weak native value.

Risky patterns:

• Almost the entire screen is a WebView.
• There are no native-device-specific features.
• Nothing works offline.
• There is no app-specific value such as device integration or notifications.

To avoid looking like a thin wrapper, it helps to make device-integration value explicit through sharing, notifications, camera access, local storage, offline UX, and similar features.

WebView itself is not the problem. The problem is when you submit a native app but the actual experience looks almost identical to the website. If you use WebView, it is better to provide native-side value in at least one of these ways:

• Native navigation or settings screens
• Device features such as sharing, notifications, camera, or file saving
• Offline explanations or cached views
• App-specific interaction that does not exist on the web version

13. Ads or payment prompts are too aggressive

If ads stand out more than the content, if placement causes accidental taps, or if hard-to-close interstitials are overused, that hurts both review outcomes and store ratings. Monetization paths can exist, but you need to verify on real devices that they are not breaking the experience.

Category 5: Store Metadata and Disclosure Information

Review checks not only the app itself but also the store description and disclosure information. If these diverge from reality, the app can be blocked even when the implementation is correct.

Items worth reviewing:

• Screenshots
• App description
• Subtitle
• Age rating
• App Privacy / Data safety
• Declaration of whether ads are shown

The especially dangerous pattern is putting features in the description that are not implemented. It is also safer not to advertise features that are only planned for the future.

Category 6: UGC and High-Risk Categories

14. There is UGC but no moderation flow

If the app handles user-generated content, simply having a posting feature is not enough. At minimum, it is better to provide these paths:

• Reporting
• Blocking
• Terms of use
• Contact channel
• A policy for handling violating content

If there is UGC but no visible defense against abuse, the review side is more likely to worry about operational risk.

15. Accountability is weak in health, finance, or kids categories

Medical and health apps, finance and investment apps, kids apps, and apps that constantly use location are reviewed more strictly than general categories. It is safer to assume a higher bar for accuracy, legal compliance, explanations with no room for misunderstanding, and clear contact information.

In these categories especially, seemingly helpful marketing copy can backfire. Wording around health or investment needs to avoid guaranteeing outcomes, misleading users, or creating exaggerated expectations.

In practice, you can reduce accidents by reviewing from these angles:

• Medical or health: Are you avoiding definitive diagnosis or treatment claims?
• Finance: Are you avoiding guaranteed profit or exaggerated expectations?
• Kids: Are external links, ads, or payment prompts too strong?
• Always-on location: Is constant collection truly necessary, or is there an alternative?

In this category, checking whether you are overstating claims and whether you are fulfilling your explanation duty matters more than adding features.

How to Read Common Rejection Wording

Review messages are often short and abstract, so it is hard to tell what you need to fix if you read them literally. In practice, it becomes easier to act if you translate them into the following meanings.

The key here is to read review wording as if it were a specification. Even if it looks abstract, most cases can be classified as unfinished app, weak explanation, or inconsistent disclosure.

Easy-to-Miss Items on Google Play

First-release requirements for new personal accounts

If you are releasing to Google Play for the first time, this is especially important. A newly created personal developer account has account-level requirements for moving into production that are separate from the app's contents.

Two representative examples are these:

• At least 12 testers must be continuously participating in the closed test.
• Android device verification must be completed using the Play Console mobile app.

This works less like a classic rejection email and more like a block inside Play Console that prevents progression to production. In other words, even if the app itself is complete, you still cannot publish if the account-side conditions are not satisfied.

Common places where first releases get stuck:

• You have enough testers, but they have not satisfied the 14-day continuous opt-in condition.
• Testers joined, but actual usage or feedback is thin.
• The account owner has not finished device verification.
• You assume an internal test is enough and miss the closed test requirement.

For a first release, it is safer to clear these requirements early in parallel with implementation verification.

Falling behind on target SDK updates

Google Play target API level requirements are updated continuously. You need an operational habit of checking the latest requirement in Play Console at the time of submission, not the latest number that was true when the article was written.

What is easy to confuse here is the difference between targetSdkVersion and minSdkVersion.

• targetSdkVersion: The level of support assumed for newer Android behaviors.
• minSdkVersion: How far back in Android versions you support.

In other words, even if you did not raise minSdkVersion, Google Play can still block the app simply because targetSdkVersion is behind the submission requirement.

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    defaultConfig {
        targetSdkVersion rootProject.ext.targetSdkVersion
        minSdkVersion 24
    }
}

The practical response is not to stop at changing the number. Raising the target SDK can change the permission model, background restrictions, notification behavior, foreground services, file access, and more. When you update it, verify these together:

• Compatibility of Android Gradle Plugin and dependent libraries
• Behavioral differences in permission dialogs
• Restrictions on notifications and background processing
• Real-device tests on the main target devices

Dangerous permissions remain in the manifest

If unused dangerous permissions remain in the manifest, you still take on an explanation burden. In particular, CONTACTS, CALL_LOG, SMS, and READ_PHONE_STATE should be reviewed carefully.

<!-- Do not declare permissions you do not use -->
<!-- <uses-permission android:name="android.permission.READ_CONTACTS" /> -->
<!-- <uses-permission android:name="android.permission.READ_CALL_LOG" /> -->

Data safety does not match the implementation

It is more common than people think to add an analytics SDK or ad SDK and leave the Console disclosure outdated. When you change SDKs, your process needs to treat Data safety as something that must be updated too.

Data safety is the Google Play section where you declare what data the app collects or shares and what it is used for. The Apple-side App Privacy works on a similar idea, and mismatches reduce trust.

The safest solution is to inventory the data instead of writing the form from memory.

• List the SDKs currently included.
• Check what type of data each one handles.
• Also enumerate the data your own APIs send.
• Compare those findings against the declarations in Play Console / App Store Connect.
• If something changed, update the privacy policy too.

Request Permissions at the Moment They Are Needed

Designs that show multiple permission dialogs immediately after launch tend to leave a bad impression on both users and reviewers.

The better policy is this:

• Request the permission when the user reaches the feature.
• Show a short pre-permission explanation right before it.
• Prepare an alternate path for the deny case.

This helps not only with review, but also with permission acceptance rates.

What to Write in Review Notes

The review notes field is easy to underestimate, but it is an important place to reduce reviewer confusion. It is particularly effective for login-required apps, permission-heavy apps, and apps that depend on external devices.

Useful information to include:

• Demo account credentials
• Steps to reach the main features
• Which screen uses each permission
• Notes when 2FA or a specific role is required
• Notes when an external server or device dependency exists

Short template example:

Review account:
Email: reviewer-demo@example.com
Password: xxxxxxxx

Main test flow:
1. Sign in with the review account
2. Open the Map tab to test location permission
3. Open Settings > Subscription to verify cancellation guidance

Response Policy After a Rejection

The important thing after a rejection is not to argue emotionally, but to classify the pointed-out issue accurately.

The basic order of work is this:

1. Re-read the message exactly as written.
2. Confirm the reproduction conditions.
3. Classify it as an implementation defect, a missing explanation, or a disclosure mistake.
4. If needed, supplement with screenshots or video.

Even when the review looks genuinely mistaken, it is often faster to fill the explanation gap first. In practice, it is better to treat an appeal as the last resort.

In the actual reply, it is usually more effective to write a short and clear summary of what changed than to send a long defense.

Thank you for the review.

We identified the issue as [implementation / metadata / clarification].
We made the following changes:
1. Fixed [issue]
2. Updated [metadata or review notes]
3. Added [account / explanation / screenshot]

How to verify:
1. Sign in with the review account
2. Open [screen name]
3. Tap [action]

If needed, we can provide additional screenshots or a screen recording.

If you reduce it to essentials, you only need three points: the cause, what you changed, and how to verify it. The longer a team struggles with review, the more these three points tend to get mixed together and make communication harder.

What to Do in the 48 Hours Before Submission

Right before release, the temptation to add one more feature is strong. But if you want to improve review pass rate, it is usually more effective to spend the final stretch on verification rather than implementation.

48 hours before

• Review the store description, screenshots, age rating, and Data safety / App Privacy.
• Inventory the SDKs in use and the list of permissions.
• Prepare the reviewer account and review notes.

24 hours before

• Verify launch behavior on the latest iPhone OS, one previous iOS version, and multiple Android devices.
• Test airplane mode, a slow network, and the fresh-install state.
• Run through payments, login, permission requests, and account-deletion flows end to end.

6 hours before

• Make one final pass to ensure the screenshots still match the actual app.
• Confirm there is no mismatch between store disclosures and the SDK configuration.
• Fully write the review notes with the path to reach the main features and any needed context.

Even just running this 48-hour flow every time makes it much easier to reduce rejection rates.

Operational Practices That Prevent Repeat Issues

Even after a release is approved once, the same issues tend to reappear when you add features or change SDKs. Whether you work alone or in a team, the following practices reduce accidents:

• When you add an SDK, update permissions, Data safety, and App Privacy as one set.
• Limit store-description claims to features that are actually implemented.
• When adding a new permission, review the target screen and the explanation text together in the PR.
• Turn the pre-release checklist into an issue template or reusable checklist.
• Record rejection wording and how you responded, then reuse that knowledge in future review notes.

The biggest long-term win is to stop treating review response as something you invent from scratch each time.

Pre-Submission Checklist

It is easier to catch gaps if you split the checklist into forms you can use as-is for each store. Even shared items are included in each table.

App Store pre-submission checklist

Google Play pre-submission checklist

Summary

What most often blocks app review is not simple bugs, but mismatches between implementation and explanation and gaps in operational preparation.

The four most important points are these:

• The reviewer can verify the main features without confusion.
• The reasons for permissions and data collection are explained concretely.
• Billing rules and store disclosures are correctly aligned.
• Store metadata matches the actual implementation.

The closer you get to release, the stronger the temptation to add one more feature. But if your goal is to improve review pass rate, it is more effective to spend the final day exhausting the checklist.

References

• App Store Review Guidelines
• Auto-renewable subscriptions
• Google Play Policy Center
• Human Interface Guidelines
• In-App Purchase (Human Interface Guidelines)
• Distributing reader apps with a link to your website
• App testing requirements for new personal developer accounts
• Device verification requirements for new developer accounts
• Target API level requirements for Google Play apps
• App Tracking Transparency