Native Android apps in Kotlin and Jetpack Compose

What we build

The app is Kotlin and Jetpack Compose. Phone screens come first. A tablet keeps a list beside the open record. Android widgets are separate home-screen layouts, including an offline state. Another language means strings in the project and room for a longer label.

The back gesture and the system bars belong in the layout. A notification or a share is in the scope, or it is omitted. A fix starts in the Android Studio project you already have. We name the crash, the stuck purchase, or the build that will not assemble before anyone proposes a new UI.

Jobs that have a shape

A first version names the main workflow and its empty, failed-request and denied-permission states. Additional platforms, offline synchronisation and widgets are listed separately. You review an installable build before submission; Google controls its review schedule.

• A tablet layout for a task the phone is too narrow for, such as two records side by side.
• Android widgets for one fact, such as the next booking, with an offline state.
• A purchase through Google Play: the product, a restore, a failed payment, and a lapsed subscription. A charge on your server is a separate API.
• One older screen moved onto Compose. The surrounding Java or XML UI stays.
• A deep link, a notification, or a camera or location permission, denial included.
• Listing text, screenshots, and the content-rating questions, when a Google Play launch is in the same quote.

From the first email to handoff

Send the job, the devices in version one, and any repository, designs, or API. A date we can plan around is a pilot, a season, or a submission window. A target date helps us assess availability.

Hourly fits a bug or a small job we can see. A fixed quote fits a named list of screens. A vague brief starts as paid discovery, and you keep the write-up if you stop.

Open the Google Play Console account in your company's name before the package name is chosen, and invite us. That name stays with the listing. Git stays in your repository. You install an internal testing build, walk the path, and break it once: no network, a denied permission, a failed card. We take a small number of projects at a time, so you work with the people doing the work. You leave with the repository, the release steps, and the account, and you can remove our access the same day.

The tools on the project

Daily tools are Android Studio, Kotlin, Jetpack Compose, and Git. The quote names the oldest Android version in scope and the devices we install on. A release comes from a documented step. If that build shrinks code, its mapping file is part of the handoff, so a later crash report can be read.

You supply the privacy policy. We write the permission strings and the Play Console answers about data the app collects. TalkBack labels, type that grows, and contrast you can read in sunlight are the WCAG work we implement. We do not certify conformance, and we do not give legal advice.

If iOS shares the release, say so in the first email. That scope is Swift and SwiftUI, or React Native or Flutter when one interface is shared. A widget, a device API, or an Android-only launch stays in Kotlin. Apps we have shipped ourselves are Swift, on the App Store.

Who should email

Email if you want an Android app developer or a Kotlin developer to build the app, extend it, or continue code someone else left. An agency can send that piece white-label or with credit. A team that already has iOS, or a developer in the Android repository, can hand us the tablet layout, the widgets, or the Google Play launch.

If the brief is still open, paid discovery can turn it into a defined feature list and acceptance checks. If you already have a developer or agency, we can take a bounded part of the work and agree how it joins the wider project. Share the target date so we can assess capacity and dependencies before committing.

What we can point to

Our published products are native Apple apps. They demonstrate product design, offline data, purchases and store-release work; they do not establish a Google Play portfolio. For an Android project, the reviewable evidence is the Kotlin or Compose implementation, test build and device checks agreed for your scope.

Send the first-version task, supported devices, designs or an API sample, purchase requirements and languages. We then identify the repository and Play Console access needed for investigation and release. Keep credentials out of the initial email.