The bug that only shows up on one Android build rarely shows up in an emulator

Mobile Testing

An emulator runs the app faithfully and still cannot reproduce what a specific chipset, a low-battery throttling mode, or a patchy train-tunnel connection does to it. Those are physical conditions, not just software states. This practice tests on real devices across the fragmentation that actually matters to your users, not the two phones sitting on a developer's desk.

Talk to UsScope the Work
AI augmented, human governedEvidence before estimatesYour IP from day oneOne accountable owner per engagementFounded in 2011. Part of the Vinove Group500+ full-time engineers, as of September 2026NASSCOM member
Watch · the 90-second brief

Why a device matrix gets built from real usage data

Fragmentation, interrupted connectivity and the submission checks a build needs before it ships.

90 secWatch without filling in a form.
A mobile device and OS testing matrix in progress.90 secSample frame · video pending

01Before building the matrix

Real devices or emulators is not really an either-or

Most engagements need both, and the balance shifts with what a given test is actually trying to prove. Four questions settle where the weight should sit.

Is the suspected bug hardware-dependent?

Battery throttling, camera behaviour and chipset-specific rendering only show up on real hardware, never inside a simulator.

How wide is your actual device spread?

A tightly controlled enterprise fleet tolerates more emulator testing than a consumer app running across hundreds of device models.

How fast do you need the feedback loop?

Emulators run faster in CI for quick functional checks, while real-device testing suits the deeper pass before a release.

Is app-store submission the immediate goal?

Submission review increasingly expects real-device evidence for permissions, camera and location behaviour, not just simulator screenshots.

Real devices against emulators and simulators
Real devicesEmulators/simulators
SpeedSlower, physical setupFast, easy to parallelise
CatchesHardware and OS-specific bugsLogic and layout bugs cheaply
CostHigher per test cycleLow, scales in CI
Best fitPre-submission and field-bug diagnosisEveryday development feedback

02Agreed before the matrix runs

The ledger that keeps device coverage honest

Mobile testing goes wrong when 'it works on my phone' gets treated as evidence about every phone your users actually carry. This ledger sets out what you bring, what we test, what comes back, and what stays yours to decide.

  1. Your side

    You bring

    • The app build and its target device and OS support range
    • Any app-store guidelines the submission needs to satisfy
    • Known problem devices or OS versions from prior releases
  2. Our side

    We build

    • A device and OS matrix scoped to your actual user base
    • Gesture, orientation and offline-behaviour testing across that matrix
    • App-store submission checks against current platform guidelines
  3. Your side

    You receive

    • A pass/fail report across every device and OS combination tested
    • A defect list tied to the specific device or OS it appeared on
    • A submission-readiness check against current app-store requirements

Never leaves you

  • The app build and the decision to submit it
  • The developer account and the submission itself
  • The call on which device-specific defects block release

Where the line sitsWe test the matrix; you decide what ships and when. A defect tied to one specific device is a very different risk than one on every device.

03From matrix to submission-ready build

Four stages, each closing on a real result

A field bug that surprises everyone usually traces back to one of these stages never happening in the first place. This system closes each stage against a real device, not an assumption.

  1. Build the device and OS matrix

    The matrix gets scoped from your actual analytics on device and OS distribution, not a generic list of currently popular phones.

    A matrix built from real usage, not guesswork

  2. Test the conditions a demo skips

    Rotation, multitasking, incoming calls and a connection that drops mid-transaction get tested deliberately, because these interruptions are routine for a real user.

    Gestures, orientation and mid-use interruptions

  3. Log defects against the specific device

    Each defect records the exact device, OS version and condition it appeared under, so engineering can reproduce it without a guessing game.

    A defect tied to the exact condition

  4. Verify against submission requirements

    Current app-store guidelines get checked against the build directly, catching a rejection reason before a submission review finds it instead.

    Ready for the store, not just the build

04What actually moves the number

Four drivers, sized from the device spread

Mobile testing is scoped against your actual device and platform spread, because these four factors change effort far more than app size alone.

Driver 01

Size of the device and OS matrix

A narrow matrix covering a handful of common devices costs less than broad coverage across many manufacturers and OS versions.

