Mobile Store-Readiness Audit + Pre-Submission Plan

Degree of freedom: HIGH — inventory A–F, score rejection risk, emit a plan. Stay plan-only. No manifest, Data Safety, or listing edits until approved.

This skill vs neighbors

Role: Senior mobile release engineer + store-compliance specialist.

Task: Inventory build/config/listing against checklist A–F, map gaps to store guidelines, phase remediations, emit plan-mobile-readiness.md. Audit & plan only — no manifest, Data Safety, or listing edits until approved.

Catch the rejections before the reviewer does. Change nothing until approved.

How to reason (every plan item)

1. Propose — privacy manifest, usage string, demo account, build, or listing fix
2. Risk — first-pass rejection or a Guideline 4.2 "repackaged website" block
3. Keep-working — platforms/items that already match store rules
4. Phase — Privacy → Functionality → Payments+build → Listing (do not execute)

Worked example

Propose: add PrivacyInfo.xcprivacy for required-reason APIs; align Play Data Safety with the AdMob SDK. Risk: first-pass rejection — missing privacy manifest + Data Safety ↔ permission mismatch. Keep-working: iOS usage-description strings already present for camera/photos. Phase: Phase 1 — Privacy (blocking). Store: iOS 5.1.2 / Play Data Safety; demo account still required in Phase 2 if login-gated.

Apple reviewed over 7.7 M submissions in 2024 and rejected over 1.9 M (about 25%) (Apple Newsroom, May 2025). Many causes are mechanical and pre-detectable: missing privacy manifests, Data Safety ↔ permission mismatches, no demo account, placeholder buttons, crashes on older devices, a stale SDK or target API. Three guidelines catch vibe-coded apps: 4.2 (the app must "elevate it beyond a repackaged website"), 4.2.6 (apps made by a template or app-generation service are rejected unless the content provider submits them), and 2.5.2 (no downloading code that changes features — the OTA question).

When this fires

Trigger phrases: "is my app store-ready", "will Google Play reject this", "pre-submission check", "privacy manifest", "data safety form", "app store rejection", "about to submit my app".

Do not fire for: runtime perf (mobile-rn-performance), screen polish (mobile-rn-screen), or general UI (enhance-capacitor-ui). This owns submission compliance and rejection-risk.

The audit [HIGH freedom]

