Every App Store Metadata & Listing Audit check

Apple Guideline 2.3.3 and Google Play's Misleading Apps policy both treat an inaccurate description as grounds for rejection — no appeal, no second chance on that submission cycle. Beyond rejection, a description that promises features the codebase doesn't deliver generates one-star reviews from users who installed expecting 'AI-powered recommendations' and found none. App stores use conversion rate and review velocity as ranking signals; a misleading description poisons both. The damage compounds: each failed submission adds days to your launch, and each negative review permanently anchors your rating.

Why this severity: Critical because Apple and Google both reject on discovery, making an inaccurate description a hard launch blocker with no runtime workaround.

Apple Guideline 2.3.7 and Google Play's Spam and Minimum Functionality keyword-spam policy both result in rejection when competitor names or stuffed keywords are detected. On the App Store, the 100-character keyword field is machine-parsed; exceeding it causes an automatic metadata validation failure before a human reviewer sees your app. On Google Play, keyword stuffing in the description triggers algorithmic suppression — your app ranks lower for every keyword it over-repeats, precisely the opposite of the intended effect. Using a competitor's trademark ('Spotify', 'Headspace') as a keyword additionally exposes the developer to trademark infringement claims under Lanham Act theories.

Why this severity: High because keyword violations cause automatic submission rejection on App Store and algorithmic ranking suppression on Google Play, directly blocking discoverability.

Screenshots that show a more polished UI than the shipping build, marketing renders dressed up as device captures, or features absent from the codebase trigger App Store rejections under Guideline 2.3.3 (Accurate Metadata). Users who install based on inaccurate screenshots leave 1-star reviews within the first session, tanking conversion and store ranking. Missing required device sizes (6.5 inch iPhone, 12.9 inch iPad) block submission outright before review even begins.

Why this severity: High because inaccurate or missing screenshots are a top-five App Store rejection cause and a documented 2.3.3 violation.

Apple's binary validation runs before any human reviewer sees the app. A 1024×1024 marketing icon with an alpha channel fails binary validation immediately — the submission is rejected with a cryptic asset error, not a guideline violation, which means no appeal pathway. Badge overlays ('FREE', '#1', 'Award') violate Apple Guideline 2.3.6 and trigger rejection during human review. Shipping the default Expo or React Native framework icon signals an unfinished product, increasing the likelihood of rejection on subjective 'minimum functionality' grounds. On Android, a missing `ic_launcher_round.png` causes visual corruption on adaptive-icon-capable devices running Android 8+.

Why this severity: Medium because the failure mode is a blocking submission error rather than a security or data integrity issue, but it halts every release cycle.

Apple Guideline 4.1 (Impersonation) and Google Play's Impersonation Policy both classify confusingly similar names or icon designs as grounds for immediate rejection. Beyond rejection, trademark holders (Spotify AB, Meta Platforms, Block Inc.) routinely file intellectual property claims against infringing apps through Apple's and Google's dispute processes, which can result in forced removal, developer account termination, and civil litigation under Lanham Act §32. A bundle ID containing a competitor's name (e.g., `com.dev.uberclone`) is discoverable by the trademark holder in App Store search and accelerates claim filing.

Why this severity: Critical because impersonation triggers rejection, developer account risk, and potential trademark litigation — all three simultaneously and without warning.

Release notes reading "Bug fixes and improvements" signal abandonment to returning users and erode update-opt-in rates, which App Store Connect surfaces in your analytics and uses indirectly in ranking. Worse, release notes that describe features not present in the shipping build violate App Store Review Guideline 2.3.1 (Accurate Metadata) and can trigger rejection on a point release that would otherwise pass review.

Why this severity: Low because generic release notes rarely cause rejection directly; impact is on retention and reviewer goodwill.

Apple's App Store metadata validation automatically rejects any subtitle exceeding 30 characters — this happens in seconds during upload, before a reviewer ever opens the app. A subtitle that repeats the app name wastes the 30-character conversion slot Apple gives you, and Apple's guidelines (Guideline 2.3.1) prohibit pricing information in subtitles. On Google Play, the 80-character short description is the primary text shown in search results; an inaccurate or over-limit short description reduces click-through rate and may trigger manual review for misleading content.

Why this severity: Low because the failure is a metadata validation error rather than a security or data risk, correctable in minutes with a new submission.

Missing demo credentials is one of the top five App Store rejection causes for apps with authentication. Apple reviewers will not create an account, will not guess a password, and will not use Google or GitHub OAuth (they have no access to those identity providers). A submission that requires login without working demo credentials is rejected under Guideline 2.1 (App Completeness) within 24-48 hours, wasting a review cycle and pushing launch dates back by a week or more.

