What makes users delete an app (and how to prevent it)

The 72-hour window

Retention curves for mobile apps all look roughly the same. Steep drop on day one, slightly less steep on day two, then a long slow decline. The shape barely changes across categories. What changes is where the curve flattens out.

Apps that retain 25%+ at day 30 almost always have something in common: users who make it past the first three days tend to stick around. The battle isn't keeping a six-month user engaged. It's getting someone from install to their third day.

This is why most of what follows focuses on the first session and the first few days. If you fix those, the long-term numbers take care of themselves more than you'd expect.

Reason 1: you asked for too much before giving anything

The fastest way to lose a new user is to put a wall between them and the thing they downloaded your app for. Account creation screens, permission requests, tutorial carousels, email verification, profile setup. Every screen you put between “app opened” and “value delivered” costs you users.

I've seen apps that require account creation, notification permission, location access, and a four-screen tutorial before showing the main interface. Each of those steps loses 10-20% of the remaining users. Stack four of them and you've lost more than half your installs before anyone sees what the app does.

The fix isn't removing onboarding entirely. Some apps genuinely need account creation or specific permissions. The fix is reordering: show value first, then ask.

A habit tracker should let you log one habit before asking you to sign up. A photo editor should let you edit one photo before requesting camera access. A weather app should show the forecast before asking for location (use IP-based location as a fallback). The principle is always the same: give before you take.

For notifications specifically, the worst time to ask is on first launch. The best time is right after the user gets value from something notifications would improve. If your app tracks water intake, ask for notification permission after they log their first glass, not before.

Reason 2: they couldn't figure out what to do

This is more common than most developers think, because developers already know how their app works. The new user doesn't.

The tell is a high day-1 drop combined with very short session lengths. If people open the app, spend 30 seconds looking around, and never come back, they probably couldn't figure out the first action they were supposed to take.

Empty states are the biggest culprit. An app that opens to a blank screen with a small “+” button in the corner is an app that most new users will close. Compare that to an app that opens with sample data, a clear prompt (“Tap here to create your first project”), or a template picker.

The simplest test: hand your phone to someone who's never seen the app. Don't explain anything. Watch what they do. If they hesitate for more than five seconds on any screen, that screen needs work. This isn't formal usability testing. Just watch three people try it and you'll find 80% of the problems.

If you're tracking the right analytics events, you can spot this pattern without handing anyone your phone. Look at the gap between “app opened” and “first meaningful action.” If fewer than 60% of new users complete their first action within the first session, you have an activation problem.

Reason 3: it was slow, crashy, or ate their battery

Technical issues cause more deletions than most indie developers realize, because the people who delete over performance rarely leave reviews. They just leave.

The thresholds are lower than you think. If your app takes more than two seconds to launch to a usable state, that's slow. If it stutters while scrolling a list, that's enough for some people. If it crashes once during the first session, a significant chunk of users won't give it a second chance.

Battery drain is the silent killer. Users don't usually notice which app is responsible, but when they check their battery settings and see your app using 15% of their battery, it gets deleted immediately. Background refresh, location tracking, and aggressive sync schedules are the usual causes.

Storage is the other one. If your app is 300MB and the user gets a “storage full” warning from iOS, your app is on the short list for deletion. The storage management screen in iOS Settings sorts apps by size, and the big ones get cut first. Be as small as you reasonably can. Lazy-load assets. Don't cache aggressively unless users actively need offline access.

Check your crash reports weekly. Not monthly, weekly. A crash that affects 2% of sessions sounds small until you realize it means one in fifty users hits it. If that crash happens during onboarding, you're losing new users and never knowing about it.

Reason 4: you annoyed them with notifications

Notifications are a strange tool. Done right, they're the single best retention mechanism for mobile apps. Done wrong, they're the fastest way to get deleted.

The line between helpful and annoying is simpler than people make it: a notification is helpful if the user would have wanted to know this information at this time, even if you hadn't sent it. A reminder that your flight boards in 30 minutes is helpful. A “We miss you! Come back and check out what's new!” message is spam.

The specific types that trigger deletions, based on consumer surveys and what shows up in negative reviews:

• Marketing promotions disguised as updates
• Multiple notifications per day from the same app
• Notifications that interrupt and have no time sensitivity
• “Come back” re-engagement nudges
• Social notifications for actions by people you don't know

If you're a solo developer, keep it simple: only send notifications that are triggered by something the user did or something the user explicitly opted into. No batch marketing pushes. No re-engagement campaigns. Those are for apps with millions of users and teams that can A/B test frequency. For indie apps, one bad notification campaign can cost you a chunk of your user base that took months to build.

Reason 5: the app stopped being useful

Not every deletion is a failure. Some apps solve a temporary problem. A trip planner gets deleted after the trip. A wedding planning app gets deleted after the wedding. A conference app gets deleted after the conference.

