Why Mobile Apps Get Rejected by Apple or Google

Why Mobile Apps Get Rejected by Apple or Google

A team spends four months building an app.

It works on the founder’s iPhone.

It works on the developer’s Pixel.

The TestFlight build looks good. The Play internal build looks good. Marketing announces the launch.

Then the review message arrives:

Rejected.

The first reaction is usually:

“But the app works.”

That’s where teams misunderstand app review.

Apple and Google may reject an app because of technical problems, incomplete functionality, privacy issues, inaccurate disclosures, permissions, payments, metadata, account requirements, user safety, limited functionality, or other platform-specific policy requirements.

The best way to reduce review problems is to design store requirements into the app before development is finished.

Apple’s current App Review Guidelines are organized around safety, performance, business, design, and legal/privacy concerns. Google Play similarly evaluates functionality, data handling, monetization, permissions, content, technical requirements, and other policy areas. (Apple Developer)

A working binary is only one part of a submission.

App Review Starts During Product Design

App review should not become a checklist somebody opens the night before launch.

Decisions made months earlier can determine whether the release is easy or painful:

• Does the user need an account?

• How is that account deleted?

• Which data does the app collect?

• Which third-party SDKs are installed?

• Which device permissions are requested?

• Does the app sell digital features?

• Does it contain user-generated content?

• Does it send user data to an AI provider?

• Does it need location in the background?

• How will a reviewer reach functionality behind authentication?

Apple itself tells developers to use its review guidance while planning and building, not simply after development is finished. (Apple Developer)

Here’s the part that catches teams off guard: a store-policy decision can become an architecture decision.

If account deletion was never designed, privacy was never mapped, or the payment system was built around the wrong assumption, fixing review issues at the end can require more than changing a line of copy.

Apple and Google Are Reviewing More Than Code

Technical Quality

Does the app install, launch, respond, and perform its major functions?

User Experience

Does the app provide meaningful mobile functionality and behave reasonably on the platform?

Privacy

Do the app, SDKs, privacy policy, Apple App Privacy information, and Google Data Safety declarations tell the same story?

Security

Are sensitive data, permissions, authentication, and privileged features handled appropriately?

Business Model

Are purchases and subscriptions structured according to the applicable store rules?

Content

Does the app contain prohibited content or inadequate controls around user-generated material?

Metadata

Do the description, screenshots, title, subscription information, and promotional claims accurately describe what reviewers receive?

App Completeness Is a Real Review Requirement

Apple’s Guideline 2.1 says submissions should be final versions with required metadata and functional URLs. Placeholder text, empty websites, temporary content, obvious crashes, and incomplete builds can cause rejection. Apple also explicitly reminds developers to provide demo-account information and keep the backend service running when login is required. (Apple Developer)

A production candidate should not contain:

• Lorem ipsum

• “Coming soon” screens presented as finished features

• Debug menus visible to customers

• Buttons that do nothing

• Dead links

• Temporary landing pages

• Expired test accounts

Google Play similarly requires apps to be stable, responsive, functional, and to provide meaningful utility. Apps that do not install, do not load, freeze, crash, or provide effectively no useful functionality can violate its Functionality, Content, and User Experience policy. (Google Help)

Crashes and Freezes Are the Obvious Problems

These are straightforward:

The app crashes at launch.

Login closes the application.

A screen freezes.

A critical button never completes.

An API failure leaves the app stuck on an infinite spinner.

A fresh install opens to a blank screen.

The harder problems are the ones your team does not see because your test devices already have everything configured.

Test More Than One Perfect Developer Phone

Developers commonly test on devices that already contain:

• A valid login session

• Cached configuration

• Test data

• Existing permissions

• Development environment settings

• Old feature flags

A reviewer is much closer to a new customer.

Test:

• Fresh installation

• Logged-out state

• New account

• Existing account

• Permission denied

• Poor network

• Smaller phone

• Larger phone

• Minimum supported OS

• Recent OS

• Dark mode where relevant

• Accessibility settings

You do not need every device ever produced.

You do need representative testing.

Your Backend Is Part of the App Review Experience

A perfectly stable mobile binary can appear completely broken when the server behind it fails.

Common examples:

• Staging server was shut down.

• Test account expired.

• Database contains no usable review data.

• Firewall allows only company IP addresses.

• Review environment cannot receive your OTP.

• Feature flag disables the important screen.

• API certificate expired.

• Subscription configuration exists in one environment but not another.

Your reviewer needs the full app, not the version that only works from your office Wi-Fi.

Reviewer Login Access Deserves Its Own Test

This is one of the easiest problems to prevent.

Apple’s App Store Connect documentation says that if login is required, App Review information should include a non-expiring demo username and password, with additional configuration or testing instructions in the Notes field. (Apple Developer)

Google Play has similarly explicit requirements. Reviewer credentials must remain valid and reusable, and Google advises developers to provide a path that avoids location-dependent passwords, expiring OTP barriers, or other access conditions that stop reviewers from reaching functionality. (Google Help)

Do not make reviewers:

• Buy a paid company account.

• Contact Sales.

• Wait for your administrator to approve them.

• Call your engineer for an SMS code.

• Be physically present in your office.

• Guess how to reach a hidden test mode.

Test your reviewer account yourself right before submission.

Then have someone else test it.

Good Review Notes Save Time

Review notes are not the place to write:

“Everything works. Please approve.”

Useful notes explain things the reviewer cannot reasonably infer.

For example:

• How to reach a non-obvious feature

• Which account role to use

• Why location is required

• How a Bluetooth accessory workflow is demonstrated

• How subscription functionality works

• Which feature requires special hardware

• What test data has been prepared

• Which credentials access each role

Apple specifically provides the App Review Notes field for settings, test registration details, accounts, streams, and other information needed to evaluate the product. (Apple Developer)

The store reviewer doesn’t know your product the way your team does.

Give them a clean path.

Screenshots and Metadata Must Match Reality

Your listing is part of the submission.

Review:

• App title

• Subtitle

• Description

• Screenshots

• Promotional text

• Subscription messaging

• Support URL

• Privacy URL

Do not advertise functionality reviewers cannot find.

