Install
openclaw skills install mobile-app-launch-coachEnd-to-end coach for indie devs / small teams launching mobile apps on iOS App Store + Google Play (and emerging app stores). Covers idea + ASO niche validation, native vs cross-platform (Swift/Kotlin/Flutter/React Native/Expo), App Store + Play Console submission and review survival (rejection patterns, IAP rules, privacy nutrition labels, AI-content disclosure 2026), monetization (subscription / one-time / freemium / ads / hybrid), App Tracking Transparency reality, ASO + paid UA + influencer + referral growth, retention and lifecycle messaging, exit options (acquisition, sale via Acquire.com / FE / direct). Use when builder asks about "should I build native or cross-platform", "App Store rejection", "Play Store policy", "ATT / IDFA", "subscription pricing tiers", "ASO keywords", "App Clip", "Instant App", "Apple Search Ads vs Meta UA", or transitioning a web SaaS to mobile. Triggers on phrases like "launch iOS app", "publish to App Store", "Google Play submission", "Flutter vs React Native", "Expo", "Apple subscription", "in-app purchase", "RevenueCat", "App Store rejection 4.3", "Privacy Manifest", "ASO ranking", "Apple Search Ads".
openclaw skills install mobile-app-launch-coachCoach an indie dev / small team through shipping a mobile app as a real product (not a portfolio piece). The 4 phases: validate the idea + ASO niche before building (most app failures are demand failures, not product failures), pick a stack + architecture that ships fast without becoming legacy debt, survive App Store + Play Store review (the review processes have strict opinions, especially around AI content + subscriptions + privacy), and monetize + grow without burning your launch on a single bad review or rejected build. Most indie apps fail one of: pure-rip-off-of-popular-app (rejected immediately), free-with-no-monetization-path, building before any keyword research, or going in solo when iOS + Android + backend + design + marketing actually need a 2-3 person team.
Trigger when the builder mentions:
Do not engage for: explicit ToS-violating apps (cheats / unauthorized scrapers / IP infringement / fake-account tools), pure web app / PWA without mobile-specific concerns, or "hire me to build the app" agency questions.
Ask 12-16 questions. Pull at least one from each block.
The product
Build state 5. Built / unbuilt? If built: which platform(s) live, build version, current users? If unbuilt: stack chosen + why? 6. Backend: pure-client / cloud-API / Firebase / custom backend / SaaS-like? 7. Team: solo, founder + dev, founder + dev + designer, full team?
Audience & monetization 8. Owned audience size: email list, X / TikTok / IG followers, community. 9. Monetization model: subscription, one-time, freemium, ads, hybrid? Target ARPU / LTV? 10. Revenue target: month-3, month-12, month-24.
Regulatory / risk 11. Categories with extra scrutiny: kids (COPPA), health (HIPAA), finance (KYC / regulated), dating (age-gating), gambling (skill-vs-chance), crypto (FinCEN / SEC concerns). 12. Privacy: collecting which data? IDFA tracking? Third-party SDKs? GDPR / CCPA compliance plan?
Constraints 13. Budget for first 6 months (build + UA + tools + Apple/Google fees). 14. Timeline: aggressive (3 months to launch), normal (6 months), thoughtful (9-12 months)? 15. iOS-only / Android-only / both? (Most indies underestimate the cost of "both.") 16. Geographic launch scope: US-only / EN-speaking / global?
If they can't answer 8-12, the gap is the work. Many app projects fail because the "build" started before the demand validation, ASO research, and monetization model were grounded.
Most failed apps die from missing demand, not poor build quality. Validate before code.
Demand-validation gate (3 conditions):
ASO research methodology (do this BEFORE building):
Tools:
Demand-signal validation (low-cost):
Demand-signal anti-patterns:
The single biggest decision. Wrong stack = either ship-too-late OR build-on-sand.
Decision matrix:
| Stack | Best for | Pros | Cons | Effort 0→launch |
|---|---|---|---|---|
| SwiftUI / Swift (iOS) | iOS-first, polished UX, deep system integrations, < $200K MRR target initially | Best UX on iOS, fastest iteration on iOS, fewer build issues, smaller team works | Don't get Android for "free" | 8-16 weeks |
| Jetpack Compose / Kotlin (Android) | Android-first, mature material design, deep system integrations | Best Android UX, fastest iteration on Android | Don't get iOS for free | 10-16 weeks |
| Native both (separate codebases) | Larger team, scaling app, $1M+ ARR target | Best quality on each platform, no abstraction overhead | 1.7-1.9× cost vs single platform; need iOS + Android engineers | 14-20+ weeks |
| React Native (Expo or bare) | JS team, web → mobile, want shared code | Largest ecosystem, fastest hire pool, OTA updates with Expo | Animation / scrolling can lag, native module hell occasionally, MV3-style native API churn | 10-14 weeks |
| Expo | RN with managed runtime, fastest indie path | Fastest setup, OTA updates, fewer build pipeline headaches | Limited to Expo modules unless ejecting; bundle size larger | 8-12 weeks |
| Flutter (Dart) | Pixel-perfect UI control, gaming-adjacent UI, multi-platform incl desktop | Single codebase iOS + Android + (web/desktop), super smooth animations | Dart hire pool smaller, native integrations heavier | 10-14 weeks |
| KMP (Kotlin Multiplatform) | Android team adding iOS, share business logic | Native UI on both sides, share networking / domain logic | Maturity gap on iOS, native UI duplication | 14-18 weeks |
| Capacitor / Ionic | Existing web app needing thin mobile shell, hybrid web tech | Reuse web codebase | Web-feel on mobile; punished by App Store reviewers if "just a web view" | 6-10 weeks |
| .NET MAUI | Existing .NET / Xamarin codebase, enterprise app | Enterprise-friendly, C# stack | Smaller hire pool, animation / native integration tradeoffs | 12-16 weeks |
Decision heuristics:
Tradeoffs to confront honestly:
Backend stack:
SDK ecosystem (typical mobile app stack):
The gauntlet. Indies underestimate the review cycle; plan 2-4 weeks of submission iteration.
Apple App Store Review Guidelines (most-relevant):
Apple-specific 2026 details:
PrivacyInfo.xcprivacy; covers data usage + third-party SDKs you depend on.Common Apple rejections (and fixes):
| Reason | Cause | Fix |
|---|---|---|
| 4.3 (spam) | App "feels like" hundreds of others | Stronger differentiation in description, screenshots, video; unique value-prop |
| 4.2 (minimum functionality) | App doesn't do enough; mostly web view | Build native features; reduce "just a web wrapper" feel |
| 5.1.1 (privacy) | Missing privacy policy or unclear data practices | Host privacy policy, fill nutrition labels honestly |
| 3.1.1 (IAP) | Selling digital goods via Stripe / external | Switch digital goods to IAP; physical goods can use Stripe |
| 2.1 (performance) | Crash on launch / specific flow | Test on real iOS devices (not just simulator); test latest iOS |
| 2.3 (accurate metadata) | Screenshots show features not in app | Update screenshots to match actual product |
| 5.6.1 (developer code of conduct) | Suspicious developer activity | Use a clean Apple Developer account; respond to inquiries |
Google Play Console policies:
Common Play rejections:
Submission process:
Apple flow (iOS):
Google flow (Android):
TestFlight + Play closed testing — use them:
Indie mobile apps have 4 viable models. Pick the one that fits your category, not the one trending on Twitter.
Model 1: Subscription (recommended for most indie consumer apps):
Model 2: One-time purchase (paid up-front):
Model 3: Freemium with IAP / unlocks:
Model 4: Ads (interstitial / banner / rewarded):
Hybrid models:
Pricing decision tree:
Subscription paywall design:
Apple / Google revenue split:
Privacy is the biggest store rejection category. Get it right at design time, not at submission.
iOS App Tracking Transparency (ATT):
Privacy Manifest (iOS 17+):
PrivacyInfo.xcprivacy file declaring:
Privacy nutrition labels (App Store + Play Data Safety):
GDPR (EU) / CCPA (CA) / similar:
Specific category regulations:
AI / ML feature disclosure (2026):
ai-product-launch-coach).Mobile UA is harder than 5 years ago. ATT broke Meta UA precision; CPI is up; retention is more important than ever.
ASO (App Store Optimization):
| Lever | iOS | Android |
|---|---|---|
| Title | 30 chars; primary keyword + brand | 50 chars; richer keyword stuffing tolerated |
| Subtitle | 30 chars; secondary keyword | (no equivalent — use short description) |
| Keywords (iOS) / description (Android) | 100 chars hidden keyword field | 80 char short description (high weight) + 4000 char long description |
| Screenshots | 6.7" + 6.5" + 5.5" sets | Multiple screen sizes |
| Preview video | 30s landscape or portrait | Up to 30s YouTube link |
| App icon | Visual hook; A/B test in App Store Connect (Custom Product Pages) | Same; use Play Console experiments |
| Reviews + ratings | Highest weight in Apple ranking | High weight |
| Install velocity + retention | Strong recent ranking signal | Strong recent ranking signal |
ASO playbook:
Paid UA:
ASA decision rule:
Organic growth:
Retention is everything:
Stay solo + grow:
Acquisition exit:
Pre-exit prep (12-18 months):
For every coaching session, produce in this order:
If builder pushes back ("I want both platforms day 1 even though solo"): re-run the diagnostic. Cross-platform indie launches usually fail on quality of one of the platforms; better to ship iOS, validate, then add Android. Coaching is pressure on the realistic plan, not affirmation of overcommit.