Why this severity: Critical because it guarantees submission rejection under Guideline 2.1 whenever the app gates functionality behind authentication.

App Store and Play Store reviewers spend roughly five minutes evaluating each submission. Apps with Bluetooth, AR, NFC, background location, subscriptions, or unusual onboarding flows that ship without review notes frequently get rejected under Guideline 2.1 (App Completeness) because the reviewer cannot reach the core feature in the time they allocate. Generic notes like "Hope you enjoy our app" do not count — they provide zero navigational guidance and still trigger rejection.

Why this severity: Medium because missing or empty notes materially raise rejection risk for non-trivial apps but rarely affect simple single-purpose apps.

The `ITSAppUsesNonExemptEncryption` key in `Info.plist` is required by the US Bureau of Industry and Security (BIS) under the Export Administration Regulations (EAR). Apple enforces this during upload to App Store Connect — if the key is missing, the submission process stops and requires manual resolution in App Store Connect's compliance section. Declaring `true` incorrectly (claiming non-exempt encryption when only standard HTTPS is used) can trigger BIS filing requirements that the developer is not equipped to fulfill, creating ongoing regulatory exposure. Most apps qualify for the exemption under EAR §740.17(b)(1) and should declare `false`.

Why this severity: Medium because an absent or incorrect declaration blocks App Store submission and creates regulatory risk under US export law, but is resolved by a single configuration line for most apps.

Using unlicensed content — a commercially-licensed font TTF file distributed without a mobile app license, a stock photo with a watermark removed, background music without a synchronization license — violates copyright law (17 U.S.C. §501) and supply chain integrity (CWE-1357). App stores reject apps containing clearly infringing assets when detected during review, and rights holders can file DMCA takedowns post-publication that force removal within 24 hours. Commercial font licenses for desktop typically explicitly exclude app distribution; Proxima Nova, Gotham, and Helvetica Neue each require separate mobile licensing agreements costing hundreds to thousands of dollars annually.

Why this severity: High because unlicensed assets expose the developer to copyright infringement claims, DMCA takedowns, and forced app removal — each of which disrupts active users.

App Store Connect rejects preview videos that exceed 30 seconds, show web-based content, include third-party service UIs rather than in-app captures, or contain licensed audio without distribution rights — all under Guideline 2.3 (Accurate Metadata). A rejected preview video blocks the entire submission, not just the video asset, so a 31-second clip or a screencast labelled `marketing-promo.mp4` costs a full review cycle.

Why this severity: Info because the preview video is optional; rejection only fires when a non-compliant video is actively submitted.

A missing `NSHealthShareUsageDescription` in `Info.plist` does not cause rejection — it causes a runtime crash the moment the app requests HealthKit permission on a user's device. This crash reaches production users if it somehow passes App Store review (possible if reviewers don't trigger the health flow). Under HIPAA §164.502 and GDPR Art. 13, health data has the highest protection tier; collecting it without a documented privacy policy describing the data type, purpose, and sharing parties exposes the developer to regulatory action by HHS (US) or a supervisory authority (EU), with fines up to 4% of global annual turnover under GDPR.

Why this severity: Medium because the failure causes a confirmed runtime crash on health permission request and creates HIPAA/GDPR regulatory exposure for sensitive health data collection.

Google Play requires every app targeting Android — including apps with zero financial features — to complete a Financial Features declaration in the Play Console before publication. Skipping this step blocks promotion to the production track entirely; it is not a soft warning. For apps with in-app purchases (React Native IAP, RevenueCat, Stripe), an incomplete declaration is treated as a policy violation under Google Play's Financial Services policy, which can result in app removal and developer account suspension. Developers who discover this requirement the night before a launch date lose 48–72 hours to Play Console processing time.

Why this severity: High because an incomplete financial features declaration is a hard publication blocker on Google Play with no emergency bypass — discovering it at launch costs days.

Apple Guideline 1.1.6 requires apps that generate content using AI to disclose this to users within the app experience. Google Play's AI-Generated Content policy applies additional scrutiny to apps generating realistic images, audio, or video of real people — including mandatory disclosure labels. Enforcement is tightening: as of 2024, Apple has rejected apps that generate AI content without in-app disclosure, and Google Play has added mandatory content labels for AI-generated realistic imagery. Omitting disclosure also undermines user trust when AI limitations (hallucinations, inaccurate outputs) surface, since users have no framework for evaluating AI-generated content they believed was human-curated.