Do not show a redesigned interface in screenshots if the submitted build still has the old one.

Do not describe “real-time tracking” when the app only refreshes manually.

Do not call something “AI-powered” simply because a basic rule engine exists.

Do not invent security capabilities, awards, user counts, affiliations, or certifications.

The reviewer is evaluating the product you submitted, not your roadmap.

“Coming Soon” Does Not Replace Current Functionality

It is fine to have a roadmap.

It is not fine to sell future functionality as though it already exists.

If the store description says users can scan inventory with the camera, the reviewer should be able to use that feature.

A roadmap slide does not complete an unfinished app.

Minimum Functionality Can Surprise Website-to-App Projects

Apple Guideline 4.2 says an app should contain features, content, and UI that elevate it beyond a repackaged website. Apps that are little more than marketing material, web clippings, or collections of links can face minimum-functionality problems. (Apple Developer)

This does not mean every WebView app is automatically rejected.

The question is whether the app provides meaningful utility and an app-like experience.

If the project starts with:

“We already have a website. Put it inside an app.”

ask what the app actually improves.

Maybe there is a legitimate reason:

• Offline workflow

• Camera scanning

• Push notifications

• Location-based functionality

• Device integration

• Better authenticated workflow

• File capture

• Mobile-specific navigation

Do not bolt on random native features simply to make the review checklist longer.

The features should make the product better.

Google Also Rejects Apps With Very Limited Functionality

Google’s language is different, but the principle is similar.

Google Play says apps should provide adequate utility and meaningful content. Its examples of violations include static text-only or PDF-style apps, apps with very little content, apps designed to do essentially nothing, and apps that fail to load or respond. (Google Help)

One store’s approval does not guarantee the other store’s approval.

Treat them as separate releases.

Copycats, Templates, and Repetitive Apps

Apple specifically prohibits simply copying popular apps and has separate rules around commercialized templates and multiple similar apps. (Apple Developer)

Google’s Spam policy similarly prohibits repetitive or low-quality apps and warns against publishing multiple applications that provide essentially the same experience. (Google Help)

That does not make legitimate white-label software impossible.

It does mean the distribution architecture needs thought.

Sometimes a single multi-tenant application with organization-specific accounts is a better store model than publishing dozens of nearly identical binaries.

Privacy Policy: A Generic Template Is Not Enough

A privacy policy has to describe what the product actually does.

Apple currently requires a privacy-policy link in App Store Connect and within the app. Its guidelines say the policy should explain data collection and use, third parties that receive user data, retention/deletion practices, and how users can revoke consent or request deletion. (Apple Developer)

Google requires a privacy policy for apps on Google Play, including apps that state they do not collect personal or sensitive data. Its User Data policy requires the policy to explain data access, collection, use, sharing, secure handling, retention, deletion, and a privacy contact mechanism. (Google Help)

A policy copied from another company does not solve this.

Your implementation and disclosure need to match.

Apple App Privacy: The Label Must Describe the Released App

App Store Connect requires developers to describe relevant data practices.

That includes the behavior of third-party code integrated into the application.

Apple explicitly says developers must include data practices of third-party partners and keep App Privacy responses accurate as app behavior changes. (Apple Developer)

So when Product says:

“We don’t collect user identifiers.”

Engineering needs to verify whether:

• Analytics does.

• Attribution does.

• Advertising does.

• Crash reporting does.

• Social login does.

• A mapping SDK does.

The privacy label should describe what the released app actually does—not what the product manager thinks it does.

Google Data Safety Works the Same Way Conceptually

The taxonomy is not identical to Apple’s, so do not copy one store’s answers into the other.

Google requires developers to complete the Data Safety form explaining collection, sharing, purposes, and relevant security practices. The requirement includes data handled by third-party libraries and SDKs, and developers remain responsible for accurate declarations. (Google Help)

Every meaningful SDK change should trigger a privacy review.

Third-Party SDKs Can Create Submission Problems

The SDK is inside your app.

The store does not care that a vendor wrote the code instead of your engineer.

Apple’s App Review Guidelines explicitly say developers are responsible for ad networks, analytics services, and third-party SDKs included in their apps. (Apple Developer)

Google Play likewise states that Data Safety declarations include data collected and handled through third-party SDKs, and Google can identify SDK versions associated with known policy issues. (Google Help)

Review:

• Analytics

• Crash reporting

• Advertising

• Attribution

• Mapping

• Social login

• Payments

• Push notifications

• AI providers

A dependency update is still a product change.

Apple Privacy Manifests Are Now Part of Release Engineering

Apple privacy manifests use the PrivacyInfo.xcprivacy file format to describe certain data practices and use of required-reason APIs.

Apple requires declared approved reasons for covered APIs and rejects App Store Connect uploads that use required-reason APIs without appropriate declarations. (Apple Developer)

Apple also maintains a list of commonly used third-party SDKs for which privacy manifests are required and, for binary dependencies in scope, signatures are required. (Apple Developer)

That means:

A dependency can create submission work even when your own application code did not change.

Generate and review the Xcode privacy report before submission where applicable; Apple specifically recommends using that report to help reconcile third-party manifests with App Privacy details. (Apple Developer)

Ask for Permissions Because a Feature Needs Them

Camera.

Photos.

Microphone.

Location.

Contacts.

Bluetooth.

Notifications.

Every one of these can be legitimate.

The problem is asking for broad access without a clear user-facing reason.

Apple’s privacy guidance says apps should minimize data access, ask only for data relevant to core functionality, respect user choices, and use narrower system pickers or share sheets when practical. (Apple Developer)

Google similarly requires sensitive access to be necessary for functionality represented in the Play listing and recommends contextual, incremental permission requests. (Google Help)

Ask in Context

Bad experience:

User opens the app.

Immediately:

“Allow location?”

“Allow camera?”

“Allow microphone?”

“Allow contacts?”

“Allow notifications?”

The user has no idea why.

A better approach is to ask when the user reaches the feature.

Scan equipment barcode → ask for camera.

That makes the permission understandable to the user and easier to justify during review.

Android Sensitive Permissions Need Extra Attention

Some Android permissions have special Play policy requirements.