For ongoing-use apps, though, “stopped being useful” usually means one of two things: either the user's situation changed, or a competitor did it better.

Situation changes are outside your control. Someone who tracked their runs might stop running. A budgeting app user might have sorted out their finances. This is healthy churn. You can't prevent it and you shouldn't try.

Competitive displacement is worth worrying about. If you're seeing steady retention for months and then a sudden dip, check whether a competitor launched a major update or a new app entered your category. The downgrade rage scanner and competitor listing analysis can help you spot these shifts before they hit your numbers.

The churn analysis approach applies here too. Track cohorts by acquisition date. If newer cohorts retain worse than older ones, something changed in the market. If all cohorts suddenly dip at the same time, check your recent updates.

Reason 6: you shipped a bad update

This is the one that stings the most because you caused it. A redesign that moved people's muscle-memory workflows. A feature that got removed because you thought nobody used it. A new bug that makes a core feature unreliable.

The pattern is distinctive: retention is stable for weeks or months, then drops sharply right after an update. If you see this in your analytics, check reviews from the same period. Users who feel strongly about a bad update will tell you. Often loudly.

Prevention is straightforward in principle and hard in practice: don't change workflows that people depend on without warning, and don't remove features without checking usage data first. If you must redesign, do it incrementally. Move one button at a time, not the entire interface.

If you've already shipped a bad update and see the retention drop, act fast. Acknowledge it in the release notes of the next version (“We heard your feedback about X. Here's what we changed back / what we fixed”). Respond to the negative reviews. People are surprisingly forgiving if you move quickly and honestly. The review response strategy matters more after a botched update than at any other time.

Reason 7: the paywall felt wrong

Users don't delete apps because they cost money. They delete apps because the price didn't match the perceived value at the moment they saw it.

The most common version: someone downloads a free app, uses it for two minutes, and gets hit with a $9.99/month subscription wall before they've experienced any real value. That's not a pricing problem. It's a paywall timing problem.

The other common version: the free tier is so limited that it doesn't demonstrate what the app can do. If your free tier only allows three items, or shows features behind blurred locks, users can't form an opinion about whether the app is worth paying for. They just leave.

The fix, which I covered in detail in the pricing guide, is making sure users hit the paywall after they've had a meaningful experience, not before. Let them create enough to care about losing access. Let them build a habit. Then ask.

Reason 8: they were cleaning out their phone

Sometimes deletion has nothing to do with your app specifically. People periodically scroll through their home screens and delete apps they haven't opened recently. iOS even suggests apps to offload in Settings. If your app hasn't been opened in three weeks, it's a candidate.

The defense against this is staying in the user's routine. Not through notification spam, but by being useful often enough that they never think of your app as dormant.

Widgets help a lot here, at least on iOS. An app with a home screen widget is visible every time the user unlocks their phone, even if they don't open the app itself. A weather app with a widget, a habit tracker with a widget, a finance app showing account balances. The widget keeps you present.

Apple Watch complications serve the same purpose for apps that make sense there. So do Live Activities and Dynamic Island integrations for time-sensitive features.

The underlying idea: occupy a surface the user already looks at, so your app stays “active” in their mind even between sessions.

How to catch deletion signals before they happen

You can't get a notification when someone deletes your app. Apple doesn't tell you. But you can track proxy signals that predict it.

Session frequency drop. If a daily user becomes a weekly user, they're on the path out. Track the distribution of days-between-sessions for each user. A shift from 1-2 days to 5-7 days is a warning.

Feature engagement narrowing. A user who used to interact with multiple features but now only opens the app for one thing is losing connection. They might still be retained, but they're fragile. One bug in that one remaining feature and they're gone.

Notification opt-out. When someone disables notifications for your app, they're telling you they want less of you. That's not a signal to send more. It's a signal that you were already sending too much, or that the content wasn't relevant.

Subscription downgrade or cancellation. Someone moving from annual to monthly, or canceling auto-renew, is testing whether they can live without you. The churn playbook covers this in detail, but the signal itself is useful even if you're not ready to build a full retention system.

None of this requires sophisticated tooling. If you're logging the five events I recommended (app open, first action, core action, conversion, error), you can derive most of these signals from that data.

The first-session checklist

If you fix nothing else, fix the first session. Run through this list for your app:

Time to value under 30 seconds. From the moment the app is usable (not just loaded, but usable), can the user do the main thing within 30 seconds? If not, what's in the way?

Zero required permissions before value. Can you defer every permission request until after the user has experienced the core feature at least once?

No account required for first use. Can you let people try the app anonymously and create an account later to save their data? If your app needs an account for core functionality (social apps, messaging), can you at least show them what the experience looks like first?

Empty state has direction. If the user has no data yet, does the screen tell them what to do? Not a tutorial. A clear next step. “Create your first X” is better than a blank screen.

