What we build with it
Kotlin is where our Flutter apps meet Android properly. A cross-platform UI layer covers most of a product, but not all of it: background services that must survive the app being killed, foreground notifications, NFC and hardware access, vendor SDKs that ship Android-only, and install-referrer plumbing for deferred deep links.
That work is written in Kotlin behind a platform channel, with the Dart side seeing a clean API and none of the Android lifecycle detail.
Where we have shipped it
Native Android work sits inside our Flutter projects rather than beside them, so it does not appear as a separate portfolio entry. It shows up as the parts of an app that cross-platform code cannot reach — for example the deferred deep linking and install-referrer plumbing we have written about, which has no portable implementation.
When we recommend it
Kotlin is the right answer for the Android half of a platform integration, and for a fully native Android app when the product is genuinely platform-specific — deep OS integration, an Android-only audience, or a team already invested in the ecosystem.
It is the wrong answer as a default for a product that also needs iOS. Two native codebases means two teams, two release cycles and two sets of bugs; unless something forces it, Flutter with a Kotlin layer underneath gets you the same capability for far less.