For example, broad access to photos/videos can require a Play Console declaration, while Google recommends the Android Photo Picker when persistent broad access is not necessary. (Google Help)

Background location also requires strong core-functionality justification and a Play declaration process. (Google Help)

SMS, Call Log, installed-app visibility, and other restricted capabilities each have their own rules. (Google Help)

If your feature works without broad sensitive access, that is usually a signal to redesign the permission model.

Account Creation Brings Account Responsibilities

If the user has to create an account, think through the full lifecycle:

• Registration

• Verification

• Login

• Password reset

• MFA if used

• Session expiration

• Account recovery

• Account deletion

• Data deletion

Do not design only the happy-path login screen.

Account Deletion Is a Major Review Item

Apple

Apple currently requires apps that support account creation to let users initiate deletion of the account within the app. Merely offering temporary deactivation is not enough. (Apple Developer)

Google

If an app enables account creation, Google requires an in-app path to request account and associated-data deletion and a web resource through which users can request deletion outside the app. (Google Help)

Google also clarifies that freezing or deactivating an account is not equivalent to deletion.

If legitimate security, fraud-prevention, or legal requirements require retention of some information, disclose the retention appropriately and obtain qualified legal/privacy advice. (Google Help)

Social Login and Sign in with Apple

This rule is commonly oversimplified.

Apple Guideline 4.8 applies when certain third-party or social login services are used to set up or authenticate the user’s primary account. In that situation Apple requires an equivalent login option with specified privacy characteristics, subject to the guideline’s exceptions. (Apple Developer)

Do not reduce that to:

“Any Google login means Sign in with Apple.”

Review Guideline 4.8 against the actual authentication architecture.

Payments Are One of the Most Expensive Areas to Get Wrong Late

The first question is:

What is the customer buying?

Digital Goods or Digital Features

Examples:

• Premium app features

• Digital subscriptions

• Virtual currency

• Digital content

Physical Goods or Real-World Services

Examples:

• Food delivery

• Transportation

• Physical products

• Many in-person services

The rules are different.

Apple In-App Purchase

Apple’s current Guideline 3.1 generally requires In-App Purchase when users unlock digital functionality or digital content inside the app, while separate rules and regional/storefront exceptions apply to external purchase options and other categories. Physical goods and services consumed outside the app use other payment methods. (Apple Developer)

This area has changed materially over time and differs by storefront.

Do not design a payment architecture from a three-year-old blog post.

Read the current rule for the markets where you distribute.

Google Play Billing

Google’s current Payments policy similarly requires Play Billing for many digital goods, services, subscriptions, and app functionality distributed through Play, unless an applicable exception applies.

Physical goods and physical services are treated differently. (Google Help)

Again:

Digital and physical are not the same category.

Subscription Screens Need to Be Clear

Before a user subscribes, make it easy to understand:

• Price

• Billing frequency

• Trial terms

• Renewal

• What is included

• How the subscription is managed

Apple’s subscription guidance explicitly requires clear information about what the user receives for the price. (Apple Developer)

A technically valid purchase flow can still create review trouble if the UI is misleading.

In-App Purchases Need to Work During Review

Do not submit a purchase screen linked to products that are not configured.

The reviewer should be able to understand:

• What is being purchased.

• What it costs.

• How the test flow works.

• What functionality becomes available.

Test the actual store configuration, not a developer-only fake purchase screen.

User-Generated Content Changes the Safety Requirement

If users can post text, images, comments, profiles, messages, or videos, moderation becomes part of the product.

Apple Guideline 1.2 requires mechanisms including filtering objectionable content, reporting offensive material, blocking abusive users, and published contact information. Apple updated its guidelines in 2026 to clarify that random or anonymous chat is subject to the UGC guideline. (Apple Developer)

Google likewise requires UGC apps to maintain effective moderation, provide terms, and provide accessible reporting and blocking functionality. (Google Help)

Moderation is not something Legal writes in a PDF after launch.

It is functionality.

Apps for Children Need Separate Review

Children and family products come with additional privacy, advertising, content, SDK, age, and parental-control requirements.

Apple’s Kids Category has additional restrictions and requires parental gates for certain actions. (Apple Developer)

Google’s Families policies similarly apply additional rules when children are part of the target audience. As of August 26, 2026, Google also prohibits anonymous-chat apps from targeting children. (Google Help)

Do not guess whether the product qualifies.

Review the current rules and obtain appropriate legal/privacy guidance where necessary.

AI Apps Are Not Automatically Rejected

An AI feature is not, by itself, a store violation.

But it can introduce several review areas at once:

• User data sent to a model provider

• Privacy disclosure

• Consent

• Harmful generated content

• Moderation

• User reporting

• Third-party data processing

Apple’s current privacy guideline specifically requires clear disclosure when personal data is shared with third parties, including third-party AI, and explicit permission before doing so. (Apple Developer)

Google’s July 2026 policy update similarly clarifies that User Data requirements apply to third-party AI integrations. Google also maintains an AI-Generated Content policy addressing prohibited harmful or deceptive output. (Google Help)

Do not assume the AI provider’s privacy settings for your use case.

Verify the provider arrangement separately.

App Tracking Transparency Is About Tracking, Not “Any Analytics”

Apple requires App Tracking Transparency when an app collects user/device data and shares it with other companies for tracking across apps and websites.

That is not the same as saying:

“Any analytics SDK requires ATT.”

The actual data flow and purpose matter. (Apple Developer)

Audit the SDK behavior rather than guessing from the vendor category.

The Store Listing Is Part of the Product

Screenshots should represent real functionality.

The description should accurately describe the released version.

The app name and icon should not impersonate another brand.

Apple’s current guidelines prohibit copying another developer’s app identity and using another developer’s brand, product name, or icon without permission. (Apple Developer)

Google has its own impersonation, intellectual-property, spam, and listing policies.

Do not build launch creative independently from the product team.

Hardware-Dependent Apps Need Reviewer Context

Suppose the app requires:

• Bluetooth medical hardware

• Warehouse scanner

• Vehicle

• IoT device

• Specialized camera accessory

A reviewer may not have that hardware.

Apple tells developers to provide information needed to review hard-to-replicate environments and may request a video or hardware depending on the case. (Apple Developer)

