Common mistakes that make mobile apps slow and lose money

These are the problems I find most often when I audit Android and iOS apps. Most of them can be fixed without building a single new feature.

1. Showing ads before the user sees any value

The mistake: a new user opens the app for the first time, before they know what it does, and an interstitial ad fills the screen. They close it, and sometimes they uninstall. An ad worth a few cents just cost you a user you paid to get.

Do this instead: no ads until the user finishes their first real action, like opening a file, finishing a level or creating something. When we did this on one app, revenue went up and first-session uninstalls went down.

2. Putting ads where it's easy, not where it works

The mistake: a banner at the bottom and an interstitial on app open, with the same frequency cap for everyone.

Do this instead: use funnel data to show ads at natural pauses, like after the user finishes an action. Preload ads so they are ready, but not so early that they expire. This is how I took one app's show rate from 60% to 80% and revenue up 20%.

3. Making money from ads only

The mistake: users who would happily pay to remove ads have no way to do it, so they leave.

Do this instead: add a paywall next to your ads. Show it after the user gets value (not on first open), right after an ad, and on premium features. Offer both a one-time Remove Ads purchase and a subscription. Ads earn from users who won't pay, and the paywall earns from users who will.

4. Doing everything at startup, on the main thread

The mistake: Application.onCreate() sets up everything, and database reads, network calls and heavy setup all run on the main thread before the first screen appears.

Do this instead: move heavy work to a background thread and delay anything that isn't needed for the first screen. This is how I cut a fintech app's startup time by 40%.

5. Memory leaks and images nobody releases

The mistake: objects and images stay in memory long after the user has left the screen. The app "works", but Google Play's Android vitals now measure memory, and it counts against you.

Do this instead: run LeakCanary, fix what it finds, and release images when screens go away. More in how I make apps faster and use less memory.

6. Shipping release builds that aren't obfuscated

The mistake: the release build isn't properly shrunk or obfuscated, so the code is easy to reverse engineer.

Do this instead: set up your ProGuard / R8 rules properly, then install the release build on a real device before you ship, to make sure nothing important was stripped out.

7. Treating one-star reviews as complaints, not bug reports

The mistake: reading bad reviews and feeling defensive.

Do this instead: read them as bug reports. "It freezes when I check out" is the main thread blocked on that screen. "It was fine before the last update" is a regression. "I lost my data after updating" is a database migration that was never written. Before I touch a client's code, I read every one-star review from the last three months.

8. Not watching Android vitals

The mistake: nobody checks Play Console until something breaks.

Do this instead: check memory, crash rate and ANR rate in Android vitals. A crash rate above 1.09% or an ANR rate above 0.47% puts your app over Google's bad-behaviour threshold, and that affects how visible it is on Google Play.

9. Shipping AI-generated code nobody reviewed

The mistake: the app was built fast with AI, and nobody checked what it generated. I have found hardcoded credentials in plain text in a live app, and the same logic copy-pasted across dozens of files.

Do this instead: get a security and structure review before you scale. See how I fix vibe-coded apps.