Plan Mobile Readiness

---
name: plan-mobile-readiness
description: >
  Plan-only App Store / Google Play submission audit for Capacitor and React
  Native: manifests, permissions, privacy, signing. Use when "ready for App
  Store?" or "will Google Play reject this?".
license: MIT
effort: high
---

# Mobile Store-Readiness Audit + Pre-Submission Plan

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

## This skill vs neighbors

| Skill | Owns |
|---|---|
| **plan-mobile-readiness** (this) | Store submission mechanics |
| `plan-aso` | Listing keywords / conversion |
| `plan-privacy-compliance` | Privacy labels vs real collection |


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

**Task:** Inventory build/config/listing against checklist A–E, 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 Guideline 2.5.2 thin-app 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.

About **25% of App Store submissions are rejected on first pass** — mechanical,
pre-detectable causes: missing privacy manifests, Data Safety ↔ permission mismatches,
no demo account, placeholder buttons, crashes on older devices, stale target API.
**Apple blocks prompt-to-app builders under Guideline 2.5.2** — the thin web-view
rejection vibe-coded apps trip constantly.

---

## 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 (2.5.2 / thin-app)
- **Placeholder / TODO UI** — cross-hand to `plan-stub-checker`.
- **Too thin / web-view-only** — Guideline 2.5.2 risk; flag honestly.
- **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** — meets current store minimum.
- **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 (2.5.2 "web-view-only" 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 and iOS 26; no opaque status-bar hack.
- **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
2.5.2 "thin app" verdict. Remediation is one pass of `enhance-mobile-native-feel`.

---

## Procedure  [HIGH freedom — plan only]

1. **Inventory** Capacitor/RN config, manifests, permissions, listing, IAP.
2. **Run A–E**, 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 / 2.5.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 + 2.5.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 2.5.2 thin-app risk; declaration must match reality both ways

---

## Report template — `plan-mobile-readiness.md`

```markdown
# 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 | 2.5.2 thin-app |

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

## Phased burndown
- **Phase 1 — Privacy** → `mobile-capacitor-platform`
- **Phase 2 — Functionality & 2.5.2** → `plan-stub-checker` / `enhance-capacitor-ui`
- **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`,
  `enhance-mobile-native-feel` (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).