Explain the dependency before the reviewer gets stuck.

Location-Limited Apps Need a Review Path Too

The same issue appears when functionality works only:

• In Los Angeles

• At a customer site

• Inside a private corporate network

• During an event

• At a specific physical venue

The review build should provide an authorized way for reviewers to understand and evaluate the functionality.

Do not hide the dependency.

TestFlight Is Not App Store Approval

A TestFlight build working perfectly does not mean the production App Store version automatically complies with every review requirement.

Likewise, an Android app working on an internal or closed testing track does not guarantee production policy approval.

Beta distribution tests software.

Store review evaluates the submitted product and its policy context.

React Native and Flutter Are Not Rejection Reasons

Apple and Google do not reject an app simply because it uses React Native, Flutter, Expo, or another legitimate cross-platform framework.

What reviewers see is the resulting product:

• Does it work?

• Does it follow policy?

• Does it respect the platform?

• Is privacy handled correctly?

• Does the experience make sense?

SimplyRem’s current mobile practice publicly lists React Native, Swift, Kotlin, and Expo and builds for both iOS and Android. (SimplyRem)

Cross-platform is an engineering decision—not an automatic review failure.

Google’s Current Android Target API Requirement Changed Again

This is one of those requirements you should verify every release.

Current requirement as of September 3, 2026: new apps and app updates submitted to Google Play generally must target Android 16, API level 36 or higher, starting August 31, 2026.

Wear OS and Android Automotive OS submissions must target API 35 or higher. Android TV and Android XR follow separate requirements, currently API 34 or higher. Google also applies availability requirements to older existing apps. (Google Help)

Do not copy last year’s API target into an evergreen checklist.

Security Problems Can Become Review Problems Too

Review before release for:

• Hardcoded secrets

• Insecure transport

• Weak authentication

• Unnecessary permissions

• Sensitive data in local storage

• Exposed tokens

• Internal stack traces

• Excessive logging

Apple’s guidelines require appropriate measures to prevent unauthorized use, disclosure, or access to user information. (Apple Developer)

A perfect privacy policy cannot rescue an implementation that sends user information somewhere the policy never mentioned.

Accessibility Belongs in the Release Process

Review:

• VoiceOver

• TalkBack

• Dynamic Type / larger text

• Labels

• Focus

• Contrast

• Touch targets

• Reduce Motion where relevant

Not every accessibility defect automatically causes rejection.

But accessibility is part of producing a professional mobile product.

SimplyRem’s current mobile and product-design pages explicitly list VoiceOver, TalkBack, Dynamic Type, Reduce Motion, and accessibility work as part of its published mobile capability. (SimplyRem)

Platform-Specific UX Still Matters With Shared Code

Shared code does not mean identical behavior.

The iOS build should respect iOS conventions.

The Android build should respect Android conventions.

Pay attention to:

• Navigation

• Back behavior

• Gestures

• Permission flows

• Controls

• Keyboard behavior

• System sheets

One codebase can still produce two platform-appropriate experiences.

Do a Submission Dry Run

Before official submission, give the release build to somebody who was not deeply involved in development.

Give them:

• Fresh phone

• Store description

• Reviewer credentials

• Review instructions

Ask them to:

1. Install it.

2. Register.

3. Log in.

4. Use every major feature.

5. Deny permissions.

6. Recover the account.

7. Test account deletion.

8. Test the paid flow where appropriate.

9. Use a weaker network.

10. Compare the actual app with the screenshots and description.

Anything confusing to that person may also confuse a reviewer.

What to Do When You Receive a Rejection

A rejection usually isn’t the end of the project.

The important thing is understanding what the reviewer actually found.

Use this process:

1. Read the entire review message.

2. Identify the exact guideline or policy cited.

3. Reproduce the issue yourself.

4. Reopen the current official policy.

5. Decide whether the issue is code, UX, metadata, privacy, payments, access, or a misunderstanding.

6. Fix the underlying problem.

7. Test again.

8. Update reviewer notes.

9. Provide relevant evidence or explanation.

10. Resubmit.

Fix the underlying issue, not just the sentence in the rejection email.

Do Not Start by Fighting the Reviewer

If the reviewer found a real bug, fix it.

If they could not log in, fix access.

If the privacy declaration is inaccurate, correct it.

If the app already complies and the problem is misunderstanding, respond calmly with:

• The exact path

• Relevant screenshots

• Clear explanation

• Current guideline

• Any documented exception

Apple lets developers communicate with App Review through App Store Connect and appeal to the App Review Board when they disagree with the outcome. (Apple Developer)

Google likewise provides an appeal process for enforcement actions through Play Console/support. (Google Help)

An appeal is not a substitute for fixing a legitimate problem.

Never Hide Functionality From Review

Do not build behavior that changes merely to fool the reviewer.

Do not secretly disable prohibited functionality during review and re-enable it after approval.

Apple explicitly warns that attempts to trick the review process can result in serious developer-program consequences. (Apple Developer)

Build the submitted product honestly.

Rejection, Removal, and Account Enforcement Are Different

Rejection

The submitted version is not approved for release.

Removal

A previously available application can be removed from distribution.

Account Enforcement

More serious or repeated policy problems can result in broader action against an app or developer account depending on the platform and circumstances.

Do not treat every ordinary rejection as an existential event.

Also do not repeatedly resubmit a known violation without understanding it.

Approval Is Not the End

A release that passes today can require changes later because:

• iOS changes

• Android changes

• Target API requirements change

• Privacy requirements evolve

• SDKs change

• Business model changes

• Store policies change

• New device classes appear

Google’s 2026 target-API change is a good example of why last year’s valid build may not meet this year’s submission requirement. (Google Help)

Maintain:

• Store metadata

• Privacy declarations

• SDKs

• Dependencies

• Account flows

• Payments

• Crash monitoring

• Security

• Accessibility

• OS compatibility

SimplyRem’s current mobile practice publishes TestFlight and Play Internal Track builds during development, privacy-manifest and Data Safety preparation, App Tracking Transparency handling, App Store and Play Store submissions, reviewer/rejection support, crash work, and ongoing post-launch maintenance. (SimplyRem)

