plan-mobile-readiness
>
Works with
--- name: plan-mobile-readiness description: > license: MIT --- # 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** — 12 testers / 14 days before production. ### E · Listing & metadata - **Screenshots/icon match build**; metadata limits; content rating/CSAE. --- ## 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`. End the turn.** --- ## 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`, `mobile-emulator-test` (then real device). - **Verify:** real-device crash test + IAP dry-run; Android closed-test gate satisfied. > Plan with a strong model; execute with `composer-2.5-execution.mdc`.
More Mobile skills
animation-vocabulary
emilkowalski/skills
Reverse-lookup glossary that turns a vague description of a web animation or motion effect into its exact term ("the bouncy thing when a popover opens" → Pop in; "the iOS rubber-band scroll" → Rubber-banding). Use when the user asks "what's it called when…", or describes a motion effect without knowing its name and wants the right word to prompt an AI or designer with. For naming an effect, not designing or building one.
xcode-project-setup
firebase/agent-skills
Safely modifies Xcode projects (.pbxproj) to add Swift Packages and link files. Use this skill whenever an iOS project needs dependencies installed (e.g. Firebase, Alamofire).
cross-border-ecommerce
nexscope-ai/ecommerce-skills
Cross-border e-commerce expansion advisor. Scores target markets on 8 weighted dimensions (market size, ecommerce penetration, competition, regulatory complexity, logistics infrastructure, payment ecosystem, cultural distance, IP protection), compares 5 fulfillment models with cost and transit data, provides country-by-country tax/duty compliance guides (EU VAT/IOSS, UK VAT, US sales tax, CA GST, AU GST, JP consumption tax), maps local payment preferences by market, and builds a phased expansion roadmap. No API key required.

