App performance testing
App performance testing company for startup, smoothness and stability
Your app probably feels fine on your own phone. As an app performance testing company, we measure how your iOS and Android app behaves on the phones your users actually own: cold start time, dropped frames, memory growth, battery, network behaviour on weak connections and the crash and ANR rates Google Play uses to judge you. This page goes one step deeper than the performance section of our mobile app testing services. You get a baseline, a budget per metric and a test that fails the build when a release gets slower.
- Mid-range and older devices, not just flagships
- Lab tests plus field data from real users
- Android vitals thresholds tracked
- Performance budgets enforced in CI
Why an app performance testing company tests on slow phones
Most apps feel fine on the developer’s phone. That phone is new, on office Wi-Fi, with a warm cache and a fresh install. Your users have a three-year-old Android with 40 apps fighting for memory, a train tunnel and a 4G signal that drops to one bar. Performance problems live there. Android holds 69.2% of mobile OS share worldwide, according to StatCounter, across everything from flagships to budget phones.
We measure in two places. Lab testing runs repeatable scripts on chosen devices with controlled network conditions, so a change can be compared fairly against the last release. Field data comes from real users through Android vitals in Play Console, Xcode Organizer, MetricKit and your crash and performance SDK. Lab results tell you why. Field data tells you whether it matters.
Testing finds and quantifies the problems. If you also want them fixed, our app performance optimization service picks up the findings and works through them with before and after numbers.
What we measure and how
Each metric gets a tool, a test method and a budget agreed with you. The budget is what turns a measurement into a pass or fail.
| Metric | iOS tooling | Android tooling | Typical test |
|---|---|---|---|
| Startup time | Instruments App Launch template, XCTest launch metrics, Organizer launch data | Macrobenchmark, TTID and TTFD in Logcat, Android vitals | Cold start after force-stop and cache clear, repeated runs, median and slow tail reported |
| Smoothness (jank) | Instruments Animation Hitches, Organizer hang rate | FrameTimeline in Perfetto, JankStats, Macrobenchmark frame timing | Scripted scroll through long lists and key transitions |
| Memory | Instruments Allocations and Leaks, memory graph debugger | Android Studio Memory Profiler, LeakCanary in debug builds | Long session: open and close the same screens repeatedly and watch the trend |
| Responsiveness | Organizer hang rate, MetricKit hang diagnostics | ANR rate in Android vitals, StrictMode in debug | Heavy actions (search, sync, photo import) on low-end devices |
| Network | Network Link Conditioner, Instruments network template | Emulator network profiles, Network Inspector | Core flows on throttled 3G-like and high-latency profiles, plus offline and reconnect |
| Battery and background | Organizer battery and energy reports | Battery Historian, background work inspector | Idle drain and background sync over a set period |
| Backend under load | k6 or JMeter | k6 or JMeter | API endpoints the app calls, at expected peak and above |
We report medians and the slow tail (for example the slowest 10% of runs), because averages hide the users who are having the worst time.
Startup time: cold, warm and hot
Android’s own guidance separates three kinds of launch. A cold start creates the app process from nothing, a warm start reuses part of it and a hot start brings an existing activity back to the front. Google recommends optimising for cold start, because improving it usually improves the other two.
We measure two moments. Time to initial display (TTID) is when the first frame appears, which Android reports automatically. Time to full display (TTFD) is when the app is actually usable, which the app must report by calling reportFullyDrawn(). Many apps never call it, so their dashboards show a fast first frame of a spinner. We add the call where the real content lands, so the number means something.
On iOS we measure launch with Instruments and XCTest launch metrics in the lab, and compare with launch time in Xcode Organizer from the field. Typical causes of slow starts are SDKs initialising on the main thread, large synchronous reads from disk, and network calls the first screen waits for. Those findings go into the report in order of measured cost.
Android vitals thresholds that affect your store visibility
On Google Play, stability is not only a user experience issue. Google publishes bad-behaviour thresholds and applies them to a 28-day average. Going over one can reduce your app’s visibility on Google Play and add a warning to your store listing, according to Google’s Android vitals documentation.
That makes crash and ANR rates a release gate, not just a dashboard. We check them before each release against the previous version, and we look at the per-device breakdown. An app can be comfortably under the overall threshold while one popular phone model is well over it, and that model’s users are the ones leaving reviews.
ANRs (App Not Responding) are usually caused by work on the main thread: disk or database access, heavy JSON parsing, synchronous network calls or lock contention. They are also the most common performance finding we report on Android apps built elsewhere.
Bad-behaviour thresholds
- User-perceived crash rate: 1.09% overall
- Crash rate per phone model: 8%
- User-perceived ANR rate: 0.47% overall
- ANR rate per phone model: 8%
- Watches: 4% crashes, 5% ANRs
- Measured as a 28-day average
Not sure where your app is slow?
Share your store links and read access to Play Console or App Store Connect. Within one business day we reply with what the field data already shows and what we would test first.
Field data on iOS: MetricKit and Xcode Organizer
Apple gives you two sources of real-user performance data, and we use both.
Xcode Organizer shows anonymised data from users who share analytics: launch time, memory, hang rate, battery, disk writes and storage, compared against goals based on similar apps. It can also alert you when a metric regresses by 75% or more against the average of the previous four versions. That is a useful safety net, but it only tells you after users already have the slow build.
MetricKit runs inside your app. MXMetricManager delivers metric reports at most once per day per metric source, and on iOS 15 and later diagnostic reports for hangs, crashes and disk-write exceptions arrive immediately. We wire MetricKit payloads into your analytics or backend so you can slice performance by app version, device and OS, which Organizer alone cannot do.
On Android the equivalent is Android vitals plus your performance SDK, such as Firebase Performance Monitoring or Sentry. We set up the same slicing there so iOS and Android numbers sit side by side.
How a performance test engagement runs
Whether it is a one-off audit or ongoing testing per release, the shape is the same.
Read the field data
Android vitals, Xcode Organizer, crash and performance SDKs. This shows which metrics and devices are already hurting real users before we write a single test.
Pick devices and network profiles
A low-end and mid-range Android, an older supported iPhone and a current flagship as a control, chosen from your analytics. Network profiles cover good Wi-Fi, weak mobile data and offline.
Script the critical flows
Cold start, login, the main list or feed, search, checkout and any heavy action, scripted so they run identically each time.
Set the baseline and budgets
Run each flow repeatedly, record medians and the slow tail, and agree a budget per metric with you, for example a maximum cold start on the reference low-end device.
Report findings with evidence
Each finding comes with traces, the measured cost and the likely cause, ranked by user impact.
Guard against regressions
Benchmark tests join your CI through our automated app testing setup, so a release that breaks a budget fails before it ships.
Performance problems we find most often
None of these are exotic. They show up in apps from every kind of team.
- Analytics, ads and crash SDKs all initialised on the main thread at launch
- Full-size images downloaded and decoded for thumbnails
- Lists that re-render every row when one item changes
- Ten API calls to draw a screen that needs one
- No caching, so every screen waits on the network
- Retained view controllers, fragments or listeners causing memory growth per screen
- Database queries and JSON parsing on the main thread, causing ANRs
- Retry loops with no backoff draining battery on weak connections
- Backend endpoints that are fine for 10 users and time out at launch-day traffic
Testing the backend with the app
Many performance problems that users blame on the app are really slow APIs. We load test the endpoints your app calls with k6 or JMeter at expected peak and beyond, using the request patterns the app actually makes rather than a generic script. That catches chatty screens, missing pagination and queries that degrade as data grows.
When we find server-side causes, we hand them to your backend team or to our mobile app backend development team. Cross-platform apps get the same treatment: Flutter and React Native have their own profiling tools, and we use them alongside the native ones. If you plan to keep performance under watch after launch, it fits into our mobile app maintenance services as a monthly health check. Teams that want this skill in-house can hire mobile QA engineers with performance profiling experience.
App performance testing: FAQs
What are Google Play’s Android vitals thresholds?
Google’s bad-behaviour thresholds are a user-perceived crash rate of 1.09% overall and 8% on any single phone model, and a user-perceived ANR rate of 0.47% overall and 8% per phone model. Watches have their own thresholds. Play uses a 28-day average, and going over a threshold can reduce your visibility on Google Play and add a warning to your store listing.
What is the difference between TTID and TTFD?
Time to initial display is when Android draws the app’s first frame, and it is reported automatically. Time to full display is when the app is actually usable, and the app must report it by calling reportFullyDrawn(). An app can have a fast TTID that only shows a spinner, so we measure both and treat TTFD as the number users feel.
Is emulator or simulator testing good enough for performance?
No. Simulators and emulators run on a powerful computer and hide memory pressure, thermal throttling and slow storage. They are fine for checking functional behaviour and some network scenarios. Performance numbers that matter come from real devices, ideally the low-end and mid-range models that make up a large share of your users, measured repeatedly.
What is MetricKit and should our iOS app use it?
MetricKit is Apple’s framework for collecting performance and diagnostic data from real users inside your app. Metric reports arrive at most once per day per source, and on iOS 15 and later diagnostic reports for hangs and crashes arrive immediately. It is worth adding to almost any production app, because it lets you slice performance by version and device in your own tools.
How do we stop performance getting worse over time?
Set a budget for each key metric on a reference device, run benchmark tests in CI and fail the build when a budget is broken. Then compare field data from Android vitals and Xcode Organizer after every release. Organizer can also alert you to regressions of 75% or more. Without a budget and a check, apps slow down one small change at a time.
Do you fix the problems you find?
We can. A performance test produces ranked findings with traces and likely causes. Your own team can fix them, or our app performance optimization service takes them on, with before and after measurements on the same devices so you can see what each fix delivered. Server-side causes go to your backend team or ours.
Know your numbers before your users do
Book a 30-minute call. We will look at your field data together and agree the devices, flows and budgets for a first performance baseline.