Growth Skills

Growth skills for indie Apple developers — from analytics interpretation to press outreach to community building. Covers the non-code aspects of building a sustainable app business.

When This Skill Activates

Use this skill when the user:

• Asks about growing their app or user acquisition
• Wants to understand app metrics or analytics
• Asks about press/media outreach or getting reviews
• Wants to build a community around their app
• Asks about indie business operations (LLC, taxes, hiring)
• Mentions growth strategy, marketing, or user engagement
• Wants data-driven guidance on what to improve next

Available Skills

store-growth-audit/

Stage-by-stage audit of an app's App Store growth machinery against a 54-item P0–P9 playbook — every item scored from an ASC read, a codebase check, or an explicit question, then routed to the skill that fixes it. Read-only; works for live apps (audit) and pre-launch apps (growth plan).

store-signals/

Close the post-launch loop — turn a live app's App Store signals (reviews, analytics, sales, crashes, listing conversion) into a metric-tagged backlog, and verify whether last cycle's changes moved the metric they promised to move.

analytics-interpretation/

Interpret app metrics and make data-driven decisions. Covers DAU/MAU, retention curves, LTV/ARPU, App Store Connect analytics, funnel analysis (AARRR), cohort analysis, and decision trees for what to fix based on which metric is underperforming.

press-media/

Get press coverage and media attention for your app. Covers press kit preparation, finding relevant journalists/bloggers/YouTubers, pitch timing and embargo strategy, indie developer story angles, and email templates for outreach.

community-building/

Build and engage a user community around your app. Covers platform selection (Twitter/X, Mastodon, Reddit, Discord), building in public strategy, content calendars for solo developers, and converting community members into advocates.

indie-business/

Business fundamentals for indie app developers. Covers business entity setup (LLC, S-Corp), Apple Small Business Program, tax basics for app revenue, revenue tracking, when to hire, and financial planning for indie sustainability.

How to Use

1. Identify what growth stage the user is at:
   • Pre-launch: store-growth-audit (seed the growth plan), press-media (prepare press kit), community-building (build anticipation)
   • Just launched: analytics-interpretation (baseline metrics), press-media (launch outreach)
   • Growing: store-signals (monthly loop), analytics-interpretation (optimize funnel), community-building (scale engagement)
   • Established: store-growth-audit (quarterly re-audit), indie-business (formalize operations), analytics-interpretation (advanced cohorts)
2. Read the relevant sub-skill's SKILL.md for detailed workflow
3. Ask clarifying questions about the user's app, audience, and current metrics
4. Provide actionable guidance tailored to their specific situation

---

Supporting file: analytics-interpretation/metrics-reference.md

Metrics Reference

Definitions, formulas, and benchmarks for key app metrics. Use this as a lookup when interpreting user data in the analytics-interpretation skill.

Metric Definitions and Formulas

Engagement Metrics

DAU (Daily Active Users) Users who open the app at least once in a calendar day.

DAU = count of unique users with at least one session on a given day

MAU (Monthly Active Users) Users who open the app at least once in a 30-day rolling window.

MAU = count of unique users with at least one session in the last 30 days

DAU/MAU Ratio (Stickiness) Percentage of monthly users who use the app on any given day. Higher = more habitual usage.

DAU/MAU = DAU / MAU × 100

Session Length Average time spent per app session, from foreground to background.

Avg Session Length = total session time / total sessions

Sessions Per User Per Day How many times the average daily user opens the app.

Sessions/User/Day = total daily sessions / DAU

Retention Metrics

Day N Retention (D1, D7, D30) Percentage of users who installed on Day 0 and returned on Day N.

DN Retention = users active on Day N / users installed on Day 0 × 100

Note: This is "classic retention" (active on exactly Day N), not "rolling retention" (active on Day N or later).

Rolling Retention (Return Rate) Percentage of users who installed on Day 0 and returned on Day N or any day after.

Rolling DN Retention = users active on Day N or later / users installed on Day 0 × 100

Rolling retention is always >= classic retention and gives a more optimistic view.

Weekly Retention Percentage of users active in Week 1 who are also active in Week N.

Week N Retention = users active in Week N / users active in Week 1 × 100

Churn Rate (Monthly) Percentage of subscribers who cancel in a given month.

Monthly Churn = subscribers lost in month / subscribers at start of month × 100

Revenue Metrics

LTV (Lifetime Value) Total revenue expected from a single user over their entire lifetime.

LTV = ARPU / Monthly Churn Rate
or
LTV = ARPU × Average Customer Lifetime (in months)

ARPU (Average Revenue Per User) Revenue per user across all users (including free users).

ARPU = total revenue / total users (in period)

ARPPU (Average Revenue Per Paying User) Revenue per paying user only.

ARPPU = total revenue / paying users (in period)

MRR (Monthly Recurring Revenue) Predictable monthly revenue from active subscriptions.

MRR = number of active subscribers × average monthly subscription price

ARR (Annual Recurring Revenue) Annualized version of MRR.

ARR = MRR × 12

CAC (Customer Acquisition Cost) Cost to acquire one new user through paid channels.

CAC = total acquisition spend / new users acquired

Payback Period Months to recoup the cost of acquiring a user.

Payback Period = CAC / monthly ARPU (in months)

Trial Start Rate Percentage of downloads that start a free trial.

Trial Start Rate = trial starts / downloads × 100

Trial Conversion Rate Percentage of free trials that convert to paid subscriptions.

Trial Conversion = paid conversions / trial starts × 100

App Store Metrics

Impressions Number of times your app appeared in App Store search results, featured sections, or browse pages. Counts views of your icon/title, not full page views.

Product Page Views (PPV) Number of times users tapped through to your full product page (screenshots, description, reviews).

Tap-Through Rate (TTR)

TTR = Product Page Views / Impressions × 100

Conversion Rate (CVR)

CVR = App Units (downloads) / Product Page Views × 100

App Units First-time downloads. Does not include re-downloads or updates.

Benchmarks by App Category

Social / Communication Apps

Productivity / Business Apps

Games (Casual)

Utilities / Tools

Note: Utility apps often have low DAU/MAU because they are used only when needed (e.g., a calculator). Low stickiness is not necessarily bad for utilities — focus on retention and satisfaction instead.

Subscription Apps (General)

App Store Conversion Benchmarks

Tap-Through Rate (Impressions → Product Page Views)

Product Page Conversion Rate (PPV → Downloads)

Quick Threshold Reference

Use these stoplight ratings in analytics reports:

Note: These are general guidelines. Always consider app category, target audience, and monetization model when evaluating. A utility app with 8% DAU/MAU might be performing excellently, while a social app at 8% has a problem.

---

Supporting file: analytics-interpretation/SKILL.md

Analytics Interpretation

Interpret your app's metrics, diagnose problems, and make data-driven decisions. Works with App Store Connect data, third-party analytics, or raw numbers the user provides.

When This Skill Activates

Use this skill when the user:

• Wants to understand their app metrics or analytics
• Asks about retention, LTV, ARPU, or churn
• Wants to know if their metrics are good or bad
• Needs help interpreting App Store Connect analytics
• Wants a data-driven growth plan
• Asks "what should I focus on to grow?"
• Has metrics data and wants to know what it means

Process

Step 1: Gather Context

Ask the user via AskUserQuestion:

1. App type and monetization model
   • Free with ads, freemium, subscription, paid upfront, or hybrid?
2. Current metrics they have access to
   • App Store Connect? Third-party analytics (Mixpanel, Firebase, Amplitude)?
3. Specific numbers they can share
   • Downloads, DAU/MAU, retention, revenue, conversion rates?
4. What they want to know
   • "Are my metrics good?" / "What should I fix?" / "Should I keep going?"

Also pull App Store Connect peer group benchmarks (App Analytics → Benchmarks) before interpreting any trend — they establish whether a metric is "bad for you" or "bad for the category."

How Peer Group Benchmarks Work

• Peer group = App Store category + business model (free / freemium / paid / paidmium / subscription) + download-volume band
• Benchmarked metrics: conversion rate, D1/D7/D28 retention, crash rate, average proceeds per paying user
• You see the peer group's 25th / 50th / 75th percentile bands (example: day-1 retention 13.4% / 21.3% / 27.4%)
• Differential privacy adds noise and groups have minimum sizes — judge by which quartile you're in, not exact deltas
• Improving ≠ done: an app that lifted conversion +5.5% over 90 days can still sit in the bottom half of its peer group

Step 2: Identify Key Metrics by App Type

Different monetization models have different north star metrics.

Free with Ads

Freemium (One-Time Unlock)

Subscription

Paid Upfront

Step 3: App Store Connect Analytics Interpretation

The App Store Funnel

Impressions (your app appeared in search/browse)
    ↓ Tap-through rate = Product Page Views / Impressions
Product Page Views (user tapped to see your page)
    ↓ Conversion rate = Downloads / Product Page Views
Downloads (user installed your app)
    ↓ D1 retention
Day 1 Active Users
    ↓ D7 retention
Day 7 Active Users
    ↓ D30 retention
Day 30 Active Users
    ↓ Monetization
Paying Users

App Store Connect Definitions (get these right)

• Conversion rate = total downloads ÷ unique impressions (not raw impressions)
• Total downloads = first-time downloads + redownloads; auto-downloads (device syncing) are excluded
• Segment every funnel metric by the 4 source types — App Store browse, App Store search, app referrer, web referrer — and by page type: product page vs. store sheet vs. no page. A strong product-page CVR can hide a weak store-sheet CVR
• Up to 7 filters stack per metric (WWDC25) — e.g. search traffic + one territory + store sheet
• Payer metrics (WWDC25): Download-to-Paid Conversion and Average Proceeds per Download connect acquisition quality to revenue

Interpreting Each Funnel Step

Impressions → Product Page Views (Tap-Through Rate)

What to fix if low:

• App icon not standing out (test bolder colors, simpler design)
• Title not communicating value (add keyword after brand name)
• Subtitle too vague (make it specific: "Budget Tracker" not "Finance App")
• Poor search ranking (see keyword-optimizer skill)

Product Page Views → Downloads (Conversion Rate)

What to fix if low:

• First 3 screenshots not showing core value
• No app preview video (adds 15-25% lift)
• Description too long before showing key benefits
• Bad ratings visible (address review issues first)
• Price too high relative to perceived value

Downloads → Day 1 Retention

What to fix if low:

• Onboarding too long or confusing
• App Store screenshots overpromised
• Core value not visible in first session
• Permissions requested too early (camera, notifications)
• Performance issues (slow launch, crashes)

Day 1 → Day 7 Retention

What to fix if low:

• No reason to come back (add notifications, reminders, streaks)
• Core loop not engaging enough
• Too complex — users haven't learned enough features
• Missing "aha moment" in first week

Day 7 → Day 30 Retention

What to fix if low:

• Feature depth too shallow (users exhaust value)
• No progression or new content
• Competitor doing it better
• Consider: is this a "use once" tool, not a habit app?

Step 4: AARRR Funnel Analysis

The pirate metrics framework — diagnose where your funnel leaks.

Acquisition: How do users find you?

Questions to ask:

• What are your top 3 acquisition sources?
• Is organic growing or shrinking?
• What's your cost per install (if running ads)?

Activation: Do users experience the core value?

Questions to ask:

• What is the one action that defines "this user gets it"?
• How many steps to reach that action?
• What percentage of new users complete it?

Retention: Do users come back?

Questions to ask:

• Where is the biggest retention drop-off?
• What do retained users do differently from churned users?
• Is there a retention cliff at a specific day?

Revenue: Are users paying?

Questions to ask:

• At what point do users encounter the paywall?
• What's the conversion rate at each paywall touchpoint?
• Do longer-retained users convert at higher rates?

Referral: Do users tell others?

Questions to ask:

• Is there a share feature in the app?
• Do you ask for ratings at the right moment?
• What triggers a user to recommend your app?

Step 5: Cohort Analysis (Subscription Apps)

How to Read a Cohort Retention Table

              Month 0  Month 1  Month 2  Month 3  Month 4  Month 5