Do Not Make the Marketing Launch Date Depend on Perfect Review Timing

You can plan.

You can prepare.

You cannot control every store-review variable.

Avoid irreversible public promises that assume the review will happen on your exact preferred schedule.

Apple and Google review times vary depending on submission, account, policy area, complexity, and whether follow-up is needed.

Build uncertainty into the launch plan.

The Most Expensive Mistake: Reading Policies After the App Is Finished

That can force redesign of:

• Authentication

• Account deletion

• Payments

• Permissions

• UGC

• Privacy

• Data architecture

App review begins while the product is being designed—not when the developer clicks Submit.

That is the main lesson.

How SimplyRem Can Help

SimplyRem’s current Mobile App Development service publicly verifies iOS, Android, React Native, Swift, Kotlin, Expo, offline workflows, backend APIs, accessibility, App Tracking Transparency, privacy manifests, App Privacy work, Google Data Safety forms, TestFlight, Play Internal Track testing, App Store and Google Play submission, and rejection appeals. (SimplyRem)

Its UI/UX practice covers platform-appropriate mobile design and accessibility. Its Cybersecurity & Audits practice covers application-security review, while Cloud & DevOps and Web Application Development cover backend, API, release, monitoring, and infrastructure concerns around the mobile product. (SimplyRem)

The easiest App Store rejection to fix is the one you prevent during product design. SimplyRem approaches submission as part of the build process—testing the release flow, reviewing privacy and permissions, preparing store metadata and reviewer access, and making sure the app is ready for both the user and the reviewer.

Conclusion

A successful mobile-app submission is not just a working binary.

It is a complete product, a clear store listing, an accurate privacy story, an understandable business model, and a review experience that gives Apple or Google what they need to evaluate the app.

Before clicking Submit, prepare:

Functionality → Privacy → Permissions → Accounts → Payments → Metadata → Reviewer Access → Security → Testing

No single checklist guarantees approval.

But treating review as part of product development puts the team in a much better position than discovering the rules after launch day has already been announced.

Apple Review Overview Card

Apple App Review

What Apple reviews

Safety, performance, business model, design, privacy/legal requirements, metadata, functionality, and the overall submitted experience. (Apple Developer)

Common mistake

Treating App Review as a final binary test.

Prepare

Build store requirements into product, UX, privacy, payments, authentication, and QA before submission.

Google Review Overview Card

Google Play Review

What Google evaluates

Functionality, user data, permissions, monetization, content, app quality, store declarations, target API requirements, and other Developer Program Policies.

Common mistake

Assuming a working internal test build automatically qualifies for production.

Prepare

Review current Play policies and Play Console declarations separately from iOS.

App-Completeness Card

App Completeness

Problem

Placeholder screens, dead links, unavailable backend, broken buttons, unfinished features.

Why reviewers care

The submitted application is expected to be ready for customers.

Prepare

Remove temporary content, test production-like infrastructure, verify URLs, and test the release build. (Apple Developer)

Reviewer-Login Card

Reviewer Cannot Log In

Problem

Expired password, OTP requirement, geo-restricted account, manual approval.

Why it matters

The reviewer cannot evaluate core functionality.

Prepare

Provide stable reusable credentials and clear instructions. Apple and Google both explicitly require usable review access when authentication blocks functionality. (Apple Developer)

Review-Notes Card

Review Notes

Use them for

• Demo credentials

• Hidden/non-obvious features

• Special configuration

• Hardware dependencies

• Location restrictions

• Subscription explanation

Avoid

“Everything works.”

Give the reviewer context they cannot infer themselves.

Metadata Card

Store Metadata

Check

• Name

• Subtitle

• Description

• Screenshots

• Promotional copy

• Support URL

• Privacy URL

• Subscription wording

Rule

Represent the submitted product, not the future roadmap.

Minimum-Functionality Card

Minimum Functionality

Apple

Apps should provide an experience beyond a repackaged website or collection of marketing links. (Apple Developer)

Google

Apps must provide meaningful utility and cannot be effectively nonfunctional or extremely limited. (Google Help)

Important

A WebView itself is not an automatic rejection. User value and functionality matter.

Privacy-Policy Card

Privacy Policy

Should explain

• Data collected

• Why

• Use

• Sharing

• Third parties

• Retention

• Deletion

• Contact method

Do not

Paste an unrelated generic template.

Apple App Privacy Card

Apple App Privacy

What Apple expects

Accurate App Store Connect disclosures describing your app and integrated third-party partners.

Common mistake

Engineering adds a new analytics SDK but nobody updates App Privacy.

Check

Compare actual release behavior, SDK privacy reports, and App Store Connect answers. (Apple Developer)

Google Data Safety Card

Google Data Safety

What Google expects

Accurate disclosure of collection, sharing, purposes, and relevant protection practices.

Common mistake

Ignoring data handled by an SDK.

Check

Review every third-party library before submitting the Data Safety form. (Google Help)

Third-Party SDK Card

Third-Party SDKs

Review:

• Analytics

• Crash reporting

• Ads

• Attribution

• Maps

• Login

• Payments

• Push

• AI

Principle

The SDK vendor wrote the code, but your app ships it.

You remain responsible for the resulting store compliance.

Apple Privacy-Manifest Card

Apple Privacy Manifest

File

PrivacyInfo.xcprivacy

Can describe

• Collected data

• Tracking

• Tracking domains

• Required-reason API use

Important

Apple requires valid privacy manifests for SDKs and scenarios covered by its current requirements, and required-reason APIs must have approved reasons. (Apple Developer)

Permission Card

Device Permissions

For every permission ask:

1. Which feature requires it?

2. Why does the user expect it?

3. Is narrower access possible?

4. When should the prompt appear?

5. What happens if the user says no?

Ask in context.

Sensitive Android Permission Card

Sensitive Android Permissions

Extra Play rules can apply to:

• Background location

• Photos/videos

• SMS

• Call logs

• Installed-app visibility

• Other restricted capabilities

Check current policy before each release because these requirements continue to change. (Google Help)

Account-Creation Card

Account Creation

Review:

• Why account is required

• Registration

• Verification

• Recovery

• Privacy

• Deletion

Do not build only “Sign up” and “Sign in.”

