Android applications in Kotlin, built for the phones people actually own
Android is not one device, it is thousands. Screen sizes, manufacturer software layers, aggressive battery management, wildly different processor speeds and an enormous population of older handsets that still work perfectly well. An Android application that only behaves on a new flagship is not finished.
Building for the real Android population
The most common mistake in Android development is testing on two recent devices and assuming the job is done. Real users arrive with handsets several years old, with limited storage, modest memory and manufacturer software that terminates background processes far more aggressively than the platform documentation suggests. If your application misbehaves there, a substantial share of your audience will simply uninstall it.
We build in Kotlin using the modern Android toolkit, and we set the minimum supported version deliberately based on who your users actually are rather than on what is convenient for development. We test on older hardware, we watch memory and battery behaviour, and we treat a slow device as a design requirement rather than an unfortunate edge case.
Layouts are built to adapt across the full range of screen sizes and densities, including tablets where relevant, and we handle the awkward realities such as the on screen keyboard covering the field somebody is typing into, rotation losing state, and users who have set a large system font because they need it.
Connectivity, offline behaviour and syncing
Mobile connections are unreliable in exactly the places business applications are used, such as basements, warehouses, rural sites and moving vehicles. We design the connection behaviour rather than assuming it. Requests retry sensibly. Work in progress is preserved. Where the task requires it, records are stored locally and synchronised when the connection returns, with clear handling of what happens if the same record changed on the server in the meantime.
Data use matters too, particularly for users on limited plans. We keep payloads small, avoid downloading images at sizes nobody will see, and schedule large transfers for moments when the device is on an unmetered connection where the platform allows it.
Push notifications that arrive and are welcome
Notifications are frequently the main reason an application exists, and getting them right is more subtle than it looks. We use Firebase Cloud Messaging, handle the notification permission properly on newer Android versions, place messages into appropriate channels so users can control categories rather than turning everything off, and make sure tapping a notification takes somebody to the exact screen it referred to.
We also encourage restraint on the sending side. Applications that notify too often get muted, and a muted application is functionally uninstalled. Where a client controls what goes out, such as a school messaging parents, we build controls that make thoughtful sending easy and thoughtless sending harder.
Google Play, publishing and the years afterwards
Publishing involves the store listing, screenshots, categorisation, content rating, data safety declarations describing exactly what the application collects and why, and increasingly strict requirements around account deletion and permissions justification. We prepare all of it and handle correspondence when the review process raises a question.
Afterwards, Google raises the minimum target requirement every year, and applications that do not keep up eventually stop being available to new users. We keep published applications current, release through staged rollouts so a problem never reaches the whole user base at once, and monitor crash reporting so faults are found before the reviews start.
What we handle
- Native Kotlin application development
- Layouts across phone and tablet sizes
- Support for older, slower devices
- Offline storage and synchronisation
- Firebase Cloud Messaging notifications
- Secure login and token handling
- Camera, location and file access
- Google Play listing and data safety forms
- Staged rollouts and crash monitoring
- Annual compatibility updates
Built with
An Android application we built and still maintain
The QuranRecord Android application is written in Kotlin and published on Google Play. It gives teachers a way to record a student recitation in around five seconds, lets parents see progress and attendance, and delivers notifications from schools to families across many time zones.
It talks to the same Django REST Framework API as the website and the iOS application, which is why all three stay consistent. It has been through several Android version transitions, notification permission changes and store policy updates, each handled as routine maintenance rather than a crisis, which is what a properly maintained application looks like over time.
If you want to understand how we approach Android work, that application is the most direct answer available, because we designed it, built it, published it and still support the people who use it.
Read about the appsAndroid questions
Planning an Android application?
Tell us who will use it, how often, and what they will be doing while they use it. That shapes almost every technical decision that follows.