Jan cohort    100%     62%      55%      50%      48%      46%
Feb cohort    100%     58%      51%      46%      44%      —
Mar cohort    100%     65%      59%      54%      —        —
Apr cohort    100%     70%      63%      —        —        —
May cohort    100%     68%      —        —        —        —

What to look for:

1. Month 0 → Month 1 drop: The biggest drop. Industry average is 30-50% churn. If yours is > 50%, trial experience needs work.

2. Flattening curve: Retention should flatten over time. If Month 3 → Month 4 → Month 5 are similar, you've found your "natural retention floor."

3. Improving cohorts: Compare Jan vs. Apr cohorts at the same month. If Apr Month 1 (70%) > Jan Month 1 (62%), your product improvements are working.

4. Retention cliff: A sudden drop at a specific month often indicates:

   • Month 1: Annual subscribers who don't renew
   • Month 3: Users who gave it a fair try and decided no
   • Month 12: Annual subscribers hitting renewal

Comparing Cohorts to Measure Impact

When you ship a change, compare cohorts before and after:

Before change (Jan-Mar avg):  Month 1 retention = 58%
After change (Apr-May avg):   Month 1 retention = 69%

Improvement: +11 percentage points → significant positive impact

Rules of thumb:

• < 3 percentage point change: likely noise
• 3-10 percentage point change: meaningful, keep the change

• 10 percentage point change: major win, double down on this direction

App Store Connect Subscription Metrics (WWDC25)

App Analytics carries 50+ subscription metrics, organized as states (subscribers in an offer, paying full price, with billing issues, churned) and events (movement between states):

• Net Paid Plans — new paid starts vs. voluntary + involuntary churn — is the single best subscription health headline
• Track Subscription Retention two ways: by months-since-subscribing and by offer start (example shape: 67% trial→paid, then 78% retained at 3 months, 73% at 6)
• Offers do three jobs — acquire (introductory), retain (promotional), win back — measure offer→full-price conversion for each job separately

Segment Cohorts by Acquisition Source

Cohort tables get sharper when split by source or custom product page. Example: a "runner" CPP segment converting at 1.3% vs. 3% overall means three different levers from one segmented number — fix that page's creative, redirect its ad spend, and re-engage its cohort via in-app events.

Step 6: Diagnostic Decision Trees

Use these when the user says "my [metric] is bad, what do I do?"

Low Impressions (< 1,000/day for established app)

Low impressions
├── Are you ranking for any keywords?
│   ├── NO → ASO problem: optimize title, subtitle, keywords
│   │        See keyword-optimizer skill
│   └── YES → Are those keywords high-volume?
│       ├── NO → Target higher-volume keywords
│       └── YES → Are you ranking in top 10?
│           ├── NO → Improve rankings (more ratings, better conversion)
│           └── YES → Expand to more keywords or new markets

High Impressions, Low Product Page Views (TTR < 4%)

Low tap-through rate
├── Is your icon professional and distinctive?
│   ├── NO → Redesign icon (test 3 variants)
│   └── YES → Is your title clear and keyword-rich?
│       ├── NO → Rewrite title: [Brand] - [Value Keyword]
│       └── YES → Is your subtitle compelling?
│           ├── NO → Rewrite subtitle with specific benefit
│           └── YES → Check competitor positioning — are you differentiated?

Good Downloads, Bad Retention (D1 < 25%)

Poor day-1 retention
├── Is onboarding complete rate > 70%?
│   ├── NO → Simplify onboarding (fewer steps, skip option)
│   └── YES → Do users reach "aha moment" in first session?
│       ├── NO → Restructure first-run experience to show core value immediately
│       └── YES → Are there performance issues (crashes, slow load)?
│           ├── YES → Fix stability first (check crash reports)
│           └── NO → Does the app match what screenshots promised?
│               ├── NO → Align marketing with actual product
│               └── YES → Core value may not be strong enough → user research needed

Good Retention, Low Revenue (conversion < 3%)

Low monetization
├── Do users see the paywall?
│   ├── NO → Add natural paywall touchpoints (feature gates, usage limits)
│   └── YES → Is the paywall compelling?
│       ├── NO → Redesign paywall (show value, social proof, feature comparison)
│       └── YES → Is the price right?
│           ├── TOO HIGH → Test lower price point or add cheaper tier
│           ├── TOO LOW → Users may not perceive enough value — test higher price
│           └── SEEMS RIGHT → Is trial experience showcasing premium features?
│               ├── NO → Onboard users to premium features during trial
│               └── YES → Test different trial lengths or offer types

Step 7: Invest, Iterate, Pivot, or Sunset?

Based on the overall picture, recommend one of four paths:

Invest (Double Down)

Signals:

• D7 retention > 40%
• Growing organically (installs increasing without paid acquisition)
• Users actively requesting features
• Conversion rate improving over time
• Strong ratings (> 4.5 stars)

Action: Increase development speed, consider marketing spend, expand to new platforms.

Iterate (Keep Improving)

Signals:

• D7 retention 20-40%
• Some organic growth but not accelerating
• Mixed user feedback (some love it, some confused)
• Conversion rate stable but not great

Action: Focus on the retention cliff. Find what retained users do differently and make all users do that. A/B test paywall and onboarding.

Pivot (Change Direction)

Signals:

• D7 retention < 20% after 3+ iterations
• Engagement concentrated in unexpected feature
• Users using app differently than intended
• Specific segment retains well, others don't

Action: Double down on the unexpected use case. Rebuild around what users actually do, not what you planned.

Sunset (Move On)

Signals:

• Declining metrics across the board
• No organic growth despite multiple iterations
• Users not engaging even after onboarding improvements
• Opportunity cost too high (other ideas with more potential)

Action: Put app in maintenance mode. Stop active development. Consider open-sourcing or selling. Redirect energy to next project.

Important caveat: Sunsetting is not failure. Most successful indie developers shipped several apps before finding the one that worked.

Reference Files

See metrics-reference.md for:

• Detailed metric definitions and formulas
• Benchmark ranges by app category (social, productivity, games, utilities)
• App Store Connect specific metric definitions
• Red/yellow/green thresholds for all key metrics

Output Format

Present analysis as an Analytics Health Report:

# Analytics Health Report: [App Name]

## Overview
**App type:** [Free/Freemium/Subscription/Paid]
**Stage:** [Pre-launch/Early/Growing/Established]
**Data period:** [Date range analyzed]

## Funnel Health

| Stage | Metric | Value | Rating | Action |
|-------|--------|-------|--------|--------|
| Acquisition | Impressions/day | X,XXX | 🟢/🟡/🔴 | ... |
| Acquisition | Tap-through rate | X.X% | 🟢/🟡/🔴 | ... |
| Activation | Conversion rate | X.X% | 🟢/🟡/🔴 | ... |
| Retention | D1 retention | XX% | 🟢/🟡/🔴 | ... |
| Retention | D7 retention | XX% | 🟢/🟡/🔴 | ... |
| Retention | D30 retention | XX% | 🟢/🟡/🔴 | ... |
| Revenue | Conversion rate | X.X% | 🟢/🟡/🔴 | ... |
| Revenue | LTV | $XX.XX | 🟢/🟡/🔴 | ... |

## Primary Bottleneck
**[Stage name]** — [One sentence explanation of the biggest problem]

## Recommended Actions (Priority Order)
1. 🔴 [Critical fix] — Expected impact: [X]
2. 🟠 [High priority] — Expected impact: [X]
3. 🟡 [Medium priority] — Expected impact: [X]

## Overall Assessment
**Recommendation:** [Invest / Iterate / Pivot / Sunset]
**Rationale:** [2-3 sentences]

References

• metrics-reference.md — Metric definitions, formulas, and benchmarks
• app-store/keyword-optimizer/ — For ASO-related fixes
• monetization/ — For pricing and paywall optimization
• testing/ — For A/B test methodology

---

Supporting file: community-building/SKILL.md

Community Building

Build and engage a community around your indie Apple app. Practical strategies for solo developers who have limited time but want meaningful growth through community.

When This Skill Activates

Use this skill when the user:

• Wants to build a community around their app
• Asks about growing their social media presence
• Wants to start building in public
• Needs a content strategy for promoting their app
• Asks about developer marketing
• Wants to turn users into advocates

Process

Step 1: Gather Context

Ask the user via AskUserQuestion:

1. Current presence: Are you on any social platforms? How many followers?
2. Time budget: How many hours per week can you dedicate to community?
3. Comfort level: Are you comfortable sharing revenue, progress, struggles?
4. App stage: Pre-launch, just launched, growing, or established?
5. Target audience: Developers, general consumers, or a specific niche?

Step 2: Platform Selection

Choose 1-2 platforms to focus on rather than spreading thin across many.

Platform Comparison

Twitter/X

• Audience: Large Apple developer community, tech enthusiasts
• Strengths: Fast feedback loops, viral potential, networking with other devs
• Weaknesses: Noisy, algorithm-dependent, declining trust among some users
• Best for: Developer tools, productivity apps, building in public
• Time investment: 15-30 min/day
• Growth speed: Moderate (1-3 months to gain traction)

Mastodon (mastodon.social / indieweb.social)

• Audience: Growing indie dev community, privacy-conscious users
• Strengths: No algorithm (chronological), supportive community, less noise
• Weaknesses: Smaller audience, less viral potential, fragmented servers
• Best for: Privacy-focused apps, developer tools, indie community engagement
• Time investment: 10-20 min/day
• Growth speed: Slow but genuine (3-6 months)

Reddit

• Audience: Highly engaged niche communities
• Strengths: Targeted subreddits, long-form discussion, SEO value
• Weaknesses: Anti-self-promotion rules, can be hostile, requires genuine participation
• Best for: Category-specific apps (r/productivity, r/fitness, r/budgeting)
• Subreddits: r/iOSProgramming, r/apple, r/SwiftUI, r/macapps, plus your app's category
• Time investment: 15-20 min/day (mostly commenting, not posting)
• Growth speed: Moderate if you contribute genuinely

Discord

• Audience: Power users, beta testers, engaged community members
• Strengths: Real-time interaction, deep engagement, beta testing hub
• Weaknesses: Requires active moderation, conversations are ephemeral, onboarding friction
• Best for: Apps with power users who want to discuss features and help shape the roadmap
• Time investment: 20-30 min/day (or batch in dedicated hours)
• Growth speed: Slow (requires seeding initial members)

Threads

• Audience: Growing, overlaps with Instagram audience
• Strengths: Growing platform, casual tone, integrated with Instagram
• Weaknesses: Still maturing, less developer-focused, algorithm-driven
• Best for: Consumer apps, visual apps, casual updates
• Time investment: 10-15 min/day
• Growth speed: Moderate (riding platform growth)

Blog / Newsletter (Owned Platform)

• Audience: Subscribers who opted in — highest intent
• Strengths: You own the audience, SEO benefits, long-form depth, email is reliable
• Weaknesses: Slow to build, requires consistent writing, higher effort per post
• Best for: Every app (this should be your long-term play, even if secondary)
• Platforms: Ghost, Buttondown, Substack, WordPress, or static site
• Time investment: 2-4 hours/week (one post per week)
• Growth speed: Very slow but most durable (6-12 months to meaningful audience)

Recommended Combinations

Step 3: Building in Public Strategy

Building in public means sharing your development journey transparently. It builds trust, creates accountability, and attracts early users.

What to Share

High engagement (share often):

• Progress updates with screenshots or short videos
• Design decisions and iterations (before/after)
• Milestones: download counts, revenue milestones, ratings
• Polls asking community to choose between features/designs
• Bugs you found and how you fixed them (relatable and educational)
• Weekly/monthly progress summaries

Medium engagement (share periodically):

• Revenue numbers and growth metrics (if comfortable)
• Lessons learned from mistakes
• Tools and processes you use
• App Store optimization experiments and results
• User testimonials and reviews

Use sparingly:

• Technical deep-dives (save for blog posts)
• Long threads (1-3 per month maximum)
• Philosophical musings about indie development

What NOT to Share

• Proprietary algorithms or trade secrets
• Features too far in advance (competitors watching, user expectations)
• Negative commentary about competitors
• Customer complaints or private messages
• Anything that could create legal liability
• Personal drama unrelated to the app journey