Account-Deletion Card

Apple

Account-creating apps must provide a way to initiate deletion within the app. (Apple Developer)

Google

Account-creating apps require an in-app deletion path and an external web deletion resource. (Google Help)

Remember

Deactivate ≠ delete.

Sign in with Apple Card

Social Login

Apple Guideline 4.8 can require an equivalent privacy-preserving login option when certain third-party/social login providers authenticate the primary account.

Review the current guideline against the actual login architecture rather than applying a blanket rule. (Apple Developer)

Apple IAP Card

Apple In-App Purchase

Digital features/content

Apple generally requires IAP when unlocking digital functionality, subject to current storefront, entitlement, and category exceptions. (Apple Developer)

Physical goods/services

Follow separate payment rules.

Google Play Billing Card

Google Play Billing

Digital content/features/services

Play Billing is generally required for Play-distributed in-app digital purchases unless an exception applies.

Physical goods/services

Are treated separately and generally should not use Play Billing. (Google Help)

Subscription Card

Subscription

Show clearly:

• Price

• Billing period

• Trial

• Renewal

• Included functionality

• Management/cancellation path

Do not make the user reverse-engineer what they are buying.

UGC / Moderation Card

User-Generated Content

Potential requirements include:

• Terms

• Reporting

• Blocking

• Moderation

• Abuse response

• Contact information

Both Apple and Google impose specific controls around UGC. (Apple Developer)

Children / Family-Policy Card

Apps for Children

Review separately for:

• Data

• Ads

• SDKs

• Age targeting

• Content

• Parental controls

• Privacy

Do not treat a child-directed app as an ordinary consumer app with a younger color palette. (Apple Developer)

AI-App Card

Generative AI

Review:

• What user data leaves the device

• Which provider receives it

• Consent/disclosure

• Harmful outputs

• Moderation

• Reporting

• Privacy policy

Apple now explicitly addresses personal data shared with third-party AI, while Google has clarified its User Data rules for third-party AI integrations. (Apple Developer)

ATT / Tracking Card

App Tracking Transparency

ATT applies when Apple’s definition of tracking across other companies’ apps/sites is met.

Do not assume:

analytics = tracking

Audit the real data use. (Apple Developer)

Android Target-API Card

Current Requirement — September 3, 2026

New Android apps and updates on Google Play generally need to target:

Android 16 / API 36+

Current exceptions:

• Wear OS: API 35+

• Android Automotive OS: API 35+

• Android TV: API 34+

• Android XR: API 34+

Google also applies separate availability requirements to existing older apps. (Google Help)

Security Card

Security

Review:

• Hardcoded secrets

• Authentication

• Sensitive local storage

• TLS/networking

• Authorization

• Excess permissions

• Logs

• Tokens

• Error screens

Privacy statements and implementation must match.

Device-Testing Checklist

•  Small phone

•  Large phone

•  Recent OS

•  Minimum supported OS

•  Fresh installation

•  Existing installation

•  Slow network

•  Offline transition

•  Dark mode where relevant

•  VoiceOver / TalkBack

•  Larger text

•  Permission denial

•  Background/foreground transitions

Fresh-Install Checklist

•  No existing login

•  No cached data

•  No pre-approved permissions

•  Production configuration

•  Registration works

•  Login works

•  Password recovery works

•  Permissions make sense

•  Initial sync works

•  Empty states work

•  Account deletion is reachable

Apple Pre-Submission Checklist

Functionality

•  Final release build

•  No crashes

•  Backend running

•  Links work

•  Purchase flows work

Review Access

•  Demo account

•  Non-expiring credentials

•  Useful Notes for Review

•  Hardware/location explanation

Privacy

•  Privacy policy

•  App Privacy reviewed

•  SDK behavior reviewed

•  Privacy manifests valid

•  Required-reason APIs declared

•  SDK signatures handled where required

•  ATT reviewed where relevant

Accounts

•  Registration

•  Login

•  Recovery

•  Deletion

•  Social-login requirement checked

Metadata

•  Screenshots accurate

•  Description accurate

•  Support URL works

•  Privacy URL works

Google Pre-Submission Checklist

Technical

•  Final App Bundle

•  Installs

•  Loads

•  No freezes

•  Production configuration

•  Current target API requirement met

Play Console

•  Data Safety

•  Privacy policy

•  Content rating

•  Target audience

•  Ads declaration

•  Restricted-permission declarations

•  App-content declarations

Accounts

•  Reviewer credentials work

•  Account deletion

•  External deletion link

•  Recovery flow

Store Listing

•  Screenshots accurate

•  Description accurate

•  Category correct

•  Contact details current

Privacy Checklist

•  List every data type collected.

•  Identify why each type is collected.

•  Identify each third party.

•  Review analytics.

•  Review crash reporting.

•  Review advertising.

•  Review authentication.

•  Review maps/location.

•  Review AI providers.

•  Review retention.

•  Review deletion.

•  Compare privacy policy.

•  Compare Apple App Privacy.

•  Compare Google Data Safety.

The three disclosure surfaces should not contradict each other.

Account Checklist

•  Is login really required?

•  Registration works.

•  Email/phone verification works.

•  Password reset works.

•  MFA works if used.

•  Sessions expire correctly.

•  Account recovery works.

•  Account deletion works.

•  Associated data deletion is understood.

•  Retained data is explained.

•  Reviewer access works.

Permission Checklist

For every permission ask:

1. Which feature needs it?

2. Is that feature currently available?

3. Is the permission part of core functionality?

4. Is narrower access possible?

5. When will the prompt appear?

6. What happens if the user denies it?

7. Does the listing explain the feature?

8. Does a third-party SDK request the permission?

Payment Checklist

•  Digital or physical?

•  Which store rules apply?

•  Which storefront/region rules apply?

•  Is pricing visible?

•  Are subscription terms clear?

•  Are products configured?

•  Does test purchase work?

•  Does entitlement update correctly?

•  What happens after cancellation?

•  Can eligible purchases be restored where required?

Reviewer-Experience Checklist

A reviewer should understand:

•  What the app does.

•  How to log in.

•  How to reach every major feature.

•  How paid functionality works.

•  Why sensitive permissions exist.

