Kotlin app builders in 2026

Google's documentation is unusually specific, which makes it easy to plan around:

"Google AI Studio lets you build native Android apps from a natural language prompt. Describe the app you want, and the Antigravity Agent generates a complete Kotlin and Jetpack Compose project."

What lands on disk:

"a standard Gradle-based project with the following structure: Build configuration: build.gradle.kts files (project and app level) using Kotlin DSL. UI layer: Jetpack Compose components with Material 3 theming. Architecture: single-activity architecture with ViewModels and data classes."

And there is a real exit: "To continue development in Android Studio, download the project as a ZIP file."

That is a genuine native Android project written to Google's own recommended patterns, from a prompt, with no local toolchain required to start. A year ago nothing like it existed.

These are quoted from Google's documentation rather than characterised, because the specifics matter more than the summary.

No server side. "Client-side only: Android apps don't include a server-side component." Anything needing a server runtime — Google names "secrets management, multiplayer, Firebase, Google Workspace APIs" — is "not available." If your app has accounts, that is a hard boundary.

Compose only. "Jetpack Compose only: apps use Kotlin and Jetpack Compose. Java and XML layouts are not supported." Fine for something new; a wall if you have existing XML layouts.

One module. "only single-activity, single-module projects are supported." Which is exactly the shape that stops working as an app grows, and it is not a shape you can grow out of gradually.

No native code. "C and C++ code is not supported."

Phones and tablets. "only phone and tablet form factors are supported." No Wear, no TV, no Auto.

The browser emulator has gaps. No camera or photo capture, no NFC, no Bluetooth, simulated GPS only, and no Google Play services. So the features people most often want on a phone are the ones you cannot test in the environment you are building in.

Distribution stops short of production. Publishing goes to "the internal testing track only. Production releases must be managed directly in the Google Play Console."

None of this makes it a bad product. It makes it a prototyping product with an honest export path, which is roughly what Google describes it as.

Google's Android documentation does not mention iOS. That is silence rather than a denial, and it would be unfair to characterise it as one — but silence is not something you can build a plan on either.

Google did separately preview a Migration Assistant in Android Studio at I/O in May, described as designed to "port apps from platforms like iOS, React Native, or web frameworks to native Android", mapping features and converting assets into Compose. Worth watching. It was announced on the Android Developers Blog rather than documented on developer.android.com, so as of today it is a preview rather than something to plan a product around.

Note the direction, too. The Migration Assistant moves work toward Android. It does not keep two platforms in step afterwards, which is the part that costs money for years rather than weeks.

Most tooling comparisons are about the first afternoon. The cost that actually accumulates is different.

Once an app exists on two platforms, the expensive thing is not writing either one. It is that they slowly stop agreeing. Someone fixes a validation rule on iOS. The Android version keeps the old one. A retry policy gets tightened on one side. An empty state behaves differently. None of it is dramatic and none of it shows up in a demo, and eighteen months later you are maintaining two applications that resemble each other.

The standard answers each trade something away. A cross-platform framework shares the logic by sharing the rendering engine, so neither interface is the platform's own. Writing both natively keeps both interfaces real and hands the drift problem straight back to you.

Duet takes a narrower position: share the logic, render natively, and make the agreement testable.

"Each feature's logic — its state, the actions that change it, the effects it requests — is written once. The iPhone app renders that state in SwiftUI; the Android app renders it in Jetpack Compose."

Nothing renders through a shared engine. Each app follows its own platform's conventions — Apple's Human Interface Guidelines on one side, Material 3 on the other.

The enforcement is the part worth understanding:

"Behavior is recorded as fixture files. Both platforms replay the same fixtures and the gate is byte equality."

The build fails when the platforms disagree. Parity is not a review discipline that erodes; it is a test that either passes or does not.

What that looks like in practice. Modaal's documentation describes an app called Memory Lane that was built on iOS first and later gained Android: sixteen Android product surfaces, 134 of 134 parity gates passing, and zero shared-logic files changed — no fixtures needed re-recording, because the Kotlin was written against fixtures the Swift had already produced. The standing ledger of deliberate divergences is six island entries and no manner waivers.

Android is in open beta, with general availability in September 2026. You can join the beta.

Two situations where the answer is plainly something else, and it is better to say so here than to have you find out after installing.

You want Android only. Modaal is a macOS app that builds through Xcode. It needs a Mac, Xcode 26 or newer and roughly 50 GB of disk. Requiring the Apple toolchain to ship an Android app is an absurd trade if you are never going to ship an iOS one. Use Google AI Studio, or Android Studio with Gemini's Agent Mode.

You already have an app you did not build in Modaal. Modaal cannot open an existing Xcode or Android Studio project. The Duet migration path runs from projects Modaal scaffolded itself — an iOS app built here can gain Android one feature at a time, but a codebase that came from somewhere else cannot be brought in. If you have a shipped app and need the second platform, this is not your tool. The honest options are a rewrite, Kotlin Multiplatform for the shared layer, or an agency.

Modaal is for the case where an app should exist on both platforms and you would rather the two versions be provably the same product than nominally the same product.