Android development

Android development in Kotlin and Jetpack Compose

A good Android app feels fast and predictable on everything from budget phones to the latest flagships. We build native apps in Kotlin with Jetpack Compose and Material 3, using Coroutines for asynchronous work and Hilt for dependency injection. API clients are generated from OpenAPI, so the app and the backend speak the same language.

Many of the products we have worked on exist on both iOS and Android. That includes Trumf, where we contributed to a widget that takes customers straight to the QR code at checkout, and services such as re:member and NRK TV. We bring that experience of keeping the product consistent across platforms into our Android work.

Native Android or cross-platform — when we recommend which

Native Kotlin and Jetpack Compose is our starting point when the app is a core product: when performance on budget phones, accessibility, biometrics, widgets, or tight integration with notifications matters. Users get an app that behaves like the rest of their phone, and the team gets access to new Android APIs without waiting for an intermediate layer.

Cross-platform can be the right call when the app mostly shows content and forms, when the budget only covers one team, or when an existing web team will own the app. The cost is usually a little less platform feel and one more dependency to keep up to date.

Often the best answer is somewhere in between:

• Shared API contracts. The OpenAPI specification generates clients for both Android and iOS, so the apps agree on the data.
• Shared concepts, native interfaces. Components and naming are mirrored across platforms, while each app is built with its own tools.
• Shared logic where there is a lot of it. When the business logic is large and identical on both platforms, we consider Kotlin Multiplatform for that part, while the interface stays native.

Several brands from one codebase

We have worked on a white-label app where several brands share a single codebase. Each brand has its own colours, copy, and features, while fixes and new functionality benefit all of them at once. Parts of the interface are driven from the server through a component library shared between iOS and Android, so content and layout can change without a new app release. The result is less maintenance and faster delivery — without the brands losing their own identity.