•  What hardware is needed.

•  Whether location restrictions exist.

•  What test data to use.

Without emailing your developer for basic instructions.

Before-Submission Vertical Flow

Product Review

↓

Current Policy Review

↓

Privacy / SDK Review

↓

Device Testing

↓

Fresh-Install Testing

↓

Account / Payment Testing

↓

Store Metadata Review

↓

Reviewer-Access Test

↓

Submit

Rejection-Response Flow

Read

↓

Identify the cited policy

↓

Reproduce

↓

Reopen current official guidance

↓

Fix or clarify

↓

Test again

↓

Update reviewer notes

↓

Resubmit

↓

Document the lesson

Fix-vs.-Appeal Decision Path

Can you reproduce the problem?

Yes → Fix it.

No → Continue.

↓

Does the cited policy clearly apply?

Yes → Adapt the product or submission.

Unclear → Re-read official documentation.

↓

Does the product comply but the reviewer could not reach the feature?

Improve access and explain clearly.

↓

Is there a documented exception that applies?

Provide concise evidence.

↓

Does the disagreement remain unresolved?

Consider the formal appeal process.

Common Rejection Cards

App Crashes

Reviewer sees: app closes or freezes.

Fix: reproduce against the release build, fix, and fresh-install test.

Reviewer Cannot Log In

Reviewer sees: authentication wall.

Fix: stable demo credentials and clear instructions.

Privacy Disclosure Does Not Match

Reviewer sees: app/SDK behavior inconsistent with store disclosure.

Fix: audit implementation and correct disclosure or behavior.

Account Cannot Be Deleted

Reviewer sees: account creation with no compliant deletion path.

Fix: implement platform-appropriate deletion.

Permission Is Not Justified

Reviewer sees: sensitive access unrelated to visible functionality.

Fix: remove, narrow, or properly justify the permission.

Payment Flow Is Wrong

Reviewer sees: digital purchase routed through a noncompliant mechanism.

Fix: review current storefront-specific payment policy.

App Is Mostly a Website

Reviewer sees: little mobile-specific utility.

Fix: solve the product-value issue rather than adding decorative native features.

Store Listing Is Misleading

Reviewer sees: screenshots or claims that do not match the build.

Fix: make metadata truthful.

SDK Creates a Policy Problem

Reviewer sees: undeclared data behavior, permission, privacy-manifest, or SDK issue.

Fix: update, remove, reconfigure, and update disclosures.

Android Target API Is Stale

Reviewer sees: submission below current requirement.

Fix: update target SDK and test behavior changes.

UGC Has No Safety Controls

Reviewer sees: posting/messaging without reporting, blocking, or moderation.

Fix: implement required safety functionality.

Good / Caution / High Risk Submission Cards

Good

• Stable release build

• Backend available

• Reviewer credentials tested

• Privacy reviewed

• Permissions justified

• Deletion implemented

• Payments tested

• Metadata accurate

• Current SDK/API requirements

• Release checklist complete

Caution

• Test account occasionally fails

• New SDKs added recently

• Privacy answers not re-reviewed

• Subscription changed at the last minute

• Review notes vague

• Only one device tested

High Risk

• Crashes

• Reviewer cannot reach core features

• Fake/outdated screenshots

• No functioning privacy policy

• Undeclared data collection

• Missing required deletion

• Unnecessary sensitive permissions

• Noncompliant payment flow

• Stale Android target API

• Duplicate/template app with almost no unique value

These are illustrative operational signals, not an official Apple or Google scoring system.

Submission Dry-Run Checklist

Give a fresh build to somebody outside the development team.

Ask them to:

•  Install from scratch.

•  Read the store description first.

•  Log in with reviewer credentials.

•  Register a new account.

•  Use every major feature.

•  Deny permissions.

•  Recover the account.

•  Test purchase where relevant.

•  Delete the account.

•  Use a slow network.

•  Compare screenshots against the app.

•  Write down anything confusing.

Mobile App Release Runbook

Document:

• Build/version

• Release environment

• Backend release

• Store metadata

• Privacy declarations

• Reviewer account reference

• Screenshots

• Payment products

• Release owner

• Release notes

• Known limitations

• Monitoring

• Hotfix/rollback approach

Do not include passwords or secrets in the runbook.

Post-Launch Maintenance Checklist

•  iOS release compatibility

•  Android release compatibility

•  Android target API deadlines

•  SDK updates

•  Privacy changes

•  Store-policy changes

•  Crash trends

•  Security

•  Accessibility

•  New device layouts

•  Metadata

•  Screenshots

•  Support URL

•  Privacy URL

•  Account deletion

•  Payment behavior

Common Submission Mistakes

Finish the App, Then Read Store Rules

Can force expensive redesign of payments, login, privacy, or account deletion.

Test Only Developer Devices

Cached state hides first-run problems.

Ask for Every Permission at Launch

Users and reviewers cannot understand the purpose.

Trust SDK Defaults

Third-party behavior can change privacy and permission obligations.

Give Reviewers Vague Notes

A reviewer should not reverse-engineer your workflow.

Never Test Account Deletion

It is a real product flow, not a policy checkbox.

Assume Apple Approval Means Google Will Approve

Different platforms. Different policies. Different submission preparation.

Set an Irreversible Launch Date Before Review

Review includes external uncertainty.

Resubmit Without Understanding the Rejection

You may repeat the same problem and waste more time.

Frequently Asked Questions

Why does Apple reject mobile apps?

Apple can reject an app when the submitted product does not meet its current App Review Guidelines. Common reasons include crashes, incomplete features, inaccessible reviewer accounts, privacy problems, inaccurate metadata, account-deletion issues, payments, permissions, minimum functionality, user-generated content, and other safety, business, design, or legal requirements.

Why does Google Play reject apps?

Google Play can reject a submission when the app or Play Console declarations violate current Developer Program Policies. Common issues include crashes, limited functionality, inaccurate Data Safety information, restricted permissions, missing account deletion, payment-policy problems, content issues, target API requirements, reviewer-access problems, and misleading store information.

Can an app be rejected even if it works?