Why this severity: Medium because non-disclosure triggers rejection under Apple Guideline 1.1.6 and Google Play's AI policy, with enforcement expanding across review categories.

Android 14 (API 34) made `android:foregroundServiceType` a hard requirement — a service that starts as a foreground service without a declared type throws a `MissingForegroundServiceTypeException` at runtime and crashes immediately on all Android 14+ devices. As of 2026, Android 14+ accounts for the majority of active Android installs. This is not a review rejection issue; it is a production crash that manifests the moment a user's device upgrades to Android 14. Libraries that depend on foreground services — audio players (`react-native-track-player`), background location (`react-native-background-geolocation`), and background sync (`expo-background-fetch`) — are all affected.

Why this severity: Low as a submission issue because Google Play does not catch it pre-publication, but the runtime crash on Android 14+ devices makes it a production reliability issue at scale.

The 1024x500 feature graphic is a hard publication requirement for Google Play — the Play Console will not let you promote a release to production without it. Apps that declare tablet support in `AndroidManifest.xml` but ship only phone screenshots land in Play's "low quality for large screens" bucket, which demotes them in tablet and Chromebook search results and surfaces a warning banner in the Play Console pre-launch report.

Why this severity: Info because impact is limited to Android discoverability and Play Console pre-launch warnings, not outright rejection beyond the graphic itself.

Apple Guideline 4.8 requires that Sign in with Apple be offered whenever any other social login (Google, Facebook, Twitter) is available in an iOS app. Violation causes rejection. Beyond the guideline, Apple mandates use of its official button component (`AppleAuthenticationButton`) with approved styles — a custom-colored button that calls the Apple auth API but renders as a blue pill violates the Human Interface Guidelines and triggers rejection during review. CWE-284 (Improper Access Control) applies when the requirement is absent entirely: users who want Apple's privacy-preserving login (hide-my-email) are denied that option, pushing them toward more data-exposing alternatives.

Why this severity: High because offering any third-party login on iOS without Sign in with Apple causes automatic rejection under Guideline 4.8, blocking all users from the app.

Google Play enforces a minimum `targetSdkVersion` that advances annually. As of 2026, new app submissions require API 35 (Android 15); existing apps receiving updates require API 34. Submitting below the threshold results in an automated rejection — the Play Console shows a 'Target API level requirement not met' error before any human reviewer sees the app. This is not a lint warning; it is a hard publish block. Additionally, targeting a lower API level disables Android security features that are default-on at higher API levels: scoped storage enforcement, permission upgrade flows, and exact alarm restrictions — each of which affects real user data handling.

Why this severity: Medium because the automated targetSdkVersion check blocks Play Store submission entirely, but the fix is a single build.gradle line plus regression testing.

Google Play has required Android App Bundle (AAB) format for new app submissions since August 2021 and for all app updates since November 2021. Submitting an APK to Google Play for a new app returns an immediate upload error in Play Console — no review occurs, no exception is granted. The build toolchain distinction is subtle: `./gradlew assembleRelease` produces an APK; `./gradlew bundleRelease` produces an AAB. Fastfile lanes that use `gradle(task: 'assemble')` are wrong for Play Store submission. The AAB requirement also means developers must use Google Play App Signing — direct APK signing keys can no longer be used for Play distribution.

Why this severity: Low as an operational issue because the error is explicit and immediate on upload, but it blocks every production deployment until corrected in the build pipeline.

Cross-platform frameworks ship their own submission footguns. Flutter's `version: 1.0.0+1` format in `pubspec.yaml` maps to both `CFBundleShortVersionString` and `CFBundleVersion` — a mismatch blocks TestFlight upload with an opaque error. Expo projects without a fully configured `eas.json` submit profile force manual submission through Transporter, and Capacitor/Ionic apps face heightened Guideline 4.2 (Minimum Functionality) scrutiny because Apple treats thin web wrappers as rejectable.

Why this severity: Info because framework quirks create process friction and occasional upload errors rather than direct policy rejection.

Google Play requires new apps to complete a closed testing track with a minimum of 12 distinct testers for at least 14 consecutive days before the production track becomes available for promotion. Developers who build toward a launch date without accounting for this requirement discover a hard gate in Play Console: the 'Publish app' button for production is disabled regardless of app quality. There is no exception for solo developers, small teams, or apps with existing iOS audiences. This requirement has blocked hundreds of planned launch days since its introduction, with no recourse other than waiting out the 14-day clock.

Why this severity: Info severity because this is a process requirement rather than a code defect, but discovery at launch day causes unavoidable 14-day delays.