Transparency Levels

Choose your comfort level:

All levels work. Pick what you are genuinely comfortable with and stay consistent.

Step 4: Content Calendar (Realistic for Solo Developers)

This calendar assumes 3-5 hours per week total for community building.

Weekly Rhythm

Monthly Additions

Batching Strategy

Do not create content in real-time throughout the week. Instead:

1. Capture constantly: Screenshot interesting moments as they happen (design iterations, bugs, metrics). Takes 30 seconds each.
2. Batch create: Dedicate 2 hours on Sunday (or whenever) to write all posts for the week using your captured screenshots.
3. Schedule posts: Use a scheduling tool (Buffer, Typefully, or native scheduling) so posts go out on the right days.
4. Engage daily: Spend 10-15 minutes responding to replies and engaging with others. This is separate from content creation.

Step 5: Community Engagement Without Full-Time Effort

Daily Habits (10-15 minutes)

• Respond to every mention, reply, and DM (brevity is fine)
• Like/boost 3-5 posts from other developers in your space
• Comment genuinely on 2-3 posts from people you follow
• Check for your app's name/keywords being mentioned

Weekly Habits (30 minutes)

• Participate in relevant hashtags: #indiedev, #iosdev, #buildinpublic, #swiftui, #indieapps
• Share or boost someone else's launch/milestone (goodwill compounds)
• Respond to any App Store reviews (use review-response-writer skill)
• Check Reddit for relevant discussions where you can add value (not promote)

Monthly Habits (1 hour)

• Review your analytics: which posts got the most engagement? Do more of those.
• Follow new people in your space (genuine follow, not follow-for-follow)
• Reach out to 1-2 developers for potential collaboration or cross-promotion
• Update your bio/links if anything has changed

Engagement Rules

• Be genuine: Forced engagement is obvious. Only comment when you have something real to say.
• Give more than you take: The ratio should be roughly 80% supporting others, 20% promoting yourself.
• Respond to everyone: When you are small, responding to every comment builds loyalty.
• Do not automate engagement: Auto-likes, auto-comments, and bot followers backfire.
• Be consistent, not constant: Better to post 3 times per week every week than 10 times one week and nothing for a month.

Step 6: Converting Community Members to Users and Advocates

Early Access and Beta Testing

• Offer TestFlight access to engaged followers before public launch
• Create a private Discord/Slack channel for beta testers
• Give beta testers a voice in feature prioritization
• Thank beta testers publicly when the app launches

Feature Requests and Public Roadmap

• Maintain a public roadmap (GitHub Projects, Notion, or Canny)
• When a community member suggests a feature you build, credit them publicly
• Let community vote on feature priority (creates investment in the product)
• When you ship a requested feature, tag the person who requested it

Referral and Sharing

• Build a share feature into your app (share results, creations, or achievements)
• Create share-worthy moments (streaks, milestones, completions)
• Make it easy to leave a review (use SKStoreReviewController at the right moment)
• Consider a referral program (if your app model supports it)

Social Proof Collection

When to ask for testimonials:

• After a user complements your app (strike while the iron is hot)
• After successfully resolving a support request
• After a user shares your app organically
• After a major update that users are excited about

How to ask:

• "Thanks so much! Would you mind if I shared your kind words on our website?"
• "Would you be willing to leave a review on the App Store? It really helps indie apps like mine."
• Keep it low-pressure. Never guilt or pressure users.

Step 7: Developer Blog as Marketing Channel

A blog is the highest-effort but highest-long-term-value community asset.

Content Types That Work

Technical blog posts (attract developer respect and SEO traffic):

• "How I built [feature] with SwiftUI"
• "Migrating from UIKit to SwiftUI: lessons learned"
• "Using Core ML to [interesting use case]"
• These get shared on Twitter, Hacker News, and iOS Dev Weekly

Behind-the-scenes posts (attract potential users):

• "Designing [App Name]'s onboarding"
• "Why I chose subscription pricing"
• "How I reduced my app's launch time by 60%"

User-focused posts (attract end-user awareness):

• "[App Name] tips and tricks you might not know"
• "How to [solve specific problem] with [App Name]"
• "What's coming in [App Name] 3.0"

Posting Cadence

• Minimum: 1 post per month (consistency matters more than frequency)
• Ideal: 2 posts per month (one technical, one behind-the-scenes)
• Maximum: 1 post per week (only if you enjoy writing and have content)

Distribution

After publishing a blog post:

1. Share on Twitter/X with a hook and key takeaway
2. Share on Mastodon
3. Submit to relevant newsletters (iOS Dev Weekly, Swift Weekly Brief)
4. Post to relevant Reddit communities (if it adds value, not just self-promotion)
5. Submit technical posts to Hacker News
6. Include in your next newsletter

Output Format

Present community strategy as:

# Community Building Plan: [App Name]

## Platform Strategy
**Primary:** [Platform] — [Why]
**Secondary:** [Platform] — [Why]