Yes. A technically functional app may still have privacy, permission, payment, metadata, account, content, or review-access problems. Store review asks more than “does this binary launch?” Apple and Google evaluate the broader submitted product and its policy compliance.

Does my app need a privacy policy?

For App Store and Google Play distribution, plan on having a real privacy policy that accurately describes the product. Apple requires one in App Store Connect and within the app, while Google requires a privacy policy linked through Play Console and available within the app. It should reflect actual data and third-party practices. (Apple Developer)

What are Apple Privacy Nutrition Labels?

They are the App Store product-page disclosures generated from the App Privacy information developers provide in App Store Connect. They describe certain categories of data collection and use. Developers are responsible for considering both their own code and third-party partners and keeping the disclosure current. (Apple Developer)

What is Google Play Data Safety?

Data Safety is Google Play’s store disclosure about how an app collects, shares, and protects user data. Developers complete the Data Safety form in Play Console and must include relevant behavior from third-party SDKs. Google reviews the submitted information as part of the Play process. (Google Help)

Can a third-party SDK cause my app to be rejected?

Yes. An SDK can introduce data collection, permissions, privacy-manifest requirements, security issues, or known policy problems. Apple and Google both place responsibility on the application developer for code and SDKs included in the submitted product.

Does my app need account deletion?

If users can create an account, account deletion is a major requirement on both stores. Apple requires users to be able to initiate account deletion within the app. Google requires an in-app deletion path and, for apps within scope, an external web resource for requesting account deletion and associated-data deletion. (Apple Developer)

Does my app need Sign in with Apple?

Not every app does. Apple Guideline 4.8 applies in specified situations where certain third-party or social login services are used for the app’s primary account. Review the current guideline and its exceptions against the actual authentication design rather than applying a blanket rule. (Apple Developer)

Why would Google reject an Android permission?

Google can reject or block an app when sensitive or restricted permissions are unnecessary, insufficiently justified, improperly declared, or inconsistent with the app’s core functionality. Background location, broad photo/video access, SMS, Call Log, and installed-app visibility are examples of areas with additional requirements. (Google Help)

Can Apple reject a WebView app?

Yes, if the resulting product does not provide enough app-specific value, but WebView technology itself is not an automatic rejection. Apple Guideline 4.2 says applications should offer functionality, content, and UI beyond a repackaged website. Evaluate the actual utility of the app. (Apple Developer)

Can Google reject an app with limited functionality?

Yes. Google Play’s Functionality, Content, and User Experience policy prohibits apps with very limited utility, apps that effectively do nothing, and apps that fail to install, load, respond, or function normally. (Google Help)

Why was my subscription rejected?

Subscription problems can come from payment-policy design, incomplete store configuration, unclear pricing or renewal terms, broken entitlement handling, or a reviewer being unable to complete the test flow. Review both the store policy and the actual subscription UI/configuration before resubmitting.

When do apps need Apple In-App Purchase?

Apple generally requires In-App Purchase when users unlock digital functionality or content inside the application, subject to current category, storefront, and regional exceptions. Physical goods and real-world services use different payment rules. Always verify Guideline 3.1 for the storefronts where the app is distributed. (Apple Developer)

When do Android apps need Google Play Billing?

Play-distributed apps generally need Google Play Billing when charging for in-app digital goods, digital services, subscriptions, or functionality unless an applicable policy exception applies. Physical goods and many physical services are treated differently. (Google Help)

What Android target API level is currently required?

As of September 3, 2026, new mobile apps and app updates submitted to Google Play generally must target Android 16, API level 36 or higher. Wear OS and Android Automotive OS currently use API 35 or higher, while Android TV and Android XR have separate API 34 requirements. (Google Help)

Can React Native or Flutter apps be approved?

Yes. Cross-platform technology itself is not a rejection reason. The resulting app still needs to meet store requirements for functionality, privacy, user experience, permissions, payments, security, metadata, and platform compatibility.

Can an AI app be rejected?

Yes, but not simply because it uses AI. AI applications still need to comply with privacy, content, safety, data-sharing, and other platform requirements. Apple currently requires explicit disclosure and permission around personal data shared with third-party AI, while Google maintains specific AI-generated-content rules. (Apple Developer)

Can I appeal an Apple or Google rejection?

Yes, when you have a legitimate basis to dispute the decision. Apple provides communication with App Review and a formal App Review Board appeal path. Google provides appeal routes for Play enforcement decisions. Appeals are most useful when the product already complies or a policy/application fact was misunderstood. (Apple Developer)

How should I respond to an app rejection?

Read the entire message, identify the cited policy, reproduce the issue, reopen the current official guidance, and decide whether the problem is technical, product, privacy, metadata, payments, reviewer access, or misunderstanding. Fix the underlying issue, test it, explain the correction clearly, and then resubmit.

How long does App Store review take?

There is no review duration you should treat as guaranteed. Timing varies by submission and whether Apple needs clarification, another build, policy documentation, or follow-up. Plan the marketing launch with review uncertainty rather than making a public commitment dependent on approval at an exact hour or day.

How long does Google Play review take?

Google Play review time also varies. New apps, updates, policy issues, account history, declarations, and complex review conditions can affect timing. Do not build a launch plan around an assumed universal review duration.

Can SimplyRem handle App Store and Google Play submissions or help after rejection?

Yes. SimplyRem’s current Mobile App Development service publicly includes App Store and Google Play submission, privacy disclosures, privacy manifests, Data Safety forms, screenshots, App Tracking Transparency, TestFlight and Play Internal Track work, and rejection appeals, along with ongoing mobile maintenance. (SimplyRem)

Final SimplyRem CTA

Building an iOS or Android app—or dealing with a rejection you did not expect?

SimplyRem can review the release build, privacy disclosures, third-party SDKs, permissions, account flows, payments, store metadata, reviewer access, and current Apple and Google requirements as part of preparing the next submission. Its current mobile practice covers native iOS and Android, React Native, Swift, Kotlin, Expo, backend integration, accessibility, privacy, store preparation, TestFlight, Play testing, submission, rejection handling, and post-launch maintenance. (SimplyRem)

The goal is not to promise approval.

It is to submit a product that is technically ready, clearly explained, accurately disclosed, and easier for the reviewer to evaluate.