Native Android apps tested on the devices your users own
Android is where a large share of Australian field workers, tradespeople and value conscious consumers actually are. Building for it well is less about writing Kotlin and more about respecting how varied the devices are.
What is android apps?
Android App Development is building applications natively for Android devices using Kotlin and Jetpack Compose, then distributing them through Google Play or an enterprise channel. It suits Australian organisations whose audience or field workforce is predominantly on Android, and whose app must work reliably across a wide range of device makes, screen sizes and operating system versions.
Get a fixed written quote- Typical timeline
- 12 to 22 weeks
- What drives cost
- Screen and role count, whether a backend already exists, hardware features involved, offline requirements.
- Best for
- Field workforces, broad consumer audiences and rugged or shared devices
- You own
- The Kotlin codebase, the Play Console account and the signing keys
- Built with
- Kotlin, Jetpack Compose, WorkManager, Play Console release tracks
Your handover
Fragmentation is a testing problem before it is a coding problem
The cliche is that Android app development is hard because there are thousands of device models. The reality is more manageable and more specific. Modern Android development handles most variation through standard components and adaptive layouts. What actually catches teams out is a narrow set of real differences: manufacturer customisations to battery and background behaviour, wildly different screen aspect ratios, low memory budget devices, older operating system versions still in service, and vendors who change how notifications behave.
- 01Kotlin and Jetpack Compose codebase in your repository
- 02Play Console account enrolled under your business
- 03Play App Signing configured with keys you control
- 04Automated build and upload pipeline
- 05Android App Bundle with device targeted delivery
- 06Data safety declarations and permission justifications
- Real device test matrix covering your users' actual handsets
- Crash reporting and Android vitals monitoring
- Staged rollout plan and release runbook
More on fragmentation is a testing problem before it is a coding problem
So we approach it as a device strategy rather than a coding style. We look at your analytics to see what your users genuinely carry, which for an Australian trade workforce often means a mix of mid range handsets and a few rugged units rather than the flagship the office runs. We then test on real hardware at the low end of that range instead of only on emulators, because memory pressure, slower storage and aggressive battery management only show up on the actual device. A layout that works on a tall narrow screen and a folding one is a design decision made early, not a rescue effort at the end.
A layout that works on a tall narrow screen and a folding one is a design decision made early, not a rescue effort at the end.
Play Store policy and the deadline that catches teams out
Google Play review is largely automated and quick, which makes publishing pleasant and makes policy enforcement the real risk. A live app can be suspended for a policy breach with limited notice, and appeals are slow, so compliance is worth treating as an engineering requirement rather than a legal formality.
The recurring issues are consistent
The recurring issues are consistent. Google raises the minimum target API level every year, and once the deadline passes you cannot submit updates until you comply, which means an app nobody has touched for two years is effectively frozen. The Data safety section must accurately describe what your app and its libraries collect, and it must match your privacy policy. Permissions considered sensitive, particularly background location, precise location, all files access and SMS, require a declared justification and are frequently refused. Apps that let users create accounts must offer account deletion, including a route accessible from outside the app. Financial, health and government related categories carry extra requirements. We build all of this into the project rather than discovering it during submission.
- Target API level tracked against Google's annual deadline
- Data safety declarations reconciled against every dependency
- Sensitive permission justifications prepared before submission
- In app and web based account deletion where accounts exist
- Signing handled through Play App Signing so a lost key is not fatal
How the engagement runs
Release tracks, staged rollout and Play Console
Play Console gives you a genuinely good release pipeline if you use it properly, and most teams use about a third of it. Getting this set up before the first release is worth more than any single feature, because it converts a launch from an event into a repeatable process.
- 01Stage 1Enrol the Play Console developer account under your business with your ABN and your own billing details
- 02Stage 2Enable Play App Signing so Google holds the upload and app signing keys securely
- 03Stage 3Configure internal testing for your team, then closed testing with a pilot group of real users
- 04Stage 4Automate build and upload so a release is a pipeline run rather than a manual export
- 05Stage 5Publish Android App Bundles so each device downloads only the code and resources it needs
- 06Stage 6Use open testing or a staged rollout starting at a small percentage, watching crash rate and vitals
- 07Stage 7Increase the rollout as the numbers hold, and halt it immediately if Android vitals degrade
Two decisions on your side that keep the project moving
The other advantage of Android is speed. Review is usually a matter of hours to a couple of days, so a fix can reach users the same week rather than waiting in a queue. That only helps if the pipeline is automated and the rollout is staged, so problems are caught while exposure is still small.
Background work, battery and why notifications stop arriving
The most common complaint about Android business apps is that the notification arrived four hours late, or the sync did not run overnight. This is almost never a bug in the app. It is Android's battery management doing exactly what it was designed to do, made less predictable by manufacturers who add their own aggressive power saving on top of the platform behaviour.
Building around it is deliberate work
Building around it is deliberate work. Scheduled and deferrable jobs go through WorkManager so the system can batch them sensibly and they survive a reboot. Genuinely time critical delivery uses high priority messaging rather than a background poll that will be throttled. Foreground services are used only where the work is user visible and justified, since both the platform and Play policy restrict them. Where a device manufacturer applies extra restrictions, we detect it and guide the user through the settings change with clear instructions rather than leaving them to conclude the app is broken. For field teams this is the difference between a system operators trust and one they check manually anyway, which defeats the purpose. Transport and logistics operators feel this most acutely, since a late job notification has an immediate operational cost.
Distributing outside the Play Store for field teams
Not every Android app belongs in a public store. If the users are your own staff, distribution through managed channels is often the better arrangement. Managed Google Play with a mobile device management platform lets you push the app to company devices, apply configuration remotely, force updates and lock devices into a single application for a kiosk or a delivery run.
More on distributing outside the Play Store for field teams
This suits Australian operators running shared devices across shifts, warehouses with mounted terminals, or field crews who should not be installing anything else on a company handset. It also removes the public listing requirements, which simplifies compliance considerably. The trade off is that you take on device management, enrolment and the support burden that comes with it, so it earns its place at a certain fleet size rather than for a handful of phones. We scope the distribution model as part of Android app development, because it changes both the build configuration and the update strategy. Where the app is one part of a wider operational system, it usually connects back to the same platform covered in custom software development rather than standing alone.
When Android should not be your first build
If your users are predominantly on iPhone, and for some Australian consumer segments they clearly are, funding Android app development first is spending in the wrong place. Check your website analytics for the actual device split among your visitors before deciding, since national averages are a poor substitute for your own data. Where the split is close to even, building both from a single cross platform codebase is usually the better economic answer than two native teams.
Wanting a presence in the store is not one
It is also the wrong call when the app itself is unnecessary. If people would open it a few times a year, they will uninstall it during the next storage cleanup. Content, simple bookings and account access work perfectly well on the mobile web, and a progressive web app can be added to the home screen with offline support and working notifications on Android without any store involvement. Build native Android when you need reliable background behaviour, hardware access such as barcode scanning or NFC, offline operation in areas with poor coverage, or managed distribution to a device fleet. Those are real reasons. Wanting a presence in the store is not one.
How we scope it
Four ways to scope your Android Apps project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Discovery build
A scoped build with the architecture settled first
Fixed written quote, agreed before work starts
- Kotlin and Jetpack Compose codebase in your repository
- Play Console account enrolled under your business
- Play App Signing configured with keys you control
Product build
A working product your customers or staff use daily
Fixed written quote, agreed before work starts
- Everything in Discovery build
- Automated build and upload pipeline
- Android App Bundle with device targeted delivery
- Data safety declarations and permission justifications
Platform build
A platform with SSO, audit trails and a security review
Fixed written quote, agreed before work starts
- Everything in Product build
- Real device test matrix covering your users' actual handsets
- Crash reporting and Android vitals monitoring
- Staged rollout plan and release runbook
Product care
A named engineer, a roadmap and real service levels
Rolling monthly, quoted in writing
- A named engineer rather than a ticket queue
- A roadmap you set, worked through each month
- Dependency patching, monitoring and incident response
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does an Android app take to build?
Usually 12 to 22 weeks from kickoff to a public release. Development takes most of it, with a few weeks for testing across a real device matrix and preparing the store listing. Play review itself is generally fast, often within a day. What extends projects is offline behaviour, hardware integration such as scanning or printing, and backend work that has to be built in parallel.
What affects the cost of an Android app?
Screen and role count, whether a backend already exists, hardware features involved, offline requirements, and how wide a device range you need to support properly. Testing across many real devices is a genuine line item that emulator only projects skip and then pay for after launch. We scope it in discovery and issue a fixed written quote. Google charges a one-off developer registration fee, paid by you.
Who owns the app, the listing and the signing keys?
You do. The Play Console account is registered to your business with your ABN and billing, so the listing, reviews and install base stay with your organisation. Play App Signing keeps the app signing key held securely by Google under your account, which also means a departing developer cannot strand you. The codebase is in your repository and our access is revocable.
How many Android versions and devices will you support?
We pick the floor from your own analytics rather than a generic recommendation, and it usually lands at covering roughly the last five or six major Android versions, which captures the large majority of active devices. We then agree a test matrix of specific real handsets that reflect what your users carry, including at least one low end device, and test every release against it rather than only on current flagships.
Can the app scan barcodes, print labels or work with rugged hardware?
Yes, and this is a common reason Australian operations choose Android in the first place. We work with camera based scanning, dedicated scanner hardware, Bluetooth label printers and NFC. The important step is confirming the exact hardware models early, because vendor software development kits vary in quality and one or two require workarounds. We test against the real units rather than assuming the documentation is accurate.
What ongoing maintenance does an Android app need?
Plan for a yearly cycle at minimum. Google raises the minimum target API level annually and updates cannot be submitted once you fall behind, so an unmaintained app becomes frozen. Beyond that there are dependency updates, testing against each new Android release, policy changes affecting permissions or data disclosures, and monitoring Android vitals since poor numbers reduce your visibility in the store.
Related services
Scope an Android build around the devices your users carry
Tell us who uses the app, where they use it and what hardware is involved. We answer the next business day and the price we send is fixed and in writing.