App Store Submission Kit

Common rejection reasons and how to avoid them

Most rejections aren't about clever policy edge cases. They come from a short list of avoidable problems: a crash, a missing login, privacy answers that don't match the app, or metadata that promises something the app doesn't do.

This guide summarises the most common ones in plain language. Section numbers refer to Apple's App Review Guidelines and the policy areas in Google Play's Developer Program Policy. Both documents change, so read the current versions for anything you're unsure about.

---

Both stores

1. The app crashes or doesn't work

Apple: 2.1 App Completeness. Google: broken functionality and minimum functionality.

Reviewers test on real devices, often on the newest OS version, sometimes on iPad even if you designed for iPhone, and often on a fresh install with no data.

Avoid it:

• Test a clean install on the newest OS release and the oldest version you support.
• Test with no network, slow network and airplane mode.
• If the app runs on iPad (iPhone apps can run on iPad by default), test it there.
• Check every link and button, including links to your website, support page and privacy policy.
• Make sure your backend is live and production-ready during review, not a test server that might be switched off.

2. Reviewer couldn't sign in

Apple: 2.1 (information needed). Google: App access.

If any part of the app needs an account, reviewers need one too. This is one of the most common reasons for a delay or rejection.

Avoid it:

• Give a demo account with full access, including paid features, in the review notes.
• Make sure it doesn't need two-factor codes sent to your phone, an invitation, or a specific location.
• Check it still works the day you submit, and don't change its password during review.
• If your app uses hardware or a QR code to log in, provide a demo mode or a video.

Use review-notes-template.md.

3. Privacy answers don't match the app

Apple: 5.1.1 Data Collection and Storage, 5.1.2 Data Use and Sharing. Google: User Data policy, Data safety.

Both stores compare your privacy declarations with what the app and its SDKs actually do. Analytics, crash reporting, ads and login SDKs often collect data you didn't think about.

Avoid it:

• List every SDK in data-inventory.csv and read each one's data disclosure documentation.
• Make your privacy policy, store declarations and in-app behaviour all say the same thing.
• Explain each permission request in plain words at the moment you ask for it.
• Don't make users grant permissions the feature doesn't need.

4. No in-app account deletion

Apple: 5.1.1(v). Google: account deletion requirement.

If users can create an account in your app, they must be able to delete it from inside the app. Google also requires a web page where users can request deletion without the app. Deactivating or hiding an account doesn't count.

Avoid it: Put "Delete account" somewhere easy to find, usually Settings > Account, and explain what gets deleted and what you keep for legal reasons.

5. Misleading or inaccurate metadata

Apple: 2.3 Accurate Metadata. Google: Metadata policy, Store listing and promotion.

Avoid it:

• Screenshots show the real app in use, not only marketing art or features that don't exist yet.
• The description doesn't promise features the app doesn't have.
• No keyword stuffing in the name, subtitle, keywords or description.
• No other app names, competitor brands or celebrity names unless you have rights.
• On Google Play, the title, icon and developer name contain no emoji, no ranking claims such as "#1" or "best", no price or promotion text such as "free" or "sale", and no all caps unless it's part of your brand.
• On Apple, metadata doesn't mention other mobile platforms or include pricing terms.

6. Too little functionality or a website in a wrapper

Apple: 4.2 Minimum Functionality. Google: minimum functionality and spam policies.

An app that only shows a website, or does very little, is often rejected.

Avoid it:

• Add real native value: offline use, notifications, device features, a better experience than the mobile site.
• Make sure the app is useful on its own, not just a link to somewhere else.

7. Copycat, template or spam apps

Apple: 4.3 Spam. Google: Spam and Impersonation policies.

Many near-identical apps from the same or different developers get rejected. Apps built from templates or generators that look like hundreds of others are at risk.

Avoid it: Make one strong app rather than many variations. Customise design and features meaningfully. Don't imitate another app's name, icon or look.

8. Payments outside the store's billing

Apple: 3.1.1 In-App Purchase. Google: Payments policy.

Digital content and features used inside the app generally have to use the store's in-app purchase system. Physical goods and real-world services (food delivery, taxis, physical shop orders) use normal payment methods.

Avoid it:

• Use in-app purchase or Play Billing for digital unlocks, subscriptions, coins and premium features.
• Rules on linking to outside payment and on alternative billing differ by country, and they've changed recently in the US, EU, South Korea, Japan and elsewhere. Check the current rules for each storefront you distribute in.
• Offer a way to restore purchases.

9. Subscription screens that aren't clear

Apple: 3.1.2 Subscriptions. Google: Subscriptions policy.

Avoid it:

