Android app development

Android is the larger platform and the harder one to test. Thousands of device and manufacturer combinations, aggressive battery management, and a store that enforces policy by automated review. Here is what that means for your build.

The hard parts of Android are not the language or the tooling. They are device fragmentation, manufacturer battery management that silently kills background work, and a Play Console policy surface that changes regularly and is enforced automatically.

What we build

Consumer apps that people open repeatedly. Our own portfolio ships on Android and carries a share of the ten million downloads behind it, which means our Android knowledge comes from operating apps at some scale rather than from a single client project.

The three things that actually make Android harder

Fragmentation is real, but not where people expect

The problem is rarely the Android version. It is screen aspect ratios, display cutouts, gesture navigation versus buttons, wildly varying memory, and manufacturer skins that change behaviour. An app that looks correct on a current flagship can be unusable on a three-year-old mid-range device that a large share of your users actually own.

The answer is not testing everything. It is choosing a small device matrix that covers the ways devices differ, and testing on real hardware rather than emulators, which are honest about layout and dishonest about performance.

Background work is not guaranteed

Android restricts background execution, and several manufacturers restrict it much further than Android itself does. Apps get suspended, alarms do not fire, and scheduled work quietly stops. If your product depends on something happening while the app is closed, that assumption needs designing around from the start rather than debugging afterwards.

Play Console policy is a moving target

• Data safety declarations must match what the app actually collects, and mismatches get caught.
• Sensitive permissions such as location, contacts and storage need a declared justification, and some need a review.
• Target API level requirements rise every year, and apps that fall behind stop being distributed to new users.
• Subscription and billing rules are enforced strictly, including how you present prices and trials.

Cross-platform, and when it is the wrong call

Most of our client work ships to both stores, and a shared codebase is usually the right economic answer: published estimates put the saving at up to forty percent against building twice. The saving comes from the product code. Notifications, purchases, permissions and store operations still have to be handled per platform, and those are where late problems live.

Native Android is the better choice when the app leans heavily on platform capabilities, needs deep background behaviour, or has performance requirements that a shared runtime makes awkward. That is a discovery decision, not a house style.

How we work

1. Discovery, including which devices your users actually hold. This changes the build more than most technical decisions.
2. Design, with the smallest supported screen considered from the start rather than adapted to at the end.
3. Build, with an installable build in your hands every week.
4. Testing on real hardware across a deliberately chosen device matrix.
5. Play Console setup, staged rollout, and iteration on live data.

Ship through a staged rollout, always. Android lets you release to a small percentage of users first, which means a crash introduced in a release reaches a fraction of your users rather than all of them. It costs nothing and it has saved more launches than any other single practice.

What you own

The source code, the design files, the keystore, and the Play Console listing, all from the start and all in your name. The signing key in particular matters: losing it means you cannot update your own app, so it belongs in your custody, backed up, from the first release.

Getting a real number

We scope before quoting: screens, what has to be stored, whether it syncs, which third parties are involved, what background behaviour is required, and what happens after launch. Then a fixed range before work starts. A quote given without those answers is a number chosen to win the work, not to describe it.