## Building in Public
**Transparency level:** [Fully/Mostly/Selectively/Journey-focused]
**Key themes:** [3-4 topics you'll share about]

## Weekly Content Calendar
| Day | Content | Platform |
|-----|---------|----------|
| Mon | [Type] | [Platform] |
| Wed | [Type] | [Platform] |
| Fri | [Type] | [Platform] |

## Monthly Content
- [ ] Revenue/growth update
- [ ] Blog post: [topic]
- [ ] Retrospective

## Engagement Plan
- Daily: [specific actions, 10-15 min]
- Weekly: [specific actions, 30 min]
- Monthly: [specific actions, 1 hour]

## Community → Users Pipeline
1. [How you'll convert followers to beta testers]
2. [How you'll convert beta testers to users]
3. [How you'll convert users to advocates]

## Metrics to Track
- Followers/subscribers (monthly)
- Engagement rate (weekly)
- Referral traffic to App Store (monthly)
- Community-driven downloads (if trackable)

References

• press-media/ — For media outreach beyond community
• app-store/review-response-writer/ — For responding to App Store reviews
• indie-business/ — For business context around community investment

---

Supporting file: indie-business/SKILL.md

Indie Business Operations

Business fundamentals for indie Apple app developers. Covers the non-code aspects of running an app business — entity setup, taxes, revenue tracking, hiring, and financial planning.

Disclaimer: This skill provides general guidance, not legal or tax advice. Always consult a qualified accountant or attorney for your specific situation.

When This Skill Activates

Use this skill when the user:

• Asks about business setup for their app (LLC, S-Corp)
• Wants to understand tax implications of app revenue
• Asks when to form an LLC or incorporate
• Wants guidance on hiring contractors or freelancers
• Asks about financial planning for going indie
• Mentions the Apple Small Business Program
• Wants to understand Apple's payment schedule and revenue tracking

Process

Step 1: Gather Context

Ask the user via AskUserQuestion:

1. Location: What country/state are you in? (tax implications vary significantly)
2. Current status: Full-time employed, part-time indie, or full-time indie?
3. Revenue level: Approximate monthly/annual app revenue (or expected if pre-launch)
4. Business entity: Do you currently have an LLC or company? Filing as sole proprietor?
5. Specific question: What business aspect are you trying to figure out?

Step 2: Business Entity Options

United States

Sole Proprietor

• How: Just start earning. Report on Schedule C of personal tax return.
• Pros: Zero paperwork, zero cost, simplest possible setup.
• Cons: No personal liability protection. Your personal assets are at risk if someone sues.
• When to use: Testing the waters, revenue < $10K/year, minimal risk app (no user data, no health claims).

Single-Member LLC (Recommended for Most Indie Devs)

• How: File articles of organization with your state. Get an EIN from the IRS (free).
• Pros: Personal liability protection, flexible tax treatment, professional credibility, separate bank account.
• Cons: Annual state fees ($0 in many states, $800/year in California), must maintain separation between personal and business finances.
• When to upgrade from sole proprietor: Revenue exceeds $10-20K/year, OR you handle user data, OR users rely on your app for health/finance/safety.

S-Corporation Election

• How: Form an LLC, then file Form 2553 to elect S-Corp tax treatment.
• Pros: Payroll tax savings on profits above "reasonable salary."
• Cons: Must pay yourself a "reasonable salary" with payroll, quarterly payroll tax filings, more complex bookkeeping, annual corporate tax return.

When to upgrade entity (decision tree):

Revenue < $10K/year and low-risk app?
├── YES → Sole proprietor is fine
└── NO → Do you handle sensitive user data or have liability risk?
    ├── YES → Form an LLC now
    └── NO → Revenue > $20K/year?
        ├── YES → Form an LLC
        └── NO → Sole proprietor, but plan for LLC soon

Already have an LLC and net profit > $80K/year?
├── YES → Talk to a CPA about S-Corp election
└── NO → Stay as LLC

United Kingdom

• Sole trader: Register with HMRC for Self Assessment. Simple but no liability protection.
• Ltd company: Register with Companies House. Corporation tax on profits (25%), then dividend tax on drawings. More tax-efficient at higher revenue.

European Union (General Guidance)

• Most EU countries have sole proprietor equivalents and limited liability company options.
• VAT registration thresholds vary by country (but Apple handles VAT on app sales).
• Consider your country's social security implications for self-employment income.
• Consult a local accountant — EU tax rules are country-specific.

India

• GST registration may be required above threshold (currently INR 20 lakh).
• TDS (Tax Deducted at Source) applies to payments from Apple (check DTAA with Ireland/US).
• Private Limited preferred if you plan to raise investment.

Step 3: Apple Small Business Program

Overview

• 15% commission (vs. 30% standard) on the first $1M in annual proceeds, applying to all app and in-app purchase revenue.
• Auto-enrollment: Apple enrolls you when you are eligible. No application needed if under $1M.
• Resets annually on January 1.

Impact Calculation

Year-2+ subscriptions are already taxed at 15% regardless of enrollment, so the program's benefit concentrates in:

• Paid upfront apps
• One-time IAP revenue
• First-year subscription revenue

Important Details

• Revenue from all apps under your developer account is combined for the $1M threshold.
• If you have multiple developer accounts (e.g., personal + company), each is evaluated separately.

Step 4: Tax Basics for App Revenue

What Apple Handles (You Don't Need to Worry About)

• Sales tax / VAT: Apple collects and remits sales tax, VAT, and equivalent taxes in virtually all jurisdictions. The price users pay includes these taxes, and Apple deducts them before your payout.
• Tax forms to developers: Apple provides 1099-MISC (US) or equivalent tax documentation annually.

What You Must Handle

Reporting Income (US)

Apple pays you monthly. All payouts are taxable income.

Quarterly Estimated Taxes (US)

If you expect to owe more than $1,000 in taxes for the year, you must make quarterly estimated payments. Missing these results in penalties.

How to estimate: Take your expected annual net profit, multiply by your effective tax rate (federal + state + self-employment). Divide by 4.

Deductible Expenses

These reduce your taxable income. Keep receipts and records for everything.

International Considerations

• If you sell apps globally, Apple handles international tax collection.
• US developers: file W-9 with Apple. Non-US developers: file W-8BEN or W-8BEN-E.
• Tax treaties between your country and Ireland/US may reduce withholding.
• Some countries require you to report worldwide income, including Apple payouts.

Step 5: Revenue Tracking and Bookkeeping

Apple's Payment Schedule

• Apple pays monthly, approximately 33 days after the end of their fiscal month.
• Apple's fiscal months don't always align with calendar months (check your agreement).
• Payments are made via direct deposit to your bank account.
• Minimum payout threshold varies by region (often $10-150 depending on country).

Bookkeeping Setup

Option 1: Spreadsheet (Free, < $50K revenue)

Track monthly:

Month | Gross Revenue | Apple Commission | Net Revenue | Expenses | Net Profit
Jan   | $1,200        | $180             | $1,020      | $150     | $870
Feb   | $1,350        | $203             | $1,148      | $99      | $1,049
...

Categories to track:

• Gross revenue (total sales)
• Apple commission (15% or 30%)
• Net revenue (what Apple pays you)
• Development expenses
• Marketing expenses
• Tools and services
• Professional services
• Net profit (net revenue minus all expenses)
• Tax set-aside (25-35% of net profit)

Option 2: Accounting Software ($50K+ revenue or if you want automation)

Tax Reserve Rule

Set aside 25-35% of net revenue (after Apple's cut) for taxes.

Open a separate savings account, transfer ~30% of every payout in, and use it only for quarterly tax payments.

Step 6: When to Hire

Hiring too early burns cash. Hiring too late burns you out. Use these guidelines.

Designers

When to hire:

• Your app icon looks amateurish compared to competitors
• Users comment on visual design in reviews
• You have maxed out SF Symbols and system UI components
• You need a marketing website, press kit, or App Store screenshots

What to pay:

• App icon: $200-1,000 (one-time)
• Full app design: $2,000-10,000 (one-time)
• Ongoing design: $50-150/hour (contract)

Where to find:

• Dribbble, Behance (portfolios)
• Twitter/X indie design community
• Referrals from other indie developers

Customer Support

When to hire:

• You spend > 5 hours/week on support emails
• Response time > 48 hours (users notice)
• Support is taking time away from development

What to pay:

• Part-time VA: $15-30/hour
• Dedicated support: $2,000-4,000/month

Where to find:

• Online communities for virtual assistants
• Referrals from other indie developers
• Start with a part-time contractor, not full-time

Marketing

When to hire:

• You have confirmed product-market fit (good retention)
• You know your acquisition cost and LTV
• Growth is limited by awareness, not product quality

What to pay:

• Freelance marketing: $50-150/hour
• ASO consultant: $500-2,000/month
• Content creator: $100-500/post

Contract Developers

When to hire:

• One-time platform expansion (watchOS, macOS port, widgets)
• Feature that requires expertise you lack (ML, AR, accessibility)
• You want to ship faster for a specific launch window

What to pay:

• iOS developer (contract): $75-200/hour
• Specialized (ML, AR): $100-250/hour
• Fixed-price project: define scope clearly, include revisions

Budget Rule

Do not hire until you can pay for 3 months from app revenue. Do not use personal savings to hire for a side project. The app should fund its own growth.

Can you pay this person for 3 months from app revenue alone?
├── YES → Hire (start with a trial project / 1-month contract)
└── NO → Wait until revenue supports it, or do it yourself

Step 7: Insurance and Liability

Professional Liability Insurance (Errors and Omissions)

• Covers claims that your app caused harm due to errors, bugs, or bad advice.
• Cost: $500-1,500/year for indie developers.
• Consider if: your app gives health, financial, or safety-related advice.
• Providers: Hiscox, Hartford, biBERK, general business insurance brokers.

Cyber Liability Insurance

• Covers data breach costs (notification, credit monitoring, legal defense).
• Cost: $500-2,000/year depending on data volume.
• Consider if: you store personal user data on your servers.
• Less relevant if: your app is fully offline / on-device only.

LLC as Liability Shield

• An LLC separates your personal assets from business liabilities.
• If someone sues your app business, they cannot (generally) take your house or personal savings.
• Must maintain separation: separate bank account, do not commingle funds, sign contracts as the LLC.
• An LLC does NOT protect you from personal negligence or fraud.

Step 8: Financial Planning for Indie Sustainability

Before Going Full-Time Indie

Checklist:

• 6 months of personal expenses saved (emergency fund)
• App revenue covers at least 50% of personal expenses (and growing)
• Health insurance sorted (US: marketplace, spouse's plan, or COBRA)
• Tax situation understood (talked to CPA)
• Spouse/partner on board with the plan and timeline
• Defined a "go back" threshold (if revenue drops below $X for Y months)

Revenue Milestones

Note: These are NET revenue figures (after Apple's cut and expenses, before taxes). Adjust for your location's cost of living.

Multiple Revenue Streams

Do not depend on a single app for your entire income. Strategies for diversification:

Recommended portfolio for sustainability:

• 1-2 apps generating recurring revenue (primary income)
• Part-time consulting/freelancing (stable fallback)
• Content creation / writing (builds authority, generates leads for consulting)

Runway Calculation

Monthly personal expenses:        $______
Monthly app net revenue:           $______
Monthly consulting revenue:        $______
Total monthly income:              $______

Monthly surplus/deficit:           $______ (income - expenses)
Emergency fund balance:            $______
Runway (months):                   emergency fund / monthly expenses = ______ months

Sustainability ratio:              monthly income / monthly expenses = ______
                                   > 1.0 = sustainable
                                   > 1.5 = comfortable
                                   > 2.0 = thriving

Output Format

Present business guidance as:

# Indie Business Assessment: [User's Situation]

## Current Status
**Location:** [Country/State]
**Entity:** [Current entity type]
**Revenue:** [Approximate level]
**Status:** [Full-time employed / Part-time indie / Full-time indie]

## Recommendations

### Business Entity
**Recommendation:** [Entity type]
**Why:** [1-2 sentences]
**Action items:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

### Tax Obligations
- [ ] [Specific tax obligation based on their situation]
- [ ] [Another obligation]
**Estimated tax rate:** [X-X%]
**Quarterly payment amount:** ~$[X]

### Financial Health
| Metric | Current | Target |
|--------|---------|--------|
| Monthly net revenue | $X | $X |
| Expense ratio | X% | < 30% |
| Tax reserve | $X | $X |
| Emergency fund | X months | 6 months |
| Sustainability ratio | X.X | > 1.5 |

### Next Steps (Priority Order)
1. 🔴 [Most urgent action]
2. 🟠 [Important but not urgent]
3. 🟡 [Plan for this quarter]

References

• analytics-interpretation/ — For understanding if your metrics support business decisions
• monetization/ — For pricing strategy and revenue model selection
• community-building/ — For organic growth that reduces acquisition costs
• Apple Small Business Program: https://developer.apple.com/app-store/small-business-program/

---

Supporting file: press-media/pitch-templates.md

Pitch Templates

Email templates for press and media outreach. Customize every template for each recipient — generic mass emails get ignored.

General Tips (Apply to All Templates)

• Subject line: Keep under 60 characters, include app name, be specific
• Opening line: Reference something the journalist recently wrote or covered — proves you did your homework
• Body: Under 200 words total. Journalists receive hundreds of emails daily.
• One screenshot inline: Embed one compelling screenshot directly in the email (not as attachment)
• Links: Include App Store link, press kit link, TestFlight link (if pre-launch)
• Call to action: One clear ask — "Would you like a TestFlight invite?" or "Can I send a promo code?"
• Signature: Name, title, website, social media handle

---

Template 1: Launch Pitch

Use for new app launches. Best sent 2-3 weeks before launch.

Subject: [App Name] — [One-Sentence Value Proposition] (launching [date])

Hi [First Name],

I loved your recent piece on [their article/topic] — [brief, genuine comment showing you read it].

I'm reaching out because I'm launching [App Name], a [category] app for [platform] that [one sentence explaining what it does and why it matters].

[App Name] is different because [unique angle — privacy-first / solo developer story / innovative tech use / solves a specific problem]. [One sentence expanding on the story angle.]

Key details:
- Launch date: [date]
- Price: [free / $X.XX / subscription at $X.XX/mo]
- Platforms: [iOS 17+ / macOS 14+]
- Press kit: [URL]

[Embedded screenshot — choose your most visually impressive screen]

I'd love to offer you early access via TestFlight if you're interested. Happy to answer any questions or hop on a quick call.

Best,
[Name]
[Website] | [Twitter/X handle]

---

Template 2: Major Update Pitch

Use for significant feature updates. Best for apps that already have some users.

Subject: [App Name] [version] — [headline feature] now available

Hi [First Name],

[App Name] just shipped its biggest update yet, and I thought it might interest you given your coverage of [relevant topic/category].

What's new in [version]:
- [Feature 1]: [one sentence — the hero feature]
- [Feature 2]: [one sentence]
- [Feature 3]: [one sentence]

The headline feature, [Feature 1], lets users [specific benefit]. I built it because [brief story — user request / personal need / new Apple API].

[App Name] now has [social proof — X downloads / X rating / featured by Apple]. This update is free for existing users.

Press kit with new screenshots: [URL]
App Store: [URL]

Would you be interested in taking a look?

Best,
[Name]
[Website] | [Twitter/X handle]

---

Template 3: Story Angle Pitch (Developer Story)

Use when the story is about YOU, not just the product. Best for outlets that cover indie developers.

Subject: [Compelling one-line story hook]

Hi [First Name],

I've been following your coverage of indie developers, especially [specific piece they wrote]. I have a story that might resonate with your audience.

[2-3 sentences telling your story — why you built this app, what personal experience drove it, what makes your journey unusual or interesting.]

The result is [App Name], a [category] app that [what it does]. [One sentence on traction or reception — downloads, ratings, user testimonials, Apple feature.]

I'm not just pitching an app — I think there's a story here about [broader theme: indie sustainability / building for accessibility / leaving big tech / solving personal problems with code]. I'd be happy to share more details or do an interview.

App Store: [URL]
Press kit: [URL]

Thanks for considering,
[Name]
[Website] | [Twitter/X handle]

---

Template 4: Podcast Pitch

Use for podcast hosts. Keep it shorter — they need to see interview value, not just app features.

Subject: Podcast guest pitch — [one-line hook about your story]

Hi [Host Name],

I'm a listener of [Podcast Name] and particularly enjoyed your episode about [specific episode]. [One genuine sentence about why it resonated.]

I'm [Name], an indie developer who [brief personal hook — quit FAANG / built app while traveling / went from zero to $X revenue / overcame specific challenge]. I recently launched [App Name], a [category] app that [one sentence].

I think your listeners would enjoy hearing about:
- [Topic 1 — something practical they can learn from]
- [Topic 2 — a challenge you faced and how you solved it]
- [Topic 3 — a broader insight about indie development]

I'm comfortable on mic and can keep things conversational. Happy to work around your schedule.

Best,
[Name]
[App Name] — [URL]
[Twitter/X handle]

---

Template 5: Follow-Up

Use exactly once, 5-7 business days after the initial pitch. Add new information — do not just repeat the original pitch.

Subject: Re: [original subject line]

Hi [First Name],

I wanted to follow up on my email from last week about [App Name].

Since then, [add one piece of new information]:
- "[App Name] was just featured in [Apple editorial / another outlet / award]"
- "We hit [milestone — 1,000 downloads / 4.8 star rating / featured by Apple]"
- "I just shipped [new feature] that I think adds to the story"
- "A user shared this testimonial: '[brief quote]'"

If the timing isn't right or [App Name] isn't a fit for your coverage, no worries at all — I appreciate your time either way.

Press kit: [URL]
TestFlight: [URL]

Best,
[Name]

---

Personalization Checklist

Before sending ANY pitch, verify:

• Used the journalist's first name (spelled correctly)
• Referenced a specific recent article they wrote
• Explained why THIS journalist is the right person for THIS story
• Kept total email under 200 words
• Included one inline screenshot
• Included press kit and App Store links
• Proofread for typos (nothing kills credibility faster)
• Sent on Tuesday-Thursday, 9-11 AM in their time zone
• Subject line is specific and under 60 characters

What NOT to Do

• Do not send identical emails to multiple journalists at the same outlet
• Do not CC or BCC multiple journalists (always individual emails)
• Do not attach large files (link to press kit instead)
• Do not use "Dear Sir/Madam" or "To whom it may concern"
• Do not send more than one follow-up
• Do not pitch on the same day as a major Apple event
• Do not ask "did you get my email?" — it's passive-aggressive
• Do not offer payment for coverage (violates journalistic ethics)
• Do not get upset or respond negatively if they don't cover you

---

Supporting file: press-media/SKILL.md

Press & Media Outreach

Get press coverage and media attention for your indie Apple app. Covers everything from press kit preparation to finding the right journalists to crafting pitches that get responses.

When This Skill Activates

Use this skill when the user:

• Wants press coverage for their app
• Is preparing for a launch and wants PR
• Wants to create a media kit or press kit
• Is looking for reviewers, bloggers, or YouTubers
• Asks about getting featured by Apple-focused outlets
• Wants to pitch their app to podcasts

Process

Step 1: Gather Context

Ask the user via AskUserQuestion:

1. App details: What does the app do? What platform(s)?
2. Launch timing: When is/was the launch? Is this a new app or major update?
3. Story angle: What makes this app unique or interesting?
4. Previous coverage: Have you been covered before? Any existing press kit?
5. Budget: Any budget for PR, or purely organic outreach?

Step 2: Press Kit Preparation

A press kit makes it easy for journalists to write about your app. If they have to hunt for information, they will skip you.

Required Assets

Fact Sheet Template

APP NAME: [Name]
DEVELOPER: [Your Name / Company]
LAUNCH DATE: [Date or "Available Now"]
PRICE: [Free / $X.XX / Free with subscription ($X.XX/mo)]
PLATFORMS: [iOS / macOS / iPadOS / watchOS / visionOS]
REQUIREMENTS: [iOS 17+ / macOS 14+]
WEBSITE: [URL]
APP STORE: [App Store link]
PRESS KIT: [URL to downloadable press kit]
CONTACT: [press@yourdomain.com]

KEY FEATURES:
- [Feature 1]: [One sentence description]
- [Feature 2]: [One sentence description]
- [Feature 3]: [One sentence description]
- [Feature 4]: [One sentence description]
- [Feature 5]: [One sentence description]

WHAT MAKES IT DIFFERENT:
[2-3 sentences on unique value proposition]

Press Kit Hosting Options

Recommendation: A /press page with a downloadable ZIP, everything inline so journalists can copy-paste without downloading.

Step 3: Finding Relevant Journalists and Outlets

Build a targeted list of 20-30 contacts. Quality over quantity — 20 personalized pitches outperform 200 generic ones.

Apple-Focused Outlets

Tier 1 — Major Coverage (hardest to get, biggest impact)

Tier 2 — Focused Coverage (more accessible, strong reach)

Tier 3 — Niche and Community (most accessible, targeted reach)

YouTube Reviewers

Search for "best iOS apps" or "best Mac apps" on YouTube. Look for:

• Channels with 10K-500K subscribers (large enough for reach, small enough to respond)
• Recent uploads (active channel)
• Previous indie app coverage (not just major apps)
• Professional review style (not just listicles)

Podcast Hosts

Step 4: Pitch Timing

When to Reach Out

Best Days and Times

• Best days: Tuesday, Wednesday, Thursday
• Best time: 9-11 AM in the journalist's time zone
• Worst days: Monday (inbox overload), Friday (winding down)
• Avoid: Major Apple events (WWDC, iPhone launch, iPad event), CES week, holiday weeks

Follow-Up Cadence

• Send initial pitch
• Wait 5-7 business days
• Send ONE follow-up (add new info or angle, don't just repeat)
• If no response after follow-up, move on — do NOT keep emailing
• Never guilt-trip or get frustrated in follow-ups

Step 5: Embargo Strategy

Embargoes let you give journalists early access in exchange for coordinated coverage on launch day.

Exclusive Strategy (Tier 1)

1. Pick ONE top-tier outlet that covers your app's category
2. Offer 1-2 week exclusive access before launch
3. Provide TestFlight build, press kit, and personal demo offer
4. Agree on publish date (your launch day)
5. Benefits: deep review, stronger relationship, headline coverage

Broader Embargo (Tier 2-3)

1. After exclusive is confirmed, invite 5-10 outlets under embargo
2. Set clear embargo lift date and time (usually launch day, 9 AM ET)
3. Include TestFlight link and press kit
4. Benefits: wave of coverage on launch day

Rules of Embargoes

• Always put embargo date/time in writing
• Honor the exclusive — don't give the same story to competitors
• If someone breaks embargo, never work with them again
• Be understanding if a small outlet publishes early by accident

Step 6: Story Angles That Get Coverage

Journalists don't write about apps — they write about stories. Frame your pitch around a story, not a feature list.

Story Angles That Work for Indie Developers

The Solo Developer Story

• "I quit my job at [Big Tech] to build the app I always wanted"
• "I built this while recovering from [life event]"
• "A 22-year-old student built a top-rated [category] app"
• Why it works: readers love underdog stories

Scratching Your Own Itch

• "I couldn't find a [category] app that [specific need], so I built one"
• "As a [profession], I needed [specific tool] — it didn't exist"
• Why it works: authentic, relatable, shows deep domain knowledge

Innovative Apple Technology Use

• "First app to use [new iOS/macOS feature]"
• "Built entirely with SwiftUI and [new framework]"
• "Uses on-device ML for [clever application]"
• Why it works: Apple-focused outlets love showcasing platform capabilities

Privacy-First Alternative

• "A [category] app that keeps your data on your device"
• "No accounts, no servers, no tracking"
• Why it works: privacy is a hot topic, especially for Apple audience

Accessibility Champion

• "Designed VoiceOver-first for visually impaired users"
• "Built to help people with [condition]"
• Why it works: feel-good story, Apple values accessibility

Design Excellence

• "What happens when a designer builds their own app"
• Award-worthy UI/UX (Apple Design Awards angle)
• Why it works: Apple-focused outlets value design deeply

Story Angles That Do NOT Work

• "My app is better than [competitor]" — sounds petty
• "My app has 50 features" — feature lists are boring
• "My app is the best [category] app" — let reviewers decide
• "I need coverage to grow" — journalists are not your marketing team
• "Check out my app" (no angle at all) — gives them nothing to write about

Step 7: After Coverage

When You Get Coverage

1. Thank the journalist publicly (tweet/post) and privately (email)
2. Share the article on all your channels
3. Add "As featured in..." to your App Store description and website
4. Screenshot the coverage for future press kit
5. Note which angle worked — use it for future pitches

When You Don't Get Coverage

• Do NOT send angry or disappointed emails
• Evaluate: was the pitch personalized? Was the timing right? Was the angle strong?
• Try a different angle next time (update, milestone, seasonal)
• Build the relationship anyway — comment on their articles, engage on social media
• Remember: most pitches don't get responses. A 10-20% response rate is normal.

Reference Files

See pitch-templates.md for:

• Launch pitch email template
• Update/feature pitch template
• Story angle pitch template
• Podcast pitch template
• Follow-up template

Output Format

Present outreach plan as:

# Press Outreach Plan: [App Name]

## Press Kit Status
- [ ] App icon (1024x1024)
- [ ] Screenshots (X screens, framed and raw)
- [ ] Description (short / medium / long)
- [ ] Developer bio and photo
- [ ] Fact sheet
- [ ] Press kit hosted at [URL]

## Story Angle
**Primary:** [The main story angle]
**Secondary:** [Backup angle if primary doesn't land]

## Target List (20-30 contacts)

### Tier 1 — Exclusive Target
| Outlet | Contact | Why Them |
|--------|---------|----------|
| [outlet] | [name] | [reason] |

### Tier 2 — Embargo Group
| Outlet | Contact | Why Them |
|--------|---------|----------|
| ... | ... | ... |

### Tier 3 — Broad Outreach
| Outlet | Contact | Why Them |
|--------|---------|----------|
| ... | ... | ... |

## Timeline
| Date | Action |
|------|--------|
| [T-3 weeks] | Send exclusive pitch to Tier 1 |
| [T-2 weeks] | Send embargo pitches to Tier 2 |
| [T-1 week] | Send broad pitches to Tier 3, follow up Tier 1 |
| [Launch day] | Embargo lifts, social media push, Product Hunt |
| [T+1 week] | Thank journalists, share coverage |

## Pitch Drafts
[See pitch-templates.md for templates, customize for each contact]

References

• pitch-templates.md — Email templates for all pitch types
• community-building/ — For organic promotion via social media
• app-store/ — For optimizing the product page journalists will link to

---

Supporting file: store-growth-audit/audit-checklist-p0-p4.md

Audit Checklist P0–P4 — Foundations (25 items)

Stanza format, flags, status vocabulary, and new-app: semantics are defined in SKILL.md. Evidence keys (EV.*) are defined in detection-playbook.md. IDs are stable — never renumber.

P0 — Day-one money toggles

P0.1 Small Business Program enrollment — core

• detect: MANUAL Q1
• rule: ✅ enrolled · 🔴 eligible but not enrolled · 🟠 not sure · applies-if: <$1M proceeds/yr (else ⚪ ineligible)
• new-app: plan — apply as soon as the account has (or will have) paid transactions; 15% vs 30% commission
• fix: growth/indie-business → ASC manual (enroll under Agreements)

P0.2 Billing Grace Period + Billing Retry enabled — core

• detect: MANUAL Q2 (+ EV.subs to establish applies-if)
• rule: ✅ both enabled · 🟠 one, or unsure · 🔴 neither · applies-if: has auto-renewable subscriptions
• new-app: plan — enable at subscription setup; recovers 5–15% of revenue lost to failed cards
• fix: generators/subscription-lifecycle → /apple:subscription

P0.3 Analytics baseline + peer-group benchmarks

• detect: HYBRID — EV.analytics (report configured, baseline recorded) + MANUAL Q3 (benchmarks checked)
• rule: ✅ baseline snapshot recorded AND benchmarks checked this quarter · 🟠 one of the two · 🔴 neither
• new-app: defer — activates once the app has 30 days of store data
• fix: growth/analytics-interpretation → /apple:learn-from-store

P0.4 Keyword research done (autocomplete + competitors + Apple Ads discovery probe)

• detect: HYBRID — keyword research artifacts (.planning/ASO.md keyword table or equivalent) + MANUAL Q4
• rule: ✅ researched list incl. popularity data exists · 🟠 informal/partial research · 🔴 keywords guessed
• new-app: plan — research before first metadata, not after
• fix: app-store/keyword-optimizer + app-store/apple-search-ads → /apple:metadata (or /apple:aso if installed)

P1 — On-metadata ASO

P1.1 Title, subtitle, keyword field optimized — core

• detect: MCP EV.meta
• rule: ✅ all three fields near their 30/30/100 limits, no cross-field duplicate words, keyword field comma-separated without spaces · 🟠 fields present but wasteful (duplicates, spaces, unused chars) · 🔴 subtitle or keyword field empty/default
• new-app: plan — score the drafted fields in ASO.md by the same rule
• fix: app-store/keyword-optimizer → /apple:metadata

P1.2 Cross-localization indexing exploited

• detect: MCP EV.locales + EV.meta
• rule: ✅ extra indexed locales for the primary storefront carry distinct keywords (e.g. en-GB, es-MX for US) · 🟠 extra locales exist but duplicate the primary keywords · 🔴 primary locale only
• new-app: plan
• fix: app-store/keyword-optimizer (advanced-tactics §1) → /apple:localize

P1.3 Developer name is a deliberate, descriptive choice

• detect: MANUAL Q5
• rule: ✅ descriptive or deliberately branded · 🟠 never considered · 🔴 misleading/squatted (rare)
• new-app: plan — one-time strategic choice; heavy to change later
• fix: app-store/keyword-optimizer (advanced-tactics §12)

P1.4 Promoted in-app purchases with keyword-bearing display names

• detect: MCP EV.iaps (display names; promoted flag may need MANUAL confirm)
• rule: ✅ promoted IAPs configured with descriptive 30-char display names · 🟠 IAPs exist, none promoted or names generic ("Pro Upgrade") · 🔴 none configured · applies-if: has IAPs/subscriptions
• new-app: plan — up to 20 promoted IAPs, each an indexed search result card
• fix: generators/promoted-iap → /apple:iap

P1.5 In-app event metadata used as indexed surface

• detect: MCP EV.events
• rule: ✅ at least one event in the last 6 months with keyword-conscious name/description · 🟠 events exist but metadata is throwaway · 🔴 never used · applies-if: app has event-worthy moments (judgment — else ⚪)
• new-app: defer — activates post-launch
• fix: generators/in-app-events → /apple:event

P1.6 Description + promotional text working

• detect: MCP EV.meta
• rule: ✅ benefit-led first paragraph AND promo text in use (it updates instantly, no review) · 🟠 description fine but promo text empty · 🔴 feature-list-only description
• new-app: plan
• fix: app-store/app-description-writer → /apple:metadata

P1.7 Metadata written for Apple's AI tagging + App Store Tags curated

• detect: MCP heuristic on EV.meta (copy unambiguous about what the app does and who it's for?) + MANUAL ("App Store Tags reviewed — irrelevant tags deselected?")
• rule: ✅ literal, tag-friendly copy incl. screenshot captions AND tags curated in ASC · 🟠 clever/metaphorical copy or tags never reviewed · 🔴 misleading copy or wrong tags left live
• new-app: plan
• fix: app-store/keyword-optimizer (advanced-tactics §13 + §15) → /apple:metadata

P2 — Conversion assets

P2.1 Icon is deliberate and has been tested

• detect: HYBRID — EV.ppo (any icon experiment ever) + MANUAL
• rule: ✅ icon tested via PPO or consciously chosen against competitors · 🟠 default/first-draft icon never revisited · 🔴 placeholder
• new-app: plan — icon is the single biggest conversion lever in search results
• fix: generators/product-page-optimization → /apple:icon + /apple:experiment

P2.2 Screenshots: first three carry benefit captions — core

• detect: HYBRID — EV.meta where screenshot info is exposed; else MANUAL
• rule: ✅ first 3 screenshots lead with benefit captions readable at thumbnail size · 🟠 screenshots fine but captions absent/feature-speak · 🔴 raw UI dumps
• new-app: plan
• fix: app-store/screenshot-planner → /apple:screenshots

P2.3 App preview video (once screenshots are solid)

• detect: HYBRID — EV.meta / MANUAL
• rule: ✅ preview video live · 🟠 planned/produced but not shipped · 🔴 none and screenshots already solid · applies-if: screenshots done (else ⚪ — sequence matters)
• new-app: defer
• fix: app-store/screenshot-planner → /apple:screenshots

P2.4 Trust signals: privacy labels, support URL, account deletion — core

• detect: HYBRID — EV.meta (support/privacy URLs live) + EV.code.accountdeletion + MANUAL Q6 (labels reviewed)
• rule: ✅ all three verified current · 🟠 URLs live but labels unreviewed, or account deletion N/A-unclear · 🔴 broken URL or missing deletion where accounts exist
• new-app: plan
• fix: legal/privacy-publish + generators/account-deletion → /apple:privacy

P2.5 Alternate icons pre-shipped for future PPO icon tests

• detect: CODE EV.code.alticons
• rule: ✅ candidate alternate icons in the shipped asset catalog · 🔴 none (icon PPO tests blocked one full release)
• new-app: code — ship candidates in v1.0; unused alternates cost nothing
• fix: generators/product-page-optimization → /apple:icon

P3 — Localization

P3.1 Metadata-only localization for the big seven — core

• detect: MCP EV.locales
• rule: ✅ ≥7 of {ja, de, fr, es, pt-BR, ko, zh-Hans} localized (title/subtitle/keywords minimum) · 🟠 1–6 non-English locales · 🔴 English only
• new-app: plan — metadata-only is Level 0 localization; the app itself can wait
• fix: product/localization-strategy → /apple:localize

P3.2 Per-storefront ratings strategy

• detect: HYBRID — EV.territories (where it's sold) + MANUAL (prompting strategy per market)
• rule: ✅ aware ratings don't carry across storefronts AND prompting actively in each target market · 🟠 selling wide, prompting only at home · 🔴 assumed the home rating shows everywhere
• new-app: defer — activates with first non-home-market push
• fix: app-store/ratings-mechanics → /apple:localize

P3.3 PPP pricing for India, Brazil, Turkey, Indonesia

• detect: MCP EV.pricing + EV.pricepoints
• rule: ✅ manual price points set for IN/BR/TR/ID below auto-equalized levels · 🟠 some manual overrides · 🔴 pure auto-equalization · applies-if: paid app or IAP/subs sold in those territories
• new-app: plan
• fix: monetization (pricing-models, Pricing Localization) → ASC pricing (dry-run via /apple:ship)

P3.4 App itself localized where demand is proven

• detect: HYBRID — EV.sales/EV.analytics by territory vs EV.code.locales
• rule: ✅ in-app localization matches the markets producing revenue · 🟠 a market >15% of revenue still un-localized in-app · 🔴 localized nowhere despite proven foreign demand · ⚪ no foreign demand signal yet
• new-app: defer
• fix: product/localization-strategy → /apple:localize

P3.5 Metadata updates automated via the ASC API

• detect: CODE EV.code.automation
• rule: ✅ scripted/bulk metadata pushes (fastlane deliver, ASC API scripts, bulk tooling) · 🟠 partially scripted · 🔴 35+ locales maintained by hand
• new-app: plan
• fix: /apple:localize + /apple:metadata (bulk update paths) — standalone: _shared/asc-api

P4 — Ratings machinery

P4.1 requestReview at success moments — core

• detect: CODE EV.code.reviewprompt
• rule: ✅ requestReview called at a success moment with condition gating · 🟠 called but at launch/random (guideline-safe but conversion-poor) · 🔴 never prompts
• new-app: code
• fix: generators/review-prompt → /apple:build

P4.2 Negative reviews answered — core

• detect: MCP EV.reviews
• rule: ✅ 1–3★ reviews from the last 90 days have developer responses · 🟠 some answered · 🔴 none answered (updated ratings replace old scores — replies are recoverable stars)
• new-app: defer — activates with first reviews
• fix: app-store/review-response-writer → /apple:ratings (gated replies via the ASC API)

P4.3 Phased release + manual version release habit

• detect: MANUAL Q7
• rule: ✅ both habits (7-day phased rollout, manual release after approval) · 🟠 one · 🔴 auto-release, full blast (one bad build can nuke the rating before you wake up)
• new-app: plan — set on the first release
• fix: app-store/ratings-mechanics → /apple:ship (phased release step)

P4.4 Never reset the ratings summary — guardrail

• detect: MANUAL (only if a reset is being considered; default ✅)
• rule: ✅ no reset planned/performed · 🔴 reset planned or recently performed
• new-app: plan — note the rule before v2.0 temptation arrives
• fix: app-store/ratings-mechanics (read it before touching the toggle)

---

Supporting file: store-growth-audit/audit-checklist-p5-p9.md

Audit Checklist P5–P9 — Growth Loops (29 items)

Stanza format, flags, status vocabulary, and new-app: semantics are defined in SKILL.md. Evidence keys (EV.*) are defined in detection-playbook.md. IDs are stable — never renumber.

P5 — Experimentation

P5.1 Product Page Optimization running as a habit — core

• detect: MCP EV.ppo
• rule: ✅ a PPO experiment ran in the last 2 quarters or after the last asset change · 🟠 ran once, long ago · 🔴 never (up to 3 treatments on organic traffic, one variable at a time)
• new-app: defer — activates ~30 days post-launch (needs traffic)
• fix: generators/product-page-optimization → /apple:experiment

P5.2 Custom Product Pages for distinct audiences

• detect: MCP EV.cpp
• rule: ✅ CPPs live, mapped to audiences/campaigns AND search keywords assigned per page (35 slots) · 🟠 pages exist but unkeyed/token · 🔴 none despite distinct audiences · ⚪ genuinely single-audience app
• new-app: defer
• fix: generators/custom-product-pages → /apple:experiment

P5.3 Creative Assets: Product Page Header + Search Results visuals

• detect: HYBRID — Asset Library state isn't exposed via the current MCP tools, so MANUAL ("header/search creative assets submitted in the Asset Library?") with EV.meta/EV.ppo as partial signals
• rule: ✅ header + search visuals live (pre-approved in the Asset Library, refreshed with campaigns) · 🟠 assets prepared but not submitted · 🔴 still default screenshots everywhere (surfaces render on iOS 27/iPadOS 27)
• new-app: plan — design header/search assets alongside the screenshot set
• fix: app-store/screenshot-planner (Creative Assets section) → /apple:screenshots

P5.4 In-app events cadence + badge variety

• detect: MCP EV.events
• rule: ✅ ≥1 event per quarter, badges varied by purpose · 🟠 sporadic events · 🔴 never used · applies-if: app has event-worthy moments (else ⚪)
• new-app: defer
• fix: generators/in-app-events → /apple:event
• note: new badge types (Now On Sale, Try Before You Buy) are ⏳ ANNOUNCED (WWDC26) — recheck each audit

P6 — Featuring & free discovery

P6.1 Featuring nominations as a rolling calendar — core, RECURRING

• detect: MANUAL Q8 + the scorecard's Recurring Calendar
• rule: ✅ nomination submitted for the current cycle AND next moment scheduled 6–8 weeks ahead · 🟠 submitted once, no calendar · 🔴 never nominated
• new-app: plan — first nomination at launch (launches are featuring moments)
• fix: generators/featuring-nomination → ASC manual (calendar maintained by the audit)

P6.2 New-OS APIs adopted at launch

• detect: HYBRID — EV.code.newapis + MANUAL timing (shipped within the new OS's launch window?)
• rule: ✅ current-cycle APIs adopted in a launch-window release (the most reliable featuring trigger) · 🟠 adopted late · 🔴 still targeting only old APIs
• new-app: code — build against the current SDK's new surfaces from day one
• fix: /apple:modernize — standalone: design/ + apple-intelligence/ adoption skills

P6.3 Secondary category set

• detect: MCP EV.meta (categories)
• rule: ✅ secondary category set and deliberately chosen (second chart presence) · 🔴 empty
• new-app: plan
• fix: /apple:ship (category step) — standalone: app-store/marketing-strategy (decision-matrix)

P6.4 Checkbox storefronts shipped where sensible

• detect: HYBRID — EV.code.platforms + EV.territories
• rule: ✅ viable easy ports shipped (Mac via Catalyst/iPad-on-Mac, visionOS, watchOS, tvOS — tiny catalogs, easy charts and featuring) · 🟠 viable port identified but not shipped · ⚪ no sensible port
• new-app: plan — check the checkbox platforms at project setup
• fix: /apple:new-app (platform choice) / /apple:plan — standalone: visionos/, watchos/, ios/ipad-patterns

P6.5 App Intents as an out-of-store discovery channel

• detect: CODE EV.code.intents + EV.code.spotlight
• rule: ✅ App Shortcuts + Spotlight indexing shipped (Siri, Spotlight, Shortcuts become discovery surfaces) · 🟠 intents exist but no AppShortcutsProvider/Spotlight · 🔴 none
• new-app: code
• fix: apple-intelligence/app-intents + generators/spotlight-indexing → /apple:plan

P6.6 Web presence: apps.apple.com SEO + landing page + Smart App Banner

• detect: MANUAL Q9 (CODE if a web repo is at hand)
• rule: ✅ landing page live with Smart App Banner, store page ranks for the app's name queries · 🟠 landing page only · 🔴 no web presence
• new-app: plan — the store's web page ranks on Google from day one; give it help
• fix: app-store/web-presence

P7 — Paid & external traffic

P7.1 Apple Ads ladder: discovery → exact-match winners (+ CPP pairing)

• detect: MANUAL Q4 + EV.cpp (paired pages)
• rule: ✅ discovery feeding exact-match campaigns, winners paired with matching CPPs · 🟠 ads running unstructured · 🔴/⚪ no ads (⚪ if deliberately organic-only and P1–P6 healthy)
• new-app: defer — paid comes after the free machinery works
• fix: app-store/apple-search-ads → /apple:aso if installed

P7.2 Brand term defended

• detect: MANUAL Q4
• rule: ✅ brand campaign live (competitors bid on your name; brand CPAs are cheap) · 🟠 unsure · 🔴 brand undefended while competitors bid · applies-if: running ads or brand has search volume
• new-app: defer
• fix: app-store/apple-search-ads

P7.3 ASA→organic halo tracked

• detect: MANUAL
• rule: ✅ organic rank movement watched on paid keywords (paid conversion lifts organic rank) · 🟠 not tracked · ⚪ no ads
• new-app: defer
• fix: app-store/apple-search-ads + growth/store-signals → /apple:learn-from-store

P7.4 Compressed launch spikes

• detect: MANUAL Q10 / .planning/ launch plan
• rule: ✅ last major release compressed Product Hunt + press embargo + newsletter into 48h (chart velocity beats volume) · 🟠 channels used but spread out · 🔴 launches go out quietly
• new-app: plan — write the spike plan before launch week
• fix: growth/press-media + growth/community-building → /apple:release-notes (assets)

P7.5 Deal-site ecosystem used for price drops

• detect: MANUAL Q9
• rule: ✅ price drops timed knowing aggregators auto-scrape them (spike → chart climb → organic tail) · 🟠 price drops happen unannounced · ⚪ free app, no price to drop
• new-app: defer
• fix: app-store/web-presence (deal-site section)

P7.6 Pre-orders used (including regionally)

• detect: MANUAL Q11 + EV.territories
• rule: ✅ pre-orders used at launch or regionally when entering new storefronts (up to 180 days of accumulated taps) · 🟠 known but unused at last opportunity · ⚪ no upcoming launch/expansion
• new-app: plan — decide pre-order length before first submission
• fix: generators/pre-orders → /apple:ship

P7.7 Offer codes distributed

• detect: MANUAL Q11 + EV.iaps/EV.subs
• rule: ✅ URL-redeemable codes in use for influencers/communities/conferences · 🟠 configured, never distributed · 🔴 unused despite subs/IAP · applies-if: has subs/IAP
• new-app: defer
• fix: generators/offer-codes-setup → /apple:subscription

P7.8 TestFlight public link as a waitlist

• detect: MANUAL Q11
• rule: ✅ public link doubled as pre-launch waitlist (up to 10k testers → day-one installers) · 🟠 TestFlight private-only pre-launch · ⚪ already long-launched with no major relaunch coming
• new-app: plan
• fix: product/beta-testing → /apple:testflight

P8 — Earnings

P8.1 Paywall + pricing experiments — core

• detect: HYBRID — EV.code.paywall + MANUAL Q12
• rule: ✅ paywall variable (trial length, intro offer, layout) tested in the last 2 quarters · 🟠 paywall shipped, never experimented · 🔴 no deliberate paywall · applies-if: monetized
• new-app: plan (paywall) / defer (experiments)
• fix: generators/paywall-generator + monetization → /apple:subscription

P8.2 Win-back offers configured

• detect: MCP EV.subs (offers) — MANUAL fallback
• rule: ✅ win-back offers live (the App Store surfaces them to lapsed subscribers by itself) · 🔴 not configured · applies-if: subscriptions ≥ minimum eligibility
• new-app: defer
• fix: generators/win-back-offers → /apple:subscription

P8.3 Retention Messaging (save offer at cancel)

• detect: MANUAL Q ("Retention Messaging configured in ASC → Subscriptions?") — EV.subs partial signal
• rule: ✅ message + retention offer live on the cancel confirmation page, tested in sandbox · 🟠 message-only (no offer — offers reached +5.5pts save-rate lift vs +1.4 average in Apple's data) · 🔴 not configured · applies-if: auto-renewable subscriptions
• new-app: defer — activates with the first live subscribers
• note: ASC tier open to all developers; the real-time server API stays access-gated (interest form + sandbox performance test)
• fix: generators/win-back-offers (Retention Messaging section) → /apple:subscription

P8.4 US web checkout / External Purchase Links — core

• detect: HYBRID — CODE EV.code.extpurchase + MANUAL Q13
• rule: ✅ shipped with commission-flip architecture + analytics from day one (currently 0% commission; litigation ongoing — re-verify) · 🟠 planned/considered · 🔴 not considered · applies-if: US storefront + digital goods revenue
• new-app: plan — architect the flip switch before you need it
• fix: monetization/external-purchases

P8.5 Cross-developer bundles & suites

• detect: MANUAL Q14
• rule: ✅ partnered bundle live or in motion with complementary indie apps · 🟠 explored · ⚪ no sensible partner category
• new-app: defer
• fix: monetization/bundles-and-licensing

P8.6 Group Purchases + Volume Purchasing

• detect: HYBRID — EV.subs (StoreKit 2 subscriptions exist; volume price bands not exposed via current MCP tools) + MANUAL ("volume price bands configured? group value merchandised?")
• rule: ✅ volume pricing bands set (≤5) and group purchase merchandised where a team/school/family-of-buyers segment exists · 🟠 live-by-default but never configured (every seat sells at full price) · 🔴 institutional demand exists, nothing configured · applies-if: auto-renewable subs on StoreKit 2 + a multi-seat buyer segment
• note: live for StoreKit 2 subscriptions (WWDC26) — on by default; Family Sharing-enabled subs are opted out by default
• new-app: plan — decide the seats model with the subscription design
• fix: monetization/bundles-and-licensing → /apple:subscription

P8.7 Own-app bundles + Family Sharing

• detect: MCP EV.iaps + EV.subs (familySharable) + MANUAL (bundles)
• rule: ✅ Family Sharing enabled where it fits AND multi-app developers bundle their own apps · 🟠 either unexamined · ⚪ single free app · applies-if: paid/subs
• new-app: plan
• fix: monetization/bundles-and-licensing → /apple:subscription

P9 — Retention loop & ops

P9.1 Retention surfaces shipped

• detect: CODE — EV.code.onboarding, EV.code.notifications, EV.code.widgets, EV.code.liveactivity
• rule: ✅ onboarding + notifications + at least one ambient surface (widget/Live Activity) · 🟠 some · 🔴 none (retention feeds both ranking and LTV)
• new-app: code
• fix: generators/onboarding-generator, push-notifications, widget-generator, live-activity-generator → /apple:plan

P9.2 Quarterly keyword refresh from ASA search-term reports — core, RECURRING

• detect: MANUAL Q15 + the scorecard's Recurring Calendar
• rule: ✅ refresh done within the last quarter with search-term data · 🟠 refreshed without paid-data input · 🔴 keywords untouched for two-plus quarters
• new-app: defer — first refresh one quarter after launch
• fix: app-store/keyword-optimizer (advanced-tactics §14) → /apple:metadata

P9.3 Update freshness

• detect: MCP EV.meta (current version's release recency)
• rule: ✅ shipped within ~8–12 weeks (each release re-triggers indexing + freshness signals) · 🟠 3–6 months · 🔴 6+ months stale
• new-app: ⚪ pre-launch
• fix: /apple:next-version — standalone: growth/store-signals for what to ship

P9.4 The re-run loop is closed — RECURRING

• detect: the scorecard itself — Recurring Calendar rows have last done within cadence
• rule: ✅ PPO re-run after last asset change, featuring calendar rolling, benchmarks rechecked · 🟠 calendar exists, rows overdue · 🔴 no calendar
• new-app: plan — seed the calendar at launch
• fix: this skill (re-audit) + generators/product-page-optimization + growth/analytics-interpretation

---

Supporting file: store-growth-audit/detection-playbook.md

Detection Playbook — gather once, evaluate 54

The audit's evidence-gathering machinery. Run all three passes up front, store the evidence under the keys below, then evaluate every checklist item against the stored evidence. Never interleave gathering with scoring; never ask MANUAL questions one at a time.

Phase-scoped runs (SKILL.md → Scoped Runs) execute only the table rows whose "Feeds items" column intersects the scope — same three-pass order, smaller batches.

Pass 1 — MCP evidence batch (read-only, ~14 calls)

One call per row; each populates an evidence key consumed by the listed items.

Pre-launch mode: skip the batch (no live app); EV.meta-class evidence comes from .planning/ASO.md, APP.md, ROADMAP.md instead. Analytics not configured yet → note "baseline lands next cycle — route to store-signals to set up" (never call setup from the audit).

Pass 2 — codebase grep batch

One pass over the app repo (skip if no codebase is at hand — affected items fall back to MANUAL).

Pass 3 — the MANUAL question batch

One AskUserQuestion round covering every MANUAL/HYBRID item the first two passes can't settle. Ask only what's still unknown; phrase options so each maps directly to a status. "Not sure" is always an option and always scores 🟠 unverified.

Trim the batch: drop questions already answered by evidence (e.g. EV.code.extpurchase present → ask only about the commission-flip architecture, not whether it shipped). In portfolio mode ask only the account-level questions (1, 3, 4-brand, 8) once for all apps.

Freshness caveats

• Analytics/sales reports arrive on Apple's schedule; a missing report is "no data yet", not 🔴.
• EV.reviews developer-response coverage is the signal for P4.2 — count unanswered 1–3★ reviews from the last 90 days, don't judge tone here (that's review-response-writer's job).
• Evidence strings must be terse and dated where MANUAL: SBP: enrolled (user, 2026-07), locales: en-US, de, ja, PPO: last experiment 2026-03 (stale).

---

Supporting file: store-growth-audit/SKILL.md

Store Growth Audit

Walk an app — new or live — through the full App Store growth playbook, phase by phase, and produce a scorecard: what's installed, what's missing, what to do next, and who fixes it.

The invariant: every item has a detection rule. Status comes from an ASC read, a codebase check, or an explicit question — never from vibes. If the user doesn't know, the item is 🟠 unverified, not assumed ✅.

Where it fits (read the seams)

• Not store-signals. That is the continuous signal → backlog loop: are the numbers moving, did last cycle's bets pay off? This is the structural audit: is the machinery even installed? Run this quarterly (or pre-launch); run store-signals monthly. Trend questions route there.
• Not analytics-interpretation. Metric-quality judgments ("is 3.2% conversion good?") route there; this skill only records the baseline and whether benchmarks were checked.
• Fixes never happen here. Every 🔴/🟠 routes to a named sibling skill and (when driven from SwiftShip) an /apple:* command. This skill detects, scores, and routes. Read-only on ASC.

When This Skill Activates

• "Audit my app's growth / store presence / what levers am I missing"
• A new app is approaching first submission and needs a growth plan, not just metadata
• Quarterly re-audit cadence, or after a launch that undershot expectations
• Before deciding to spend on paid acquisition ("is the free machinery done first?")
• Portfolio triage: "which of my apps is leaving the most on the table"

The Model: P0–P9

54 items across ten phases. Each phase is a theme; the item detail lives in the checklist files.

Compressed priority (used for action selection, not the maturity ladder): P0 money toggles first → P1–P3 (metadata, conversion, localization) → P8.4 web checkout + P8.6 volume purchasing (the 2026-era revenue unlocks) → everything else → P7 paid traffic last. Paid spend on top of broken free machinery is burned money.

Reference Files

Audit Process

1. Resolve app, mode, and scope. Get the appId (from .planning/STATE.md when driven by SwiftShip, else list_apps + confirm with the user). App live on the store → existing mode; not yet shipped → pre-launch mode. Scope defaults to the full P0–P9; a named phase runs scoped (see Scoped Runs). A prior scorecard (GROWTH.md), if present, is the diff baseline.
2. Gather evidence — one pass, per detection-playbook.md. Run the full MCP read batch, the full codebase grep pass, and ONE batched AskUserQuestion round for every MANUAL item. Never interleave gathering with scoring; never ask questions one at a time.
3. Score all 54 items against the gathered evidence using each item's rule:. Honor applies-if: guards (⚪ N/A) and ⏳ ANNOUNCED flags. Every status carries a terse, citable evidence string (locales: en-US only, SBP: enrolled (user, 2026-07)).
4. Compute phase scores + maturity level (rules below), and — when a prior scorecard exists — per-item deltas: fixed / regressed / new since last audit.
5. Select the top 5 actions (rule below).
6. Write or refresh the scorecard — in a SwiftShip project this is .planning/GROWTH.md (schema in SwiftShip's templates/GROWTH.md); standalone, write GROWTH.md beside the audit. Append an audit-history row; refresh the recurring calendar's next-due dates.
7. Print the digest and route. Maturity level, phase bar, top-5 with routes, deltas, unanswered MANUAL items, next three calendar due-dates, and the suggested next command/skill.

Item Record Format

Each checklist item is a stanza:

#### P3.1 Metadata-only localization (ja de fr es pt ko zh-Hans) — core
- detect: MCP `list_locales`
- rule: ✅ ≥7 target locales localized · 🟠 1–6 non-English locales · 🔴 en-only
- new-app: plan — seed target locales in the first submission
- fix: product/localization-strategy → /apple:localize

• ID (P<phase>.<n>) is stable forever — scorecards diff by ID; never renumber.
• Flags after the name: core (phase-gating), RECURRING (calendar-driven), ⏳ ANNOUNCED (WWDC26).
• detect: MCP <tool> · CODE <grep> · MANUAL <question> · HYBRID (combination).
• rule: explicit ✅/🟠/🔴 thresholds; optional applies-if: guard → ⚪ N/A when it fails.
• new-app: how pre-launch mode scores it — plan / code / defer (see Modes).
• fix: sibling-skill → /apple:command — the skill path works standalone; the command half applies when driven from SwiftShip.

Status vocabulary: ✅ done/healthy · 🟠 partial, stale, or unverified · 🔴 missing · ⚪ N/A (applies-if failed; excluded from denominators) · ⏳ ANNOUNCED (not yet scoreable; excluded from denominators; carries prep: and recheck: lines instead of a live rule).

Scoring & Maturity

• Phase score: ✅ n / N applicable — ⚪ and ⏳ items are excluded from N.
• Phase grade:
  • Complete — all applicable items ✅
  • Working — ≥50% ✅ and no core item 🔴
  • Gaps — any core item 🔴, or <50% ✅
  • Not started — no applicable item ✅
• core items (13): P0.1, P0.2, P1.1, P2.2, P2.4, P3.1, P4.1, P4.2, P5.1, P6.1, P8.1, P8.4, P9.2.
• Growth maturity level (0–9): the highest P such that every phase ≤ P grades at least Working. An app with P0–P3 working but P4 in gaps is Level 3, no matter how good P5–P9 look. The ladder follows numeric phase order; the compressed priority shapes only action selection.

Top-5 action selection: from all applicable 🔴 + 🟠 items, order by compressed-priority tier (T1: P0 · T2: P1–P3 · T3: P8.4 + P8.6-when-live · T4: P4–P6, rest of P8, P9 · T5: P7), then within a tier: core first, 🔴 before 🟠, lowest effort first. Two overrides: an overdue RECURRING calendar item jumps to the top; always include at least one metadata-only quick win (shippable without a binary release).

Modes: Existing vs Pre-Launch

The first post-launch audit diffs cleanly against the pre-launch scorecard — same IDs, same schema.

Scoped Runs (single phase)

"Run phase 3" = audit + worklist for that stage only.

• Scope: one phase (P3, bare 3 accepted) or a short range/list (P1-P3, P0,P4). Default remains the full P0–P9 audit.
• Evidence: pull only the detection-playbook.md rows whose items are in scope — MCP calls, greps, and MANUAL questions alike. A P1 run needs get_metadata/list_locales/list_iap/ list_app_events, not sales reports or paywall greps.
• Scorecard: update only the in-scope phase tables and their Phase Scores rows; every other row stays untouched (stable IDs make the partial update safe). Append an Audit History row tagged scope: P3. Recompute the maturity level from the refreshed rows plus the untouched remainder — mark it (est.) if any out-of-scope phase has never been audited.
• Output: instead of the top-5, print the phase worklist — every applicable in-scope item with status, evidence, and route — ordered core first, 🔴 before 🟠, lowest effort first. End by offering to start the first route (gated, as always).
• A scoped run never rewrites items outside its scope, and never counts as a full re-audit for the Recurring Calendar's "announced-features recheck" row unless the ⏳ items are in scope.

Output Format

The scorecard file (schema = SwiftShip templates/GROWTH.md): header (app, date, mode, maturity) · phase-score table · top-5 actions · ten per-phase tables (ID | Item | Status | Evidence | Next step | Route) · Watchlist (⏳ announced) · Recurring Calendar · Baseline Metrics Snapshot · append-only Audit History.

The printed digest never dumps 54 rows:

Growth audit: <App> — Level 4/9 (existing, re-audit)
P0 ▓▓▓░ 3/4 · P1 ▓▓▓▓▓░░ 5/7 · P2 ▓▓▓░░ 3/5 · P3 ▓░░░░ 1/5 · P4 ▓▓▓▓ 4/4 …
Top 5: 1) P0.1 Apply to Small Business Program (route: growth/indie-business) …
Since last audit: 3 fixed, 1 regressed (P9.3 update freshness)
Unverified (you were unsure): P0.3 peer benchmarks, P7.2 brand defense
Calendar: featuring nomination due in 12 days · keyword refresh due 2026-10-01
Next: /apple:localize (or product/localization-strategy standalone)

Routing Map

The only place the full route list lives; stanzas carry the short form.

Caveats

• Read-only on ASC. The audit never mutates anything — not even analytics report setup (that routes to store-signals / /apple:learn-from-store). Surface → score → route.
• MANUAL honesty. Ask once, in one batch. "I don't know" scores 🟠 unverified — the scorecard tells the user what to go check, it never guesses.
• ⏳ items are rechecked every audit. Apple ships announced features on its own schedule; each ⏳ stanza carries a dormant detection rule — when the feature is live, apply it and drop the flag.
• Never reset the ratings summary (P4.4). That item is a guardrail, not a task: resetting discards accumulated social proof and is almost never recoverable. Default ✅; flip to 🔴 only if a reset is planned or happened — then route to app-store/ratings-mechanics to stop it.
• Stable IDs. New items get new numbers; retired items keep their row with status retired.

---

Supporting file: store-signals/signals-ledger.md

Signals Ledger & Backlog Formats

Reference formats for store-signals. SIGNALS.md is the durable ledger (one row per hypothesis, survives across cycles); the backlog section is appended to ROADMAP.md each run.

.planning/SIGNALS.md — the hypothesis ledger

Step 1 reads it, step 5 resolves the OPEN rows, step 6 appends new ones. Each row is one testable bet.

# Signals Ledger

| id | signal (evidence) | hypothesis | target metric | baseline | status | shipped-in | check-after |
|----|-------------------|------------|---------------|----------|--------|------------|-------------|
| S1 | 6/40 reviews ask "team mode" | team mode gives repeat reason to return | D7 retention | 14% | open | — | — |
| S2 | crash sig `-[Settings]` 4.1% sessions | fix settings crash | crash-free rate | 95.9% | shipped | v1.3 | 2026-07-15 |
| S3 | TTR 3.2% (poor) | bolder icon lifts tap-through | impression→download | 3.2% | win | v1.3 | 2026-07-01 |

• status: open (identified, not yet built) · shipped (change is live, awaiting check-after) · win / regression / neutral (verified in a later cycle) · retired (dropped).
• baseline: the metric value recorded at the time the hypothesis was written — never overwrite it; step 5 compares "now" against this frozen number.
• check-after: absolute date (~+14d post-ship) when the metric is expected to have moved.

Backlog section appended to ROADMAP.md

Every item carries the fields below so next-version can plan against evidence, not intuition.

## Backlog from store signals — <YYYY-MM-DD>

### <item title>
- **signal:** 6 reviews request "team/bracket mode"
- **evidence:** 6 of last 40 reviews; 4.6★ but 3 name it explicitly
- **type:** feature | bug | ASO | pricing | retention
- **hypothesis:** team mode lifts rating + D7 by giving a repeat-event reason to return
- **target metric + baseline:** D7 retention (now 14%); rating (now 4.6)
- **effort:** S | M | L
- **score:** impact × confidence ÷ effort
- **check-after:** +14d post-ship

### Declined (off-strategy / guardrail)
- <request> — declined because <reason vs POSITIONING.md / guardrail>

Loop-closure block (step 5 output)

## Loop closure — <YYYY-MM-DD>
| id | shipped-in | metric | baseline → now | verdict | action |
|----|------------|--------|----------------|---------|--------|
| S2 | v1.3 | crash-free rate | 95.9% → 99.4% | WIN | mark resolved |
| S3 | v1.3 | impression→download | 3.2% → 3.1% | NEUTRAL | keep watching |

Verdict rule of thumb (see analytics-interpretation for per-metric benchmarks): < 3pp move on a retention/conversion metric ≈ NEUTRAL (noise); a clear move in the wrong direction = REGRESSION → open a revert/rethink task.

---

Supporting file: store-signals/SKILL.md

Store Signals

Pull what the shipped app is actually telling you and convert it into the next backlog — then verify whether last cycle's bets paid off.

This is the missing arc that turns build → ship into a loop: ship → MEASURE → DIAGNOSE → next PLAN → build → ship → measure again… The ledger (SIGNALS.md) is what makes it a loop and not a monthly report.

Where it fits (read the seams)

• Not analytics-interpretation. That interprets a metric you hand it (is 14% D7 good?). This is the end-to-end operate loop: gather every signal → cluster → diagnose → write a metric-tagged backlog → close last cycle's hypotheses. It uses analytics-interpretation's benchmarks.
• Read-only on ASC. Never responds to reviews, never mutates metadata/pricing. It surfaces, gates on explicit OK, and routes the change to the right command (next-version, bugfix, metadata).
• Feeds planning. Output is a dated backlog appended to ROADMAP.md + rows in SIGNALS.md, consumed by /apple:next-version / /apple:release.

Prerequisites

• A live (or TestFlight) app; resolve its appId from .planning/STATE.md, else list_apps + confirm.
• .planning/ context: STATE.md, APP.md, POSITIONING.md (job-to-be-done + guardrails).
• .planning/SIGNALS.md if present — the OPEN hypotheses from prior runs (each with a target metric, recorded baseline, and "check-after" date). See signals-ledger.md for the ledger + backlog formats.

Flow

1. Load prior hypotheses. Read SIGNALS.md → the OPEN rows to verify in step 5.
2. Pull the signals (read-only), this period vs trailing:
   • Reviews / ratings — list_reviews (recent, lowest-star first; flag unanswered), get_review for detail.
   • Analytics — get_analytics_report: retention, funnel/conversion, acquisition, impression→download. No report configured yet → setup_analytics_reports and note "retention/funnel lands next cycle."
   • Sales — get_sales_report: proceeds/units vs trailing 7/30-day.
   • Stability / perf — get_diagnostics (crash/hang signatures) + get_perf_metrics (launch, memory, energy).
   • Beta — list_beta_feedback_crashes if in TestFlight.
   • Listing — get_metadata to spot ASO conversion problems against current copy.
3. Normalize & cluster. Dedupe reviews into recurring themes (requests / complaints / praise) with frequency; attach magnitude (users / revenue / retention implicated). Weight by frequency × revenue impact, not by how loud one reviewer is.
4. Diagnose, filter, prioritize. Map each cluster to the core metric it moves (rating · D7 · Pro conversion · crash-free rate · ASO conversion · proceeds); score impact × confidence ÷ effort. Strategy filter: cross-check POSITIONING.md — on-strategy → backlog; off-strategy → list under "Declined (why)" (never silently drop, never silently build). Carry the app's guardrails forward. Small-N (new app): say so, lean on qualitative reviews, flag low confidence.
5. Close the prior loop. For each OPEN hypothesis whose change shipped and whose "check-after" date passed: compare the target metric now vs its baseline → WIN / REGRESSION / NEUTRAL. WIN → resolve; REGRESSION → open a revert/rethink task; NEUTRAL → keep watching or retire.
6. Write the backlog. Append a dated, metric-tagged section to ROADMAP.md and update SIGNALS.md (one row per hypothesis; formats in signals-ledger.md). Then output a ranked digest (top 3-5 "what's hurting most, why, the proposed move"), the loop-closure results, and a suggested next command (/apple:next-version, /apple:bugfix for a hot crash, /apple:metadata for an ASO fix).

Portfolio mode

With no single app (or --portfolio): run steps 2-4 across every app in list_apps, then rank which app to invest in next — biggest fixable revenue/retention/rating gap first (pairs with portfolio-health-monitor). Output one line per app + the single highest-ROI move overall.

Done

• A ranked cited digest, the WIN/REGRESSION/NEUTRAL loop-closure for last cycle, and a metric-tagged backlog written to ROADMAP.md + SIGNALS.md, with a routed next command.

Caveats

• Read-only on ASC — never auto-apply pricing, metadata, or review responses; surface → gate → route.
• Evidence over vibes — every backlog item cites its signal + magnitude; the loudest reviewer is not the roadmap.
• Always verify last cycle (step 5) before planning the next — that closure is the whole point.
• Apple delivers analytics on its own schedule; a freshly configured report is empty until next cycle.