• Show the price and billing period clearly, at least as prominent as any trial or discount.
• Say exactly what's included.
• Say how to cancel.
• Link to your terms and privacy policy from the purchase screen.
• Don't use dark patterns: hidden close buttons, confusing toggles, or pre-selected expensive plans.

10. User-generated content without moderation

Apple: 1.2 User-Generated Content. Google: User Generated Content policy.

Chat, comments, profiles, uploads and machine-made content shared between users all count.

Avoid it: Provide a filter for objectionable content, a way to report content, a way to block abusive users, timely responses to reports and published contact details.

11. Incomplete or placeholder content

Apple: 2.1 and 2.3. Google: minimum functionality.

"Coming soon" screens, filler text, empty states with no data, test content and "beta" labels lead to rejections.

Avoid it: Remove or hide unfinished features. Seed demo content for the reviewer if the app is empty on first launch.

---

Mostly Apple

Third-party login without an equivalent option

4.8 Login Services. If you use a third-party or social login service for the main account, you generally also need to offer another login option that meets Apple's privacy criteria. Sign in with Apple is one such option. There are exceptions, for example when the app only uses your own company's account system. Check the current wording.

Permission purpose strings

5.1.1. Every permission must come with a clear purpose string that explains what it's for. "This app needs your camera" isn't enough. Say what the user gets: "Scan receipts to add them to your expense report."

Tracking without permission

5.1.2. If you track users across other companies' apps and websites, including for targeted ads or sharing with data brokers, you must ask permission with App Tracking Transparency first, and respect the answer.

Using non-public APIs or downloading code

2.5 Software Requirements. Use only public APIs, don't download executable code that changes how the app works after review, and keep the app self-contained.

Kids category

1.3 Kids Category. Apps for children have strict limits on ads, third-party analytics and links out of the app, and need parental gates for purchases and external links.

---

Mostly Google

Restricted permissions without a core-feature reason

SMS, call log, all files access, background location, photos and videos, QUERY_ALL_PACKAGES, accessibility services and exact alarms all have restrictions. Each needs a declaration explaining why it's essential to your app's core feature. If a system picker or a less sensitive API can do the job, Google expects you to use it.

Families policy

If your target audience includes children, ads and SDKs must be from approved programmes, and data collection is restricted.

Target API level too low

Uploads targeting an API level below Google's current requirement are rejected automatically. Update your targetSdkVersion before each annual deadline.

Deceptive behaviour and ads

Apps must do what the listing says, must not imitate system notifications or other apps, and ads must not appear unexpectedly or be hard to close.

---

If you're rejected

1. Read the full message. Both stores say which guideline or policy applies, and often include screenshots.
2. Fix the real issue, not only the screen they mentioned. Reviewers may check more thoroughly next time.
3. Reply clearly. On Apple, reply in App Store Connect with what you changed. On Google, check the policy status page in Play Console.
4. Appeal only if you believe there's a misunderstanding. Be polite, specific and brief. Apple has an App Review Board appeal process. Google has an appeal form linked from the rejection.
5. Keep notes of every rejection and fix, so the next release doesn't repeat it.

Screenshot, icon and video sizes

These tables reflect Apple's and Google's published specifications as of October 2026. Both stores add new device sizes and adjust rules regularly. Check the store's current requirements before you export your final assets:

• Apple: App Store Connect Help, "Screenshot specifications" and "App preview specifications"
• Google: Play Console Help, "Add preview assets to showcase your app"

---

Apple App Store

App icon

| Asset | Size | Format | Notes |
|---|---|---|---|
| App Store icon | 1024 x 1024 px | PNG | No transparency, square corners (the system applies the mask), included in your app's asset catalogue |

Optional dark and tinted icon variants can be added in the asset catalogue.

iPhone screenshots

You need screenshots for at least one large iPhone size. If your interface is the same across devices, provide the largest size and App Store Connect scales it down for smaller devices.

| Display | Portrait sizes (px) | Landscape sizes (px) | Required? |
|---|---|---|---|
| 6.9" | 1320 x 2868, 1290 x 2796, or 1260 x 2736 | 2868 x 1320, 2796 x 1290, or 2736 x 1260 | Provide this or 6.5" |
| 6.5" | 1284 x 2778 or 1242 x 2688 | 2778 x 1284 or 2688 x 1242 | Required if your app runs on iPhone and you don't provide 6.9" |

Smaller iPhone sizes are optional and are scaled from the next size up if you don't provide them. App Store Connect may also list a 6.1" set; check which sets it asks for when you open your version page.

iPad screenshots