A · Privacy (#1 modern rejection class)

• iOS privacy manifest — PrivacyInfo.xcprivacy, required-reason APIs, SDK manifests.
• Usage-description strings — every sensitive API has NS*UsageDescription.
• App Tracking Transparency — before ad/tracking SDK calls.
• Android Data Safety — matches actual permissions and SDK collection.
• Third-party SDK disclosure — analytics/ad SDKs in Data Safety.
• Privacy policy URL — live, public, matches collection.

B · Functionality & completeness (4.2 / thin-app)

• Placeholder / TODO UI — cross-hand to plan-stub-checker.
• Too thin / web-view-only — Guideline 4.2 risk; flag honestly. Generated by an

app-builder service and submitted by that service → 4.2.6.

• OTA scope — live updates that add or change features → 2.5.2; detail in

plan-capacitor-hardening pillar 5.

• Demo account — login-gated apps need working creds in review notes.
• Every advertised feature works.

C · Payments

• IAP via store billing — digital goods through StoreKit/Play Billing, not external links.
• IAP products approved and tested with sandbox accounts.

D · Technical / build

• Target API level — Google Play has required targetSdkVersion 36 (Android 16)

for new apps and updates since 2026-08-31 (extension to 2026-11-01 on request). Probe: grep targetSdkVersion android/variables.gradle or the Expo SDK's target.

• iOS SDK — uploads must be built with Xcode 26 and the iOS 26 SDK (since 2026-04-28).
• Age rating — the updated App Store Connect age-rating questions are answered.
• Build format & signing — .aab, release-signed, 64-bit, no debuggable.
• Crash on older devices — emulator-only testing isn't enough.
• Android closed-testing gate — personal developer accounts need a closed test before production (12 testers / 14 days at time of writing); verify the current tester count and duration in Play Console policy at submit time.

E · Listing & metadata

• Screenshots/icon match build; metadata limits; content rating/CSAE.

F · Native feel (4.2 "repackaged website" evidence)

• System chrome — platform tab bar / stack headers, not a JS or HTML bar; 3–5 destinations.
• Edge-to-edge — correct insets on Android 16 (targetSdk 36) and iOS 26+; no opaque status-bar hack.
• Back — Android back closes sheets and pops routes; it never exits from a nested screen.
• Lists virtualize — no blank cells on fling; pull-to-refresh present.
• Feedback — press response on every tappable; haptics on confirm with a settings switch.
• Type — body ≥ 16sp, honors Dynamic Type / fontScale.

A fail here is a rejection risk on its own and the strongest signal for a 4.2 "thin app" verdict. Remediation is workflow-mobile-native-uiux (the enhance-mobile-native-feel pass plus accessibility and device QA).

Procedure [HIGH freedom — plan only]

1. Inventory Capacitor/RN config, manifests, permissions, listing, IAP.
2. Run A–F, map to guidelines. Blocking vs Risk.
3. Score & order by likelihood × launch-delay cost.
4. Phase — privacy + functionality first.
5. Emit `plan-mobile-readiness.md`, then end the turn with a standalone recap in chat: the two or three highest-impact findings and the first phase to approve. The file is the deliverable — write it before the recap.

Guardrails

• Plan only. No manifest, Data Safety, or listing edits.
• Declaration must match reality — both ways.
• Be honest about thin-app / 4.2 risk.
• Never advise external payment for digital goods.
• Verify current target-API thresholds at submit time.
• Real devices, not emulators only.

Self-critique before the burndown [LOW freedom — do not skip]

1. evidenced-not-assumed — manifests, permissions, and listing fields you actually read
2. plan-only — no PrivacyInfo, Data Safety, or metadata edits
3. severity/phase justified — privacy + 4.2 before listing polish
4. right-owner — keywords/screenshots → plan-aso; collection-vs-claimed → plan-privacy-compliance; receipt/restore → audit-monetization-iap; placeholders → plan-stub-checker
5. no-false-safety — do not hide Guideline 4.2 thin-app risk; declaration must match reality both ways

Report template — plan-mobile-readiness.md

# Mobile Store-Readiness Audit — <app>

_Audit-only. Pre-submission. Nothing changes until each phase is approved._

## Scope
- Platform: iOS ☐ Android ☐  | Framework: Capacitor ☐ RN ☐

## Verdict
| Area | Blocking | Risk | Worst item |
|------|----------|------|-----------|
| Privacy | n | n | Data Safety mismatch |
| Functionality | n | n | 4.2 thin web-view app |

## Findings
| # | Item | Store | Guideline | Blocking? | Direction |
|---|------|-------|-----------|-----------|-----------|

## Phased burndown
- **Phase 1 — Privacy** → `mobile-capacitor-platform`
- **Phase 2 — Functionality & 4.2** → `plan-stub-checker` / `workflow-mobile-native-uiux`
- **Phase 3 — Payments & build** → `mobile-capacitor-platform`
- **Phase 4 — Listing & testing gate** → metadata, Android closed-test

## Execution handoff
Real older devices + IAP dry-run before submit.

Chains with

• Launch gates loop — mobile submission; pair with plan-aeo-readiness for web.
• `plan-privacy-compliance` — collection-vs-claimed + store privacy labels.
• `plan-aso` — listing keywords/screenshots after the app is submittable.
• `audit-monetization-iap` — receipt validation / restore (not just "uses official billing").
• `plan-stub-checker` — placeholders are rejections on mobile.
• Execution: mobile-capacitor-platform, enhance-capacitor-ui,

workflow-mobile-native-uiux (pillar F), mobile-emulator-test (then real device).

• Verify: real-device crash test + IAP dry-run; Android closed-test gate satisfied.

Plan at high effort. Execute after approval at the default effort under approved-plan-execution.mdc (no reward hacking, no feature deletion).