How I make mobile apps faster and use less memory

A slow app is not just a technical problem. It is a revenue problem. Here are real client apps I made faster and lighter, and what changed for the business.

Client 1: a laggy app stuck at $1,000 MRR

The problem: the client's app was stuck at $1,000 in monthly recurring revenue. He thought the app was slow, and he was right. Users were opening it, hitting a laggy screen, and leaving before they saw what the product could do. Retention was holding back growth, not marketing or pricing.

What I found: I used the app the way a normal user would. The slowness was obvious within the first minute: glitchy transitions and screens that took too long to load. Each one feels small, but together they tell the user the app isn't ready.

What I did: fixed the slow screens and transitions so the main flow felt fast and smooth.

The result: the month after the update went live, his MRR crossed $2,000. Same app, same marketing, same pricing. Just faster and smoother.

Client 2: memory problems users couldn't see

The problem: the app worked fine on the surface. But Google Play's Android vitals now measure memory, and this app was failing the new thresholds. Google has said apps that fail them will lose visibility on the Play Store from February 2027.

What I found and fixed:

• Image loading: images were kept in memory long after the user left the screen, a classic bitmap retention problem. I changed the loading strategy so images are released when they are no longer needed. Memory use dropped noticeably.
• Memory leaks: LeakCanary flagged three leaks nobody knew about: objects kept in memory long past their lifecycle. I fixed all three.
• Obfuscation: the release build was not properly obfuscated, which made the code easy to reverse engineer. I fixed the ProGuard rules so release builds are properly shrunk and obfuscated.

The result: the app now carries much less dead weight on every launch, and it is ready for the new thresholds before they are enforced.

Client 3: a fintech app that was slow to start

Memory leaks and heavy work on the main thread were slowing down a fintech app's launch. Fixing them cut startup time by 40%. Read the full case study.

How I find these problems

1. Use the app like a normal user. I go through the main flow and note where it feels slow or where I hesitate.
2. Read the one-star reviews. Users describe technical problems in plain words. "It freezes when I pay" usually means the main thread is blocked on that screen.
3. Check the crash reports. If Firebase Crashlytics is set up, I start with the top five crashes by frequency.
4. Measure. Memory use, startup time and main-thread blocking, with tools like LeakCanary, ANR-WatchDog and Android Studio's profilers.
5. Only then open the code, already knowing what to look for.

A quick check you can do today: open Play Console, go to Android vitals and look at memory, crash rate and ANR rate. A crash rate above 1.09% or an ANR rate above 0.47% puts your app over Google's bad-behaviour threshold.