Android is easy to demo and hard to ship. A build that works flawlessly on a current Pixel can fail on a mid-range handset running a manufacturer skin two versions behind — which is what a large share of your users are holding.

What we bring

Our diagnostic apps run on over 200,000 devices, across a huge spread of manufacturers, chipsets and Android versions. At that range you stop trusting documentation and start trusting field reports.

What it teaches: OEM skins change documented behaviour without saying so; aggressive battery optimisation silently kills background work on several major brands; telephony and connectivity APIs return values that are incomplete or plainly wrong; and the devices in your analytics are nothing like the ones in your test drawer.

How we build

Kotlin, natively — if the app is your product rather than a companion to it, native is still where the quality ceiling is. Compose where it earns its place, Views where they remain the better answer. We will not rewrite a working app for architectural fashion.

Minimum SDK set from your actual user base, not from what is convenient to develop against.

Play Store submission

This is where projects stall. We handle listing setup, data safety declarations, permission justifications, staged rollout and the review cycle — and where an app needs a sensitive permission, we prepare the justification properly, because a rejection costs weeks.

We have also been through enforcement on our own catalogue, suspensions included. Not a pleasant credential, but it means we can read an enforcement notice and identify what actually triggered it. If your app is currently suspended or stuck in review, that is work we will take.

Typical projects

A new app through to a live listing; an existing app that needs modernising rather than rewriting; adding Android to a product that only exists on iOS or web; diagnostics and connectivity features, which are our home ground.

Testing on devices that matter

A test matrix built from your analytics, not from a shelf of flagships. In practice that means the mid-range Samsung, Xiaomi, Oppo and Vivo handsets most of your users actually hold, at the API levels they actually run.

Automated tests cover logic and regressions. But a large class of Android faults — permission dialogs that differ by OEM, background work killed by an aggressive battery manager, a keyboard that resizes the layout unexpectedly — only appear on real hardware. Those get checked by hand on devices, because emulators do not reproduce them.

Where a problem is device-specific and we cannot reproduce it, we say so plainly and instrument the app to collect what we need, rather than guessing at a fix and shipping it hopefully.

Performance and battery

Two complaints dominate one-star reviews: the app is slow to open, and the app drains the battery. Both are usually structural rather than incidental.

Cold start gets budgeted and measured. Work that does not have to happen before first paint is moved off the startup path. Background work uses WorkManager with constraints that respect Doze rather than fighting it — because on several major OEM builds, fighting it simply means the work never runs.

Network calls assume a bad connection, because a large share of real usage happens on one. Retries are bounded, failures are legible to the user, and nothing spins forever.

Accessibility and localisation

TalkBack navigation, touch targets that meet the minimum, contrast that survives a bright screen outdoors, and layouts that hold together at large font scales. Users change their font size far more often than developers expect.

Where an app ships in multiple languages, strings are externalised from the start and layouts are tested against the longest translation rather than the shortest. Retrofitting either of these is significantly more expensive than doing it once.

Maintenance after launch

Android does not stand still. Each yearly release brings behaviour changes, and Google Play enforces a rising minimum target API — meaning an app left untouched will eventually be delisted from search for new users.

We would rather stay on a maintenance arrangement than hand over and vanish: target API upgrades, policy changes, dependency and security updates, and crash triage against real reports. If you would prefer to take it in-house, we hand over cleanly — source, pipeline, signing arrangements and documentation good enough for another developer to continue.

What a project looks like

A short shaping conversation to establish what the app must do and what it does not. A range rather than a single number, widening with uncertainty. Working builds early and often, on real devices, rather than a reveal near the deadline.

You get the source, the build pipeline, the store listing configured properly, and an app that still works on the handsets your users own rather than only on the one in the demo.