The week after launch is where most indie apps quietly die. Not from bad code, but from the developer panicking, shipping too many random updates, and chasing every review. This is a steadier playbook for the first 90 days, with the exact retention thresholds (verified June 2026) that tell you whether to scale, narrow, or sunset.
TL;DR
- Days 0-3: confirm analytics emit data, then fix crashes only. Ship nothing else.
- Days 4-7: triage reviews by a fixed rule. Reply to specific-bug and concrete-suggestion reviews; ignore subjective negativity.
- Weeks 2-4: ship one targeted update, then track D1 and D7 retention against category medians (Productivity D7 ≈ 32%, all-vertical median D7 ≈ 13% as of June 2026).
- Weeks 5-12: make a go/no-go call on core value, then settle into a bi-weekly release cadence using phased release.
- Day 90: run a real review. The decision rests on D7 retention plus organic growth trend, not rating or NPS.
Background
Launch day produces a flood of low-quality signal: a few downloads, maybe one review, a slight ranking bump. New developers over-react to all of it. The right post-launch posture is to slow down, measure the four or five metrics that matter, and ship deliberate updates on a weekly or bi-weekly cadence. The App Store rewards consistency more than speed. Apps that ship reliable updates with clear release notes outperform those that ship five panic releases in week one.
Is this you?
- Your app has been live on the App Store for less than 90 days.
- You feel pressure to constantly ship, respond, or change things.
- You have not yet established a release cadence.
- You have fewer than 1,000 downloads but more than zero.
Quick verdict
In the first 90 days, prioritize: critical bug fixes (within 48 hours), retention measurement (continuous), one feature per 2-week cycle, and ignoring most reviews. Skip vanity metrics entirely.
Step by step
Each step has: specific metric + quantitative threshold + tool action. Have RevenueCat / TelemetryDeck / GA4 / App Store Connect open.
-
Day 0 — analytics must emit data.
Verify:
- [ ] App Store Connect → Trends, installs in last 24h > 0 - [ ] Crashlytics / TelemetryDeck / Sentry shows non-zero sessions - [ ] Custom events ("app_open", "onboarding_complete", "first_action") all firing - [ ] Push token registration > 70% (if you use push) - [ ] IAP tested in sandbox; first real-world purchase observedAny zero → fix today. Every later step depends on this signal.
-
D1-D3: crashes only, no other updates.
Thresholds:
crash-free user rate < 99.0% → investigate immediately crash-free session rate < 99.5% → investigate immediately any single stack trace affects ≥ 5% of users → must ship fix within 48hCrashlytics / Sentry entry: dashboard → “Issues” sorted by “users affected”. Top 3 → pull the stack trace, fix directly. Ship fixes via phased release. As of June 2026, Apple’s phased release ramps over 7 days at a fixed schedule: 1% → 2% → 5% → 10% → 20% → 50% → 100%, increasing one step every 24 hours. Turn it on in App Store Connect → your version → “Phased Release for Automatic Updates”. You can pause it for up to 30 days (no limit on pauses) if a regression appears, which is your safety valve. See Apple’s phased release documentation for the exact behavior.
-
D4-D7: triage reviews.
Rules:
1-star + describes a specific bug → personal reply + backlog ("Fixed in v1.0.2, please update") 1-2 star + subjective complaint ("ugly") → do not reply (sinks emotional energy, won't change rating) 3-4 star + concrete suggestion → personal reply + backlog 5 star → do not reply (don't pad with thanks)Tool: App Store Connect → “Ratings and Reviews” — reply inline. Filter
Country: All+Rating: ≤2. The payoff for replying to specific complaints is concrete: per AppFollow’s data across 100K+ interactions, users who get a developer response update their review roughly 38% of the time. So a precise reply with a fix ETA is a rating-recovery move, not just PR. Acknowledge the exact issue; a generic “thanks for your feedback” backfires.One related lever while you are here: rating prompts. Use Apple’s
SKStoreReviewController(orrequestReviewon iOS 18+) at a moment of success, such as right after the user completes their first real action. Apple caps it at 3 prompts per user per 365 days, so timing matters far more than frequency. Never prompt on app open or right after a crash. -
W2 — ship first real update (v1.1.x). Based on the first week’s signal, pick ONE:
Priority (in this order): 1. Feature bug affecting onboarding completion ("first_action" fires < 50% = onboarding broken) 2. ≥3 independent users requested the same missing feature 3. Crash fix (recurring sub-top-3 issue) Do NOT: - Overhaul UI (UI doesn't matter until onboarding works) - Add a whole new module (users haven't mastered the current one) - Chase a trend ("add AI", unless a real use case is clear)Ship a numbered release note (see app-store-listing-copywriting step 7).
-
W3-W4: track D1 / D7 retention against the right benchmark.
The single most common mistake here is comparing your numbers to a global average instead of your category. “Good retention” is only meaningful per category. Below are median retention figures as of June 2026 (Adjust / Unstar 2026 benchmark sets), with the all-vertical median as a floor.
Cohort All-vertical median Productivity / tools Social / messaging Streaming / media D1 26% 52% 48% 44% D7 13% 32% 28% 24% D30 7% 20% 14% 11% Top-quartile apps run roughly 1.5-2x these medians; bottom-quartile runs about 0.5x. Read your own numbers against your category row, then against these action thresholds:
D1 retention (open next day): < 20% (any category) → onboarding is seriously broken; users never reach value below category median → likely first-session friction; instrument the funnel > category median → core promise lands on day 1 D7 retention (open after 7 days): < 5% → core value not working; no listing tweak fixes this 5-10% → weak fit; narrow the audience before scaling > category median + rising → ready to scale acquisitionA note on productivity apps specifically: a D1 below ~45% almost always means the user did not create their first artifact (note, task, project) in session one. Fix the first-run-to-first-artifact path before anything else.
Tools (June 2026):
- Free + privacy-first: TelemetryDeck (native Apple, free up to 100,000 signals/month, roughly 3,300 monthly active users; funnels and retention dashboards included on the free tier).
- Built in: App Store Connect → Analytics → Retention (data lags a day or two, but the trend is reliable and it costs nothing).
- Powerful: Mixpanel or Amplitude (generous free tier, then usage-based; expect ~$0-25/month at indie volumes).
Screenshot weekly; x-axis = cohort (week N signup), y-axis = D7 retention. You are watching the trend across cohorts, not any single day.
-
W5-W8: core value go/no-go decision.
Decision tree:
if D7 ≥ 10% AND D7 trend rising: core value works → move to scaling rhythm (W8-W12) elif D7 ≥ 10% AND flat / declining: partial fit → run user interviews + funnel analysis elif D7 in 5-10%: weak fit → narrow the audience ("for night-shift nurses" not "for everyone") elif D7 < 5%: no listing-optimization fix → pivot or sunsetUser interviews: pick 5 random active users from the last 7 days (export from RevenueCat / Mixpanel), email them, offer a $10 Amazon gift card for a 20-minute call. Five fixed questions:
1. How did you find this app? 2. After installing, what specifically did you expect it to solve? 3. When you first opened it, what most disappointed or confused you? 4. How often do you open it now? Which exact moment makes you open it? 5. If you had to uninstall today, what would the reason be? -
W8-W12 — establish bi-weekly release cadence. Add a recurring calendar event
Every other Tuesday: ship v1.X.0:2-week cycle: D0 (Tue) Pick 1-3 changes, draft release note D1-D8 Develop + internal QA D9 Internal build review D10 (Thu) TestFlight external (50 testers) D11-D12 Collect TestFlight feedback D13 (Mon) Submit for review D14 (Tue) Approved → phased release startsHard cap: 1-3 changes per release + a theme (“This release: onboarding rewrite”). No 10-item changelogs.
-
D90: real review + decision. Build
90_day_review.md:# 90-day review — <App name> — <date> ## Core data - Total installs: X - D1 retention: X% (industry avg Y%) - D7 retention: X% (industry avg Y%) - D30 retention: X% - Paid conversion (if any): X% - Average LTV: $X - CAC (if running paid): $X ## Channel breakdown | Channel | Installs | D7 ret | Rating | Notes | |---------------------|----------|--------|--------|-------| | Organic search | | | | | | App Store editorial | | | | | | X / social | | | | | | Friends / community | | | | | ## Decision [ ] Commit next quarter, primary focus: <specific direction> [ ] Pivot: keep X, redo Y [ ] Sunset: maintenance only [ ] Walk away: open-source / archivePrimary decision = D7 retention + organic growth trend. Don’t lean on NPS / rating — both are easy to self-deceive on.
Common pitfalls
- Refreshing App Store Connect every hour. Update intervals are slow and the data is noisy at low volumes.
- Responding to every review. Respond to specific bugs and accusations only; ignore subjective negativity.
- Shipping 5 updates in week one because you keep finding small things. Batch them.
- Treating downloads as the success metric. Downloads matter only inasmuch as they produce retained users.
- Buying ads or installs before understanding organic retention. You will burn money on the wrong funnel.
- Letting one bad review derail planning. One review is one data point.
Who this is for
Indie developers in their first 90 days post-launch on the App Store.
When to skip this
Established apps with stable user bases — your iteration framework should be more sophisticated.
FAQ
- How often should I ship updates?: Every 1-2 weeks is a healthy rhythm. Less often and you lose momentum; more often and updates feel chaotic to users.
- What do I do about a one-star review?: If it cites a real bug, respond with a fix ETA. If it is generic (“hate this”), ignore — your response cannot help, and engagement amplifies it.
- When should I start paid acquisition?: After you have 90 days of retention data and know the cost of organic users. Paid before that is gambling.
- How do I know if the app is failing?: 7-day retention under 10% with no obvious explanation is the strongest signal. Crash rate above 1% is the second. Below these, give it time.