Case study
Why your Android app feels slow after every update
Our own Android app is updated almost every day, and the people using it said it lagged. The cause was not one heavy screen but repeated work, a phone relearning the app after each release, and a demo that crashed only on real phones.
Key takeaways
- A slow app usually has several small repeated costs rather than one heavy screen, so the complaint is hard to trace from descriptions alone.
- Android learns an app's instructions over days after each install, so frequent updates keep pushing the app back to its slow start.
- A baseline profile ships inside the app so Google Play can prepare the main screens at install, and it needs recording again whenever those screens change.
- Checks that run on a computer can pass while a real Android phone refuses the same thing, so watch the app on a handset before a release.
Our own Android app is updated almost every day, and the people using it had started to say it lagged: a screen taking a moment to answer, a list stumbling as it scrolled, the first seconds after opening it heavy. They raised it on 23 October 2026, we found the causes and reworked the repeated parts the next day, and we refreshed one piece of it again on 25 October once the screens had changed. Nothing was broken anywhere, which is exactly what made it hard to point at.
A slow app costs a business even when nothing is broken
People rarely report lag; they open the app less, answer later, and in the end stop using it. Every delay also reads as the business behind the app being slow, whatever the cause. In our app there was no heavy screen and no fault to point at, which is why the complaint was hard to pin down.
Why an Android app feels slow after an update
An Android app is slow after an update because the phone does not fully prepare the app's instructions when it installs it: it runs them cautiously at first, and learns over days which parts are used. An app that updates almost every day sends the phone back to that cautious start each time, and people never stay on one version long enough for the learning to finish.
A baseline profile is the remedy for that half of the problem. It is a recording, made once on a test phone, of the parts of the app the main screens use, shipped inside the app so that Google Play can prepare them when it installs an update.
What our engineer found on a test phone
The lag was not one heavy screen but several small costs landing at the same moments.
- When several messages arrived together, each one set off its own fresh load of the same screens, so a burst meant a burst of loading.
- A screen asked for again while its first load was still on its way sent a second, identical request.
- Long lists were built whole, including the rows nobody had scrolled to.
- At start-up, stored files were unlocked and read on the part of the app that draws the screen, so drawing had to wait.
- The demo that opens the app for new visitors crashed on its first frame. Three pieces of text in it were written in a way that the checks on a computer accepted and Android phones refuse, so every check had passed; it surfaced only when we watched the app on a test phone.
What we changed
We took out the repeated work and gave the app a map of itself to travel with on every update.
- A burst of new messages is now gathered into one load, a second and a half after the last one arrives.
- Identical requests share one answer, and when something has changed in the meantime, the newer answer is the one shown.
- Long lists draw only the rows on screen and add the rest as the person scrolls.
- Start-up reading and unlocking moved off the part that draws, a draft is saved once typing pauses for 400 milliseconds, and dates and figures are formatted with tools made once rather than on every row.
- Each language's words are prepared only when that language is used.
- The baseline profile travels inside every update, so Google Play prepares the main screens when it installs one. When we rearranged screens the next day, we recorded it again, because a map that no longer matches the app helps nobody.
- The demo's text was rewritten, and one of our checks now fails on any wording Android would refuse, so that gap cannot reopen quietly.
Where it stands, and what we are not claiming
The changes are in our next Android version and reach people once that version is live on Google Play. On our test phone the app loads less, scrolls lists as it goes, starts without the screen waiting on stored files, and the demo opens again. We took no before-and-after timing on a real phone, so we are not claiming seconds saved. What we can say is that the app no longer asks the phone to learn it from scratch after every release, and no longer loads the same screens several times over.
What you can check yourself
- Ask whoever builds your Android app whether it ships with a baseline profile, and whether that recording is refreshed when the screens change. If the term draws a blank, that is your answer.
- Use the app straight after an update, then again a day later, and compare. A difference in feel points at the relearning half of the problem.
- Scroll the longest list in your app quickly. Rows that arrive late, jump or appear blank as you go are the sign we met.
- Open the app and watch the first screen for a few seconds: if it sits empty while the app settles, work is being done while the screen is trying to draw.
- Ask to see the app run on a real Android phone before a release, not only the checks that run on a computer.
What to do next
Put the pattern in writing for whoever builds your app: which screen, whether it was straight after an update, and whether it settled later. Agree what better would look like before the next release — the first screen showing content, the long list scrolling without blank rows — and ask them to show you those moments on a handset. Reading an app while it is in use, on our own product and for clients who run one, is the kind of work our engineers do.
Questions people ask
Why does my Android app feel slower right after an update?
Android learns an app's code over days of use, not in one go. The app is at its slowest in that stretch and settles as the phone sees which parts are used; if another update arrives before it settles, the stretch starts again. There is no single figure that fits every phone and every app.
What should I give a developer who has never heard of a baseline profile?
Give them the pattern you see, not the term alone: the app is slowest just after updates and settles later, and the long list stutters. Ask them to check whether the app ships with a baseline profile and, if it does not, whether adding one suits this app. Ask too that the recording be refreshed whenever the main screens change, since an old profile stops matching the app.
Can slow lists and repeated loading be fixed without rebuilding the app?
In our case the changes were to how the app itself behaves, and they reach people with the next version. Whether yours can be fixed the same way depends on what is actually causing it. The place to start is watching the app on a real phone rather than guessing from complaints.
How can I tell whether my app is slow on real phones if every check passes?
Checks that run on a computer do not reproduce what a phone accepts when the app is running. In our app, three pieces of text passed every check and crashed the demo on a real phone. Watching the app on a handset before each release finds what other checks miss.
Will people feel a difference, and when?
The changes are in the next Android version and reach people once it is live on Google Play. On our test phone the app loads less and scrolls lists as it goes. We took no before-and-after timing on a real phone, so we make no claim about how much faster it feels.