Driver 02

Depth of offline and interruption testing

Basic connectivity checks cost less than a thorough pass through every interruption scenario a mobile user actually encounters.

Driver 03

Whether this is one submission or ongoing coverage

A single pre-submission pass costs less overall than a recurring matrix refreshed ahead of every future release.

Driver 04

Platform coverage required

Testing one platform costs less than covering iOS and Android in parallel, since each carries its own fragmentation and submission rules.

05Evidence and proof

Fragmentation caught on the hardware users actually carry.

Mobile testing proof here is a bug isolated on the exact device that produced it. These records carry that bar while written approvals are secured.

Explore case studies
A real-device test isolating a camera-permission bug an emulator missed.
Pillar Learning · EdTech platform, US

A submission blocked by one camera-permission bug only a real device caught.

Pillar Learning's app passed every emulator test and still hit an app-store rejection. Testing on the actual affected phone model isolated a camera-permission bug within a day.

Emulator test result
Passed
Time to isolate on real hardware
1 day
Sample · pending client approval
A mobile device matrix rebuilt from real usage analytics.
Tern · Logistics SaaS, EU

A device matrix rebuilt from actual usage data cut field bugs sharply.

Tern's driver app kept failing on specific Android builds nobody had tested against. A matrix rebuilt from real device analytics closed the gap before the next release.

Device coverage matched to real usage
Rebuilt fully
Field-reported bugs next release
Down sharply
Sample · pending client approval
Portrait of a VP of product reviewing a mobile device test matrix.

Every crash report named a phone we didn't own. Testing on the actual devices our patients use changed that completely.

Anika RaoVP Product, Koru Health
Sample · pending client approval

06Read this first

When a full device matrix is overkill

Running a broad public device matrix against an app three internal staff use on managed phones spends budget on a risk that never existed. The exits are marked plainly.

  • The app runs on a small, managed device fleet

    A tightly controlled fleet of identical, managed devices needs a much smaller matrix than a public consumer release.

  • The real gap is the API or backend behind the app

    When failures trace back to the service the app calls rather than the app itself, API testing is the more direct fix.

    API Testing

  • You need broader release confidence, not just the mobile layer

    When the goal spans a whole release across web and mobile together, software testing owns that broader scope instead.

    Software Testing
Engagement shapes for mobile testing work
ShapeBest whenYou directWe carry
Pre-submission passA release is close to app-store submissionRelease date and submission scopeMatrix testing and submission checks
Bug diagnosisA field bug will not reproduce in-houseSupport response and user communicationReproduction, isolation and a verified fix
Ongoing coverageReleases ship on a regular mobile cadenceRelease cadence and platform prioritiesA refreshed matrix and recurring pass

07Straight answers

Asked before a mobile release ships.

Not answered here?

Ask us directly Or scope the work first
What's included in a mobile app testing engagement?

Mobile app testing covers device and OS fragmentation across a defined matrix, gesture and orientation behaviour, offline and interrupted-connectivity handling, and app-store submission checks. Real hardware gets used for the failures a simulator cannot reproduce.

Do you test on real devices or emulators?

Both, chosen by what the test needs to prove. Emulators suit fast, everyday development checks, while real devices catch hardware and OS-specific bugs a simulator physically cannot.

Do you test both iOS and Android?

Yes, each platform carries its own fragmentation pattern and submission rules, so coverage gets scoped separately even within the same engagement.

Can you diagnose a bug that only happens on users' devices in the field?

Yes, this is a common starting point. Reproduction attempts target the specific device and OS combinations implicated by crash reports or user descriptions.

Do you check app-store submission requirements?

Yes, current platform guidelines get checked against the build directly, catching a likely rejection reason before a submission review finds it instead.

What does mobile testing cost?

Cost scales with the size of the device and OS matrix and how deep the offline and interruption testing needs to go. A narrow matrix costs far less than broad coverage.

How do you decide which devices belong in the test matrix?

The matrix gets built from your actual usage analytics wherever they exist, rather than a generic list of currently popular phones.

Can this run as an ongoing check ahead of every release?

Yes, a recurring pass ahead of each submission keeps the matrix current as new devices and OS versions ship into the market.