Android app development
Android app development company for Kotlin and Jetpack Compose apps
We are an Android app development company in Lahore building native Kotlin apps with Jetpack Compose for clients in the USA, UK, UAE, Europe and Australia. We test on the cheap phones your users actually own, not just flagship devices, and release through Play Console testing tracks before anything reaches production. You own the code, the Play Console account and the signing keys.
- Native Kotlin and Jetpack Compose
- Targets Android 16 (API level 36)
- Real-device testing across price tiers
- Play Console release handled
What our Android app development company builds
Native Android apps are written in Kotlin, the platform’s preferred language, with interfaces built in Jetpack Compose, Google’s recommended modern UI toolkit. Compose replaces XML layouts with Kotlin code, which makes screens easier to test and change. For older apps we work inside the existing View system and migrate screen by screen, rather than freezing features for a rewrite; our Android app upgrade services cover target API and Java-to-Kotlin moves.
Typical projects include consumer and marketplace apps, fintech and wallet apps, logistics and field-service tools, and companion apps for Bluetooth hardware. If you need the same app on iPhone at the same time, look at cross-platform app development first: one codebase may cover both for less, and we will tell you whether it fits.
Each engagement includes a dedicated project manager, two-week sprints with a working build in Play Console internal testing, QA on real devices, and production release. Code sits in your own repository from the first commit.
Why Android-first makes sense for global and emerging markets
Platform share depends on geography. StatCounter’s September 2026 data puts Android at 69.2% of mobile OS share worldwide, against 30.8% for iOS. In the US the split is close to even, with iOS slightly ahead at 53.6%, but in most markets outside the US, Android is where the majority of your users are likely to be.
That makes Android the logical first platform for marketplaces, ride and delivery apps, mobile wallets, and any product aimed at a broad audience outside the US. It also changes how you build: more low-memory devices, patchier networks and users who uninstall apps that take too much storage or data.
If your first customers are US consumers paying through subscriptions, iOS app development may still come first. Starting with one platform also keeps a first release lean, which is how our MVP app development projects usually begin.
Android-first usually fits when
- Your users are global or in emerging markets
- You need low-cost devices to work well
- Your app relies on background work, NFC or Bluetooth
- You plan Wear OS, Android TV or Android Automotive later
- Distribution to company-owned devices matters
Our device fragmentation testing strategy
Android runs on a huge range of device models from many manufacturers, each with its own screen sizes, OS versions and battery-saving behaviour. Testing everything is impossible, so our mobile app testing is deliberate.
| Layer | What we test | Why it matters |
|---|---|---|
| Price tiers | A low-end phone with limited RAM, a mid-range phone and a current flagship | Low-memory devices expose leaks, slow startup and janky lists that flagships hide |
| Manufacturer skins | Samsung, Xiaomi and other OEM builds common in your target markets | Aggressive battery managers can kill background work and delay notifications |
| OS versions | Your minimum supported version up to Android 16 | Permission models, notification rules and background limits change between versions |
| Screen classes | Small phones, large phones, foldables and tablets | Compose adaptive layouts must hold up when the window size changes; see Android tablet app development |
| Conditions | Slow and flaky networks, low storage, denied permissions, process death | Users hit these daily; emulators rarely reproduce them |
We agree the device matrix with you during discovery, based on your analytics or your target markets. A cloud device farm covers wider sweeps (Firebase Test Lab is deprecated and shuts down on 30 September 2027, so we use alternatives); physical devices cover what matters most.
Google Play rules: target API 36 and Play Console testing tracks
Google raises the minimum target API level every year. From August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher, with an extension available to November 1, 2026. Wear OS and Automotive apps must target API 35, and TV apps API 34. Existing apps must target API 35 or higher to stay visible to new users on newer devices.
Raising the target API level is rarely a one-line change. New behaviour around permissions, notifications, background work and edge-to-edge layouts can break screens that looked fine before. On Android 16, apps targeting API 36 can no longer lock orientation or resizability on screens 600dp wide or more (games are exempt), so phone-only layouts must adapt to tablets and foldables. For live apps we plan these upgrades under app maintenance and support, as backlog items with their own QA pass, ahead of Google’s deadline. Our guide to Google Play target API level requirements covers the extension form and what happens to existing installs.
How we use Play Console testing tracks
- Internal testing: every sprint build goes here for your team, usually available within minutes.
- Closed testing: a named group of beta users or a client pilot, with feedback collected before wider release.
- Open testing: a public beta listing when you want broader feedback without a full launch.
- Staged rollout: production releases go to a small percentage of users first, so a crash spike in Crashlytics can be stopped before it reaches everyone.
Your Play Console account costs a one-time $25 and is registered to your company; our guide on how to publish an app on Google Play walks through verification, testing and the Data safety form. Google Play’s fees depend on market, earnings tier, subscription vs one-off, and whether you use Google Play Billing. In the US, UK and EEA (since 30 June 2026; Australia and Japan since 30 September), the service fee starts at 10% on the first $1M of annual earnings and is 10% on auto-renewing subscriptions, plus a separate 5% billing fee only when Google Play Billing is used; other markets stay at 15% on the first $1M, 30% above and 15% on subscriptions until the change reaches them.
Need an Android app that works on budget phones too?
Tell us your target markets and core features. We will propose a device matrix, a release plan through Play Console testing tracks and the next step toward a fixed quote.
Android-specific features we build
These are areas where Android gives you more room than iOS, and where native Kotlin pays off.
Home screen widgets
Glanceable widgets built with Jetpack Glance, kept fresh without draining the battery. Useful for bookings, balances, delivery status and habit tracking.
Reliable background work
Uploads, sync and scheduled jobs with WorkManager, and foreground services only where the user expects them. We test against OEM battery managers that kill background processes.
Notifications and deep links
Firebase Cloud Messaging with notification channels, runtime permission prompts on newer Android versions, and App Links that open the right screen.
Hardware access
Camera with CameraX, NFC, Bluetooth Low Energy, barcode scanning and location, each with clear permission rationale for users and Play review.
Payments and billing
Google Play Billing (Library v8 or later is required for new apps and updates from 31 August 2026) for digital goods and subscriptions; payment gateways or Google Pay for physical goods and services.
Wear OS, Android TV and Automotive
Companion experiences for Wear OS app development, Android TV apps and cars share code with the phone app. These are separate builds with their own target API rules, scoped as their own phases.
Performance and battery: where Android apps win or lose users
Users judge an Android app in its first few seconds. Slow cold starts, stuttering lists and a big download size lead to uninstalls, especially on entry-level phones. We treat performance as an acceptance criterion, not a polish task at the end.
In practice that means Baseline Profiles to speed up startup, R8 to shrink and optimise code, Android App Bundles so users only download what their device needs, and Compose recomposition checks so screens do not redraw more than they must. Android Studio’s profilers and Android vitals in Play Console show where time and battery go.
Battery is the other silent killer. Polling a server every few minutes, holding location longer than needed or waking the device for non-urgent sync all show up in Android vitals and in reviews. We batch work, respect Doze and use push instead of polling wherever the product allows.
Our Android development process
It follows our standard delivery process, with Android-specific checkpoints.
Discovery and device matrix
Backlog with acceptance criteria, target markets, minimum Android version and the device matrix for testing. You create your Play Console account and invite us.
Material Design prototype
A clickable Figma prototype following Material Design conventions, built by our mobile app UI/UX design team and tested with users before any code.
Architecture and CI
Kotlin, Compose, coroutines and a clear modular structure, with Gradle builds in GitHub Actions or Codemagic producing signed bundles on every merge.
Sprints with internal testing builds
Two-week sprints, each ending with a working build in Play Console internal testing for you to install and review.
QA, security and performance
Real-device testing across the matrix, security checks against OWASP MASVS, and startup, memory and battery profiling.
Closed test, staged rollout, support
A closed test with a pilot group, then a staged production rollout with crash monitoring. Post-launch support keeps you compliant as Google’s target API rules move each year.
Hire Android developers or a full team
If you already run a product team, you may only need engineers. You can hire Android developers on a dedicated or staff-augmentation basis, with a two-week trial. For a sense of budget before any calls, read our app development cost comparison for Pakistan, the USA, UK and UAE.
Android apps we have shipped
[[Case study: Android app name, industry and market, problem, what we built, measurable result. Confirm before publishing.]]
[[Client testimonial with name, role and company, used with written permission.]]
Android app development: frequently asked questions
Do you build Android apps in Kotlin or Java?
New apps are built in Kotlin, which is Google’s preferred language for Android, with interfaces in Jetpack Compose. Kotlin is fully interoperable with Java, so we can extend and maintain existing Java apps without a rewrite. Where it makes sense, we migrate older Java and XML screens to Kotlin and Compose gradually, alongside normal feature work.
What is the Google Play target API level requirement in 2026?
From August 31, 2026, new apps and updates on Google Play must target Android 16 (API level 36) or higher, with an extension available to November 1, 2026. Wear OS and Automotive apps must target API 35 and TV apps API 34. Existing apps need to target at least API 35 to stay visible to new users on newer devices.
How do you handle Android device fragmentation?
We agree a device matrix during discovery based on your target markets or analytics. It covers low-end, mid-range and flagship phones, the manufacturer skins your users have, your minimum Android version up to Android 16, and tablets or foldables where relevant. Physical devices handle core testing; a cloud device farm adds wider coverage.
Should I launch on Android or iOS first?
Look at where your users are. StatCounter’s September 2026 figures show Android at 69.2% of mobile share worldwide, while iOS leads in the US at 53.6%. Global, emerging-market and broad-audience products usually start on Android. US-focused subscription products often start on iOS. If you need both at launch, consider a cross-platform build.
How do you release an Android app on Google Play?
Builds move through Play Console tracks: internal testing for every sprint build, closed testing with a named group of real users, then a staged production rollout to a small percentage of users first. We prepare the store listing, data safety form and content rating, and monitor crashes in Crashlytics and Android vitals during the rollout.
Can you build Wear OS or Android TV apps?
Yes, as companions to a phone app or standalone. Wear OS and Android TV apps have their own design patterns, input methods and Google Play target API rules, so we scope them as separate phases. Shared Kotlin code keeps business logic and data consistent across the phone, watch and TV versions.
Who owns the Play Console account and signing keys?
You do. You register your company’s Google Play Console account, a one-time $25 fee, and add us with limited permissions. The app, its reviews and its revenue stay in your account. We use Play App Signing and document the upload key process, so you never depend on us to publish an update.
Plan your Android app with people who test on real phones
Book a 30-minute scoping call. We will review your features, target markets and minimum Android version, and you will leave with a recommended scope and a device testing plan.