Second session has a reason. After the first session, is there a reason to come back? A streak, a reminder they set, data that updates, content that refreshes. If the first session is complete and self-contained with no reason to return, most users won't.

Days 2 through 7: building the habit

The first session gets them in. The first week makes them stay. Here's what actually moves the retention numbers during this window.

Progressive disclosure of features. Don't show everything on day one. Let users discover features as they need them. If your app has a powerful but complex feature, surface it on day 3 or 4 through a subtle prompt or an in-app message. By then they understand the basics and are ready for more.

Contextual reminders, not scheduled pushes. A reminder that fires because the user set it is helpful. A reminder that fires because it's been 24 hours since their last session is annoying. If you can't build trigger-based notifications, build no notifications.

Quick wins. Give users something that feels like progress early in the week. A streak counter, a completed badge, a summary of what they've done. People are more likely to continue something they've already started. This isn't gamification. It's acknowledging their effort.

Data that grows in value. The more data a user puts into your app, the harder it is to leave. A journal app with two weeks of entries is harder to abandon than one with two entries. A finance tracker with categorized transactions becomes more useful over time. Design for accumulation.

Common mistakes I see indie developers make

Building retention features before fixing activation. Streaks, badges, and social features don't help if people never get past the first screen. Fix the first session first. Always.

Treating all users the same. A power user who opens your app five times a day and a casual user who opens it once a week need different experiences. If your re-engagement strategy treats them identically, you'll annoy the first group and under-serve the second.

Copying retention tactics from apps 100x your size. Spotify's Wrapped campaign works because a hundred million people use Spotify. Your app's year-in-review feature will feel hollow with two months of data from three hundred users. Scale your tactics to your stage.

Optimizing for DAU instead of value delivered. If your app genuinely only needs to be opened twice a week to be useful, don't try to make people open it daily. A weekly-use app with high satisfaction is better than a daily-use app that people resent opening.

Ignoring the deletion moment. When iOS shows the “Delete App?” confirmation, that's it. You get no callback, no last chance, no exit survey. Everything you do for retention has to happen before that moment. There are no second chances once the dialog appears.

Measuring what matters

You don't need complex analytics to understand retention. Start with three numbers:

Day 1 retention. What percentage of new users open the app the day after installing? Typical: 20-30%. Good: 35%+. If you're below 20%, your first session is broken.

Day 7 retention. What percentage are still active a week later? Typical: 10-15%. Good: 20%+. The gap between day 1 and day 7 tells you whether the habit is forming.

Day 30 retention. Typical: 5-8%. Good: 12%+. If you're above 15% at day 30, you have genuine product-market fit for the users who make it that far. The question becomes how to get more users to day 30, which circles back to fixing the first session.

Track these by cohort (week the user installed), not in aggregate. Aggregate retention can improve just because you had a good acquisition week, masking that your actual retention got worse. Cohort data tells you the truth.

App Store Connect gives you day 1, day 7, and day 28 retention for free, no SDK required. If you're not checking this monthly, start.

The 20-minute retention audit

If you do nothing else after reading this, spend 20 minutes on this:

Minutes 1-5: Delete your app from your phone. Reinstall from the App Store. Go through the first-time experience as if you've never seen it. Time how long it takes to reach the main feature. Note every screen that isn't directly moving you toward value.

Minutes 6-10: Open App Store Connect. Go to App Analytics > Retention. Look at your day 1, day 7, and day 28 numbers. Compare the last three monthly cohorts. Are they improving, stable, or declining?

Minutes 11-15: Read your most recent 1-star and 2-star reviews. Look specifically for complaints about the first experience: “couldn't figure out how to...”, “too many permissions”, “forced to create an account”, “paywall immediately.”

Minutes 16-20: Write down the single biggest friction point you found. Not three things. One thing. Fix that this week. Then repeat the audit next month.

This isn't glamorous work. There's no growth hack here. But the apps that retain users are the ones where someone went through this process repeatedly and kept smoothing out the rough edges.

When deletion is fine

Not all churn is bad. Some of it is the market telling you useful things.

If someone deletes your app because it's not what they expected from the App Store listing, that's an ASO problem, not a retention problem. Your screenshots or description attracted the wrong audience. Fix the listing, not the app.

If someone deletes because they finished what they needed (planned a trip, tracked a move, managed a one-time event), that's a sign your app worked. They got value. They might recommend it to someone else. They might come back for the next trip.

If someone deletes because a competitor genuinely does it better, learn from it. Check what they did differently. The zombie scanner finds apps on the other side of this equation: abandoned apps whose users are looking for exactly what you might build.

Retention isn't about keeping everyone forever. It's about making sure the people who should stick around actually do. If your validation was solid and you built what the market asked for, the retention will follow. Fix the friction, respect the user's time, and focus on making the first 72 hours as smooth as possible.