| Display | Portrait sizes (px) | Landscape sizes (px) | Required? |
|---|---|---|---|
| 13" | 2064 x 2752 or 2048 x 2732 | 2752 x 2064 or 2732 x 2048 | Required if your app runs on iPad |

Mac screenshots

| Aspect ratio | Sizes (px) | Required? |
|---|---|---|
| 16:10 | 1280 x 800, 1440 x 900, 2560 x 1600, or 2880 x 1800 | Required for Mac apps |

Screenshot rules

| Rule | Value |
|---|---|
| Number per device size | 1 to 10 |
| Formats | `.jpeg`, `.jpg`, `.png` |
| Transparency | Not allowed. Flatten images and remove the alpha channel |
| Content | Must show the app. Marketing captions are fine, but the app's interface should be the focus |

App previews (videos)

| Rule | Value |
|---|---|
| Number per device size | Up to 3 |
| Length | 15 to 30 seconds |
| Content | Footage captured from the app itself |

App previews have their own resolution table per device. Check Apple's "App preview specifications" page for the exact sizes, frame rates and file limits before exporting.

---

Google Play

Icon and feature graphic

| Asset | Size | Format | Notes |
|---|---|---|---|
| App icon | 512 x 512 px | 32-bit PNG (with alpha) | Up to 1,024 KB. Google applies the rounded mask, so design a full square without your own rounded corners or shadow. No badges or text suggesting ranking, price or Play categories |
| Feature graphic | 1024 x 500 px | JPEG or 24-bit PNG (no alpha) | Required. Shown at the top of your listing in some places. Keep important content away from the edges |

Phone screenshots

| Rule | Value |
|---|---|
| Number | At least 2 to publish (across device types), up to 8 per device type |
| Formats | JPEG or 24-bit PNG, no alpha |
| Dimensions | Each side between 320 px and 3,840 px |
| Aspect ratio | The long side can be at most twice the short side |
| Recommended for app promotion | At least 4 screenshots at 1080 px or more: 1080 x 1920 portrait (9:16) or 1920 x 1080 landscape (16:9) |
| Recommended for games | At least 3 landscape screenshots at 1920 x 1080, or portrait at 1080 x 1920 |

Tablet and Chromebook screenshots

| Rule | Value |
|---|---|
| Number | At least 4 if you provide them for large screens |
| Dimensions | Between 1,080 px and 7,680 px |
| Aspect ratio | 16:9 landscape or 9:16 portrait |
| Tip | Avoid text that isn't part of the app, since it may be cropped on some screens |

Wear OS, Android TV, Android Automotive and Android XR have their own screenshot rules. Check the Play Console Help page if you support them.

Preview video

| Rule | Value |
|---|---|
| Format | A YouTube link to a single video (not a playlist or channel) |
| Visibility | Public or unlisted |
| Ads | Monetisation must be off |
| Age restriction | Must not be age-restricted |
| Autoplay | Only the first 30 seconds autoplay, so put the best part first |

---

Export checklist

• Every image is exactly the required pixel size, not just the right aspect ratio.
• Alpha channel removed where transparency isn't allowed (all Apple screenshots, Google screenshots and feature graphic).
• Colour profile is sRGB (or Display P3 for Apple, where supported).
• Status bars are clean: full battery, strong signal, a neutral time, no personal notifications.
• No real customer data, email addresses or phone numbers visible.
• Text on screenshots is large enough to read on a phone listing.
• Screenshots are localised for each language you list in, or at least the captions are.
• File names are ordered (01-home.png, 02-search.png) so upload order is easy.
• Metadata such as location removed from image files before upload.

Privacy worksheet: App Privacy and Data safety

Apple's App Privacy details (often called the privacy nutrition label) and Google Play's Data safety form ask similar questions in different ways. This worksheet helps you answer both from one set of facts.

Answers must cover data collected by your code and every third-party SDK in the app: analytics, crash reporting, ads, login, payments, chat, maps and so on. Wrong answers can lead to rejection or removal, and they affect user trust.

The categories below follow each store's forms as of October 2026. Both forms are updated from time to time, so check the current questions in App Store Connect and Play Console as you fill them in.

---

Step 1: build your inventory

Open data-inventory.csv in any spreadsheet app. The filled rows are examples: keep the ones that apply, correct them, delete the rest, and add one row for every type of data that leaves the device, whether it goes to your servers or to a third party. For each SDK, read its documentation for "data collection", "privacy" or "Data safety". Most large SDK providers publish a page listing exactly what they collect.

Things people often miss:

• Crash reports usually include device identifiers and diagnostic data.
• Analytics SDKs often collect a device or app instance ID.
• Login SDKs collect email and name.
• Ad SDKs often collect advertising ID, approximate location and usage data.
• Customer support chat widgets collect messages and contact details.
• Your own server logs collect IP addresses.

Step 2: key definitions

| Term | Apple | Google |
|---|---|---|
| **Collected** | Data sent off the device in a way that lets you or partners access it for longer than needed to handle the request in real time | Data sent off the device by your app |
| **Shared** | Covered through "used for tracking" and third-party use | Data transferred to a third party. Transfers to service providers processing data on your behalf usually don't count as sharing |
| **Linked to the user** | Data connected to the user's identity, account or device | Not asked in the same way |
| **Tracking** | Linking your data with other companies' data for targeted ads or ad measurement, or sharing it with data brokers | Not a separate question |
| **Ephemeral** | Not a separate question | Data processed only in memory and kept only as long as needed for the request |
| **Optional** | Not a separate question | Whether users can choose not to provide it |

Read each store's full definitions before you answer. These summaries are a guide only.

Step 3: Apple App Privacy

For each data type you collect, answer: what it's used for, whether it's linked to the user's identity, and whether it's used for tracking.

Data types

| Category | Data types | Collected? | Linked? | Tracking? | Purposes |
|---|---|---|---|---|---|
| Contact info | Name, email address, phone number, physical address, other contact info | | | | |
| Health and fitness | Health, fitness | | | | |
| Financial info | Payment info, credit info, other financial info | | | | |
| Location | Precise location, coarse location | | | | |
| Sensitive info | Racial or ethnic data, sexual orientation, pregnancy, disability, religious or philosophical beliefs, union membership, political opinion, genetic or biometric data | | | | |
| Contacts | Contacts | | | | |
| User content | Emails or text messages, photos or videos, audio data, gameplay content, customer support, other user content | | | | |
| Browsing history | Browsing history | | | | |
| Search history | Search history | | | | |
| Identifiers | User ID, device ID | | | | |
| Purchases | Purchase history | | | | |
| Usage data | Product interaction, advertising data, other usage data | | | | |
| Diagnostics | Crash data, performance data, other diagnostic data | | | | |
| Other data | Any other data types | | | | |

Purposes

• Third-party advertising
• Developer's advertising or marketing
• Analytics
• Product personalisation
• App functionality
• Other purposes

Notes

• If you use a payment SDK and don't store card details yourself, check how Apple's guidance treats that data.
• Data collected only in rare, optional cases (for example, a user choosing to send a feedback form) may still need to be declared. Read Apple's guidance on optional disclosure.
• If you answer "used for tracking" for anything, you must also use App Tracking Transparency.

Step 4: Google Play Data safety

Google asks whether you collect or share each data type, then for each one: is it collected, shared or both; is it processed ephemerally; is it required or optional; and what purposes it's used for.

Data types

| Category | Data types | Collected? | Shared? | Ephemeral? | Required or optional? | Purposes |
|---|---|---|---|---|---|---|
| Location | Approximate, precise | | | | | |
| Personal info | Name, email address, user IDs, address, phone number, race and ethnicity, political or religious beliefs, sexual orientation, other info | | | | | |
| Financial info | User payment info, purchase history, credit score, other financial info | | | | | |
| Health and fitness | Health info, fitness info | | | | | |
| Messages | Emails, SMS or MMS, other in-app messages | | | | | |
| Photos and videos | Photos, videos | | | | | |
| Audio files | Voice or sound recordings, music files, other audio files | | | | | |
| Files and docs | Files and docs | | | | | |
| Calendar | Calendar events | | | | | |
| Contacts | Contacts | | | | | |
| App activity | App interactions, in-app search history, installed apps, other user-generated content, other actions | | | | | |
| Web browsing | Web browsing history | | | | | |
| App info and performance | Crash logs, diagnostics, other app performance data | | | | | |
| Device or other IDs | Device or other IDs | | | | | |

Purposes

• App functionality
• Analytics
• Developer communications
• Advertising or marketing
• Fraud prevention, security and compliance
• Personalisation
• Account management

Security practices

• Is all user data encrypted in transit? (HTTPS everywhere, including SDKs)
• Can users request that their data be deleted? Give the method.
• Have you committed to the Families policy, if your app targets children?
• Optional: has your app had an independent security review against a recognised standard? Only claim this if it's true and current.

Step 5: cross-check

• Every row in data-inventory.csv appears in both forms.
• Your privacy policy describes the same data, purposes and third parties.
• Permission prompts in the app match the data you declared.
• Account deletion works and matches what you said.
• You've set a reminder to review both forms whenever you add or update an SDK.

Completed by: ______________ Date: ____________ App version: ________