Hands setting a dark-screen phone down on a timber workbench beside a steel tray of screws and a folded yellow macro lens

Mobile App Quality

Keeping mobile releases reliable before launch

Most avoidable mobile defects aren't exotic. They're the sign-in that breaks when the session expires, the checkout that fails on one Android version, the screen that renders fine on the developer's phone and badly on a mid-range device. We structure testing and release checks so quality is a process, not a final sprint.

Ask about mobile testing See how we build apps

Studio in Canary Wharf, London · Working with UK product teams Monday to Friday

Brushed-steel workbench seen at an oblique angle with matte aluminium rails, a closed laptop sleeve, folded glasses and a steel tape measure

The build floor

What we do

Quality as a process, not a final sprint

On a phone, quality splits into things that are hard to see until they aren't. Correctness is the obvious part: the task completes, the data saves, the payment goes through.

Then there's performance on the devices your users actually carry, which is rarely the newest one. Then there's behaviour under bad conditions: patchy signal, an interrupted session, low storage. A release that handles the first and ignores the other two will generate support tickets within days. We plan the tests, then hold the line when the calendar gets tight.

Where testing lands

Four gates a release passes through

Automated Maestro UI tests

Automated UI testing with Maestro

We use Maestro to automate mobile UI tests, scripting the flows that matter most: sign-in, the core task, checkout, and the awkward edge cases people hit in real use. Maestro is a tool for automating mobile UI tests and appears in current tooling lists for app quality workflows, validating flows on mobile interfaces. Writing those scripts early means the test suite grows with the product instead of being assembled in a panic before release. A failing test becomes a fact, not an opinion.

Priority Which flows first

Which flows get automated first

Not everything deserves a script. We start with the paths where a failure costs the most and the paths that change most often. Authentication goes first, because everything sits behind it. Then the primary task the app exists to perform, then payment or submission if either applies, then the states that are easy to forget: empty lists, expired sessions, permission prompts. Lower-value screens get manual checks. Automating them first would be busywork with good optics.

Coverage Real devices

Testing on real devices, not just simulators

Simulators are fast and convenient, and they lie in predictable ways. Camera behaviour, push notifications, background processing, Bluetooth, and performance under thermal throttling all behave differently on hardware. We run the release candidate on real devices before a build ships, which is also where battery and memory problems show up. It's inconvenient and it's the difference between a confident release and a hopeful one.

Device coverage

A spread that represents your users

You cannot test every Android variant. The useful move is to pick a spread that catches the class of bug a single test device hides.

Device class Why it's tested Where it earns its place

Recent flagship Android and iOS Where it earns its place Current OS behaviours, new APIs, the wallet case Early signal on next-version regressions

Mid-range Android Where it earns its place What most UK users actually carry Layout, memory and thermal behaviour

Older model still in circulation Where it earns its place Low storage and old OS paths The class of bug a fresh phone hides

Current and previous major OS versions Where it earns its place API deprecations and permission changes Catches the update-week failures

A device your team does not own Where it earns its place The gap in the team's own coverage Where user reports start, and where a fleet stops agreeing with itself

Judgement, not repetition

Manual checks that stay manual

Automated tests are good at repetition and bad at judgement. Someone still needs to open the app, use it like a person, and notice that a layout is wrong or a message reads badly.

We keep a short manual pass on each release covering visual correctness, copy, and anything that needs a human eye on a real screen. It takes less time than people expect, and it catches things no script was written for.

Before a build goes out

Release readiness checks

Version numbers confirmed on the store listing and the build
Release notes written for a real reader, not a changelog dump
Environment configuration verified against production
Analytics and crash reporting wired and firing
Rollback path tested rather than assumed

The rollback matters most. A release that breaks something needs a way back that has actually been exercised, not a plan written on the assumption it will work. This list is deliberately short so people actually follow it.

Regression testing

Regression testing as the product grows

The first release is easy to test. The twelfth is where things get hard, because every feature added is a chance to break something already working.

Automated UI tests earn their keep here, since they run the same flows on every build without the cost of manual repetition. It is not a full safety net. It is a consistent one, and consistency beats sporadic thoroughness when release cadence picks up.

Common failure modes

Where testing goes wrong in practice

Testing left until the end

Schedule pressure makes testing negotiable, and it becomes the thing that gets cut first.
Only the team's own devices

Comfortable hardware hides the bugs your mid-range users find in the first week.
A passing suite as proof

Passing proves the scripted flows still work. It does not prove the app is good.

None of these are solved by buying more tools. They are solved by deciding, at the start, what "ready to ship" means and holding that line when the calendar gets tight.

What we ask of a client before release

Two things make a release smoother: a clear statement of what the app is supposed to do from the user's side, and access to a representative device or a description of what your users actually carry.

Without the first, we test everything equally and waste effort. Without the second, we're guessing at coverage. Both take minutes to provide and change the outcome.

After upload

Support once the app is live

Top-down view of a brushed-steel bench with a closed matte grey notebook, a steel carabiner and a paracord cord in an S-curve

Monitoring and fixes

Real users find real problems

Releasing is the start of the interesting part. We set up crash reporting and monitoring before launch so those problems are visible to someone, and we keep a defined support window after release for fixes.

If you take maintenance in-house, you get the test suite, the release process documentation, and a handover session. Either way, the point is that quality does not end when the build uploads.

Straight answers

Questions we hear on quality

Short answers to the three things product owners usually ask before we quote a scope.

Do you test on real devices or simulators?

Both. Simulators cover fast iteration; real devices catch camera, notification, performance and thermal behaviour that simulators misrepresent.

What does Maestro do that manual testing can't?

It repeats the same scripted flows on every build without fatigue. That consistency catches regressions that manual passes miss when release cadence picks up.

Can you take over testing for an app built elsewhere?

Often, yes. We start by reviewing the critical flows and the existing coverage, then decide whether to extend the current suite or rebuild it.

Ready when you are

Bring us a release that has to hold up

Send the app or the spec, tell us which flows matter most, and we will come back with a testing scope, a device spread and a release checklist fitted to your product.

Contact the studio See our work

BLUEHORIZON INNOVATIONS
1 Canada Square, London, England, E14 5AA
+44 20 7837 4011
[email protected]