As CEO of a software company that builds and deploys apps for multiple clients, app store rejection isn't a one-time headache — it's a recurring risk across every launch. Different clients, different apps, and the same handful of policy details keep tripping submissions up. None of these were bugs in the code. They were policy details that got missed until a reviewer flagged them, and each one meant a launch delay for a client waiting to go live. Here's the list we now audit against before every submission, across every app we ship.
Branding
1. App name and icon must be identical across the app binary and store listing.
If your icon or name changes even slightly between what's built into the app and what's shown on the store page, reviewers flag it as a mismatch. Keep both in sync before every submission — this is one of the easiest rejections to avoid and one of the most common to trigger by accident after a last-minute design tweak.
Account Management
2. If users can create an account, you must provide an in-app account deletion option.
This isn't optional anymore on either store. If your app supports sign-up, it needs a clear, discoverable way to delete that account from within the app itself — not just a support email or a web form. Build this in from the start; retrofitting it after a rejection costs more time than adding it during initial development.
Payments
3. If you use Stripe or any in-app purchase system, you must also support Google Pay and Apple Pay.
Both stores expect their own payment rails to be available alongside third-party processors, especially for digital goods or subscriptions. Skipping this because "Stripe already works" is a common assumption that doesn't hold at review time.
Content & Safety
4. Any feature allowing user-generated content (posts, comments, etc.) must include a "report content" option — this is mandatory under store policy.
If users can post anything visible to others, there needs to be a way to report it. This applies even to minor features like comment sections or reviews that might feel like an afterthought during development.
5. For e-commerce or content apps, users should be able to browse content before login.
Apple in particular expects a "preview first, login if needed" experience. Forcing a login wall before someone can see a single product or piece of content is a frequent rejection trigger — let people browse, and gate the account-required actions (checkout, saving, posting) behind login instead.
Store Listing Accuracy
6. Screenshots on the Play Store/App Store must accurately reflect the actual app experience.
Marketing screenshots that show a redesigned UI, features not yet shipped, or mockups instead of the real app will get flagged. What's in the listing has to match what a user actually opens.
Permissions
7. Permission descriptions must clearly match their actual purpose (e.g., Maps permission, Image Picker permission).
Vague or generic permission descriptions get rejected. If you're requesting location access, the description shown to the user needs to explain specifically why — tied to an actual feature in the app, not a generic boilerplate line.
8. Don't request broad Media/Storage permissions unless your app is heavily media-dependent.
A simple profile picture upload doesn't need full media/storage access — a scoped image picker is enough. Requesting broader access than the feature needs is one of the most common reasons for a permissions-related rejection.
9. Only request permissions your app actually needs — no extras "just in case."
Every permission in the manifest gets scrutinized against what the app visibly does. If a permission isn't tied to a feature a reviewer can find and test, expect a rejection or a request for justification.
Bottom Line
Running a software company that ships apps for multiple clients means app store review isn't a single event you prepare for once — it's a recurring gate every project has to clear. Most rejections aren't about whether the app works; they're about policy details that are easy to overlook when the team is focused on functionality and the client is focused on launch date. Auditing against a list like this before every submission — regardless of which client or which app — is what turned this from a recurring surprise into a routine pre-launch check.
