DEV Community: Avik Sharma Chowdhury

How I Built Free and Full Build Flavors for Android in My KMP Codebase

Avik Sharma Chowdhury — Fri, 02 Oct 2026 10:55:07 +0000

Part 3 of my KMP series: how Android product flavors let the free version of my app leave the sign-in, sync and payment code out of the build

In Part 1, I shared how my plan changed after completing the closed testing with MVP. I decided to launch the app for free and keep the paid features (sign-in, cloud sync and a premium subscription) ready for later. In Part 2, I walked through how the project is organized.

This part is about how one codebase builds both versions: a free app with only the core features, and a full app with everything. I’ll cover product flavors, how the free app leaves the premium features out, and how the shared code works with either version without knowing which one it’s in.

One note before we start: product flavors are an Android feature, and everything in this part is about the Android app. On iOS, I plan to release the full version, so the iOS code simply includes all the features.

Why Two Builds?

My first attempt was introducing a feature flag that hid the premium features. The free version still included the Auth and Payment SDKs and still asked for the billing permission, even though no one can buy anything.

I wanted the free app to contain only what it uses. That meant building two different apps from the same code.

Product Flavors

A product flavor is Android’s way of building different versions of an app from one codebase. You define flavors in Gradle, and each flavor can have its own code, resources and dependencies.

android {
    flavorDimensions.addAll(listOf("environment", "distribution"))

    productFlavors {
        create("dev") { dimension = "environment" }
        create("prod") { dimension = "environment" }

        create("free") { dimension = "distribution" }
        create("full") { dimension = "distribution" }
    }
}

The flavors are grouped into two dimensions:

environment (dev / prod): a development version and a release version. The dev build has a different app ID, so both can be installed on the same phone.
distribution (free / full): which features the app includes. The free flavor has only the core features, and full flavor includes sign-in, sync and payments.

Gradle combines them into variants such as prodFreeRelease, which is the app on Google Play, and devFullDebug, which I use to work on the premium features.

Leaving Auth and Payment Code Out

The sign-in and sync code lives in an auth module, and the payment code lives in a payment module. Both are added only to the full flavor:

dependencies {
    // Only the full build includes sign-in, sync and payments
    "fullImplementation"(project(":libs:auth"))
    "fullImplementation"(project(":libs:payment"))
}

fullImplementation means only include this in builds of the full flavor. The free app on Google Play doesn’t contain the sign-in, sync or payment code, or the SDKs behind them.

The billing permission works the same way. It’s declared in a small manifest file inside the androidFull folder, so only the full app asks for it.

The free build leaves the sign-in, sync and payment modules out entirely. The full build plugs them in behind the same interfaces.

Hiding the SDKs Behind Interfaces

The shared code never uses the auth or payment modules directly. It only uses interfaces. These interfaces live in a small module called domain-api. This module holds only interfaces and simple data classes, with no SDKs:

interface AuthRepository {
    val currentUserId: Flow<String?>
    suspend fun signIn(): Result<Unit>
    suspend fun logoutUser(): Result<Unit>
    // ...
}

The shared code depends on these interfaces. The auth and payment modules implement them with Supabase and RevenueCat. The free build has its own simple versions that do nothing.

Picking the Right Code at Startup

Something still has to decide which versions of the interfaces the app uses. This is where the flavor source sets come in. Each flavor has its own folder, androidFree and androidFull, and only one of them is compiled into a build.

In commonMain, there's a small interface for whatever cloud setup the build has:

interface CloudBootstrap {
    fun modules(): List<Module>
    fun onKoinStarted(koin: Koin) {}
}

Each flavor folder defines a value with the same name, cloudBootstrap. In androidFree, it loads freeCloudModule. This module has no-op (no operation) versions of the sign-in, sync and payment interfaces.

val cloudBootstrap: CloudBootstrap = object : CloudBootstrap {
    override fun modules(): List<Module> = listOf(freeCloudModule)
}

The free version doesn’t override onKoinStarted. The interface already gives it an empty default, so in the free build that call does nothing.

In androidFull, it loads the real modules and sets up payments once Koin has started:

val cloudBootstrap: CloudBootstrap = object : CloudBootstrap {
    override fun modules(): List<Module> =
        listOf(authCloudModule, paymentCloudModule, fullAndroidModule)

    override fun onKoinStarted(koin: Koin) {
        PaymentInitializer.initializeAndroid(koin.get())
    }
}

The app’s startup code in androidMain uses cloudBootstrap without knowing which one it got:

val koin = startKoin {
    androidContext(this@MyApplication)
    modules(listOf(androidModule, sharedModule) + cloudBootstrap.modules())
}.koin

cloudBootstrap.onKoinStarted(koin)

The free build’s module provides the same interfaces with fakes and no-ops.

val freeCloudModule = module {
    single<AuthRepository> { FakeAuthRepository() }
    single<RemoteSyncGateway> { NoOpSyncGatewayImpl() }
    single<SubscriptionRepository> { FakeSubscriptionRepository() }
    single<PaywallHost> { NoOpPaywallHost }
}

A Safety Net for the Free Build

The free build should never include the auth and payment code. One wrong line in a Gradle file could bring it back, and the app would still build without any error. To catch that, I added a check to CI.

On every pull request, GitHub Actions lists every library in the free release build and fails if one of the full-only SDKs shows up:

- name: Verify the free flavor has no paid SDKs
  run: |
    ./gradlew -q :composeApp:dependencies --configuration prodFreeReleaseRuntimeClasspath > free-deps.txt
    if grep -qiE "com\.revenuecat|io\.github\.jan|io\.ktor|project :libs:auth|project :libs:payment" free-deps.txt; then
      echo "::error::A paid SDK leaked into the free flavor's classpath"
      exit 1
    fi

Lessons Learned

A feature flag hides a feature. A flavor-only dependency removes it. If you don’t want code in an app, keep it out of the build.
Keep third-party types out of your interfaces. Convert them into your own types inside the module that uses the library.
Give shared code interfaces, and let each build choose the implementation. The shared code stays the same for both versions.
Add a CI check for every rule you care about. It’s easy to break a structure rule without noticing.

Wrapping Up

Building this app taught me more about Kotlin Multiplatform than any tutorial did. Most of the lessons came from real problems, like reorganizing the project as it grew, keeping SDKs out of the shared code, and fixing an iOS build that broke without warning. I hope learning about these pitfalls saves you some time on your own project.

I might write more about the app later, like offline sync or testing in-app purchases. If you’d like to see that, follow me here on Medium. And if you’re working on a KMP app yourself, I’d love to hear what you’ve learned in the comments.

Thanks for reading! If you’re preparing for the “Leben in Deutschland” test, you can try the app on Google Play.

See all parts of the series on Medium

How I Structured My First KMP App: Modules, Layers and Source Sets

Avik Sharma Chowdhury — Fri, 02 Oct 2026 10:20:33 +0000

A walkthrough of the modules, source sets and Gradle setup behind a Kotlin Multiplatform app on Google Play.

Part 2 of “Building an Exam Prep App with Kotlin Multiplatform”. Part 1: From Idea to Google Play: The Challenges of My First KMP App

In Part 1, I shared the story of my first Kotlin Multiplatform app: why I built it, how the plan changed after the MVP, and how I ended up shipping a free version while keeping the paid features ready for later.

In this article, I’ll walk through how the project is organized: how the modules fit together, how the code is layered, which code is shared, and which code is platform-specific. I’ll include some code from the project along the way.

Project Overview

The project is split into a few Gradle modules. Each module has its own build file and its own dependencies, and it can only use code from the modules it depends on.

LebenInDeutschland/
├── composeApp/ main app module
├── iosApp/ Xcode project that launches the iOS app
├── libs/ library modules
│ ├── domain-api/ shared interfaces and models
│ ├── auth/ sign-in and cloud sync (Supabase)
│ ├── payment/ subscriptions (RevenueCat)
│ └── telemetry-core/ crash and analytics logging
└── build-logic/ shared Gradle setup

composeApp is the main module. It holds the screens, ViewModels, business logic and local database. Most of that lives in commonMain, and each platform folder only holds what that platform needs. On Android, this module builds the app itself. On iOS, it builds a framework that the Xcode project in iosApp loads.

libs/ holds four smaller modules, each with its own build file. domain-api has only interfaces and data classes, with no SDKs. auth and payment implement those interfaces using Supabase and RevenueCat. telemetry-core wraps crash reporting and analytics.

The app module depends on the shared interfaces in domain-api. The auth and payment modules implement those interfaces, and only the full build flavor includes them.

App Module Layers

Inside composeApp, the code follows Clean Architecture. That’s a way of organizing code into layers, where each layer has one job and only depends on the layers below it:

presentation: screens (Compose UI) and ViewModels. A ViewModel holds the screen’s state and reacts to what the user does.
domain: the rules of the app. For example, CalculateReadinessUseCase decides how ready you are for the exam based on your progress. This layer uses plain Kotlin and has no UI or database code.
data: where the data comes from. The local Room database (Room is Android’s database library, which now also works on iOS in KMP), the question file, and the repositories that combine them.

composeApp/src/commonMain/kotlin/.../
├── data/ local database, repositories, sync
├── domain/ models, repository interfaces, use cases
├── presentation/ screens and ViewModels, one folder per feature
├── di/ dependency injection setup
└── util/

Horizontal vs Vertical Slicing

A question I was asked in a recent interview: is your project sliced horizontally or vertically? It’s a useful way to describe a structure, so here is what the two mean and where my app fits.

Horizontal slicing (also called package by layer) groups code by its technical layer first. There is one data folder, one domain folder and one presentation folder, and every feature adds its files to each of them:

data/
  repository/ QuestionRepositoryImpl, ProgressRepositoryImpl, ExamHistoryRepositoryImpl
domain/
  repository/ QuestionRepository, ProgressRepository, ExamHistoryRepository
  usecase/ CalculateReadinessUseCase
presentation/
  exam/ ExamScreen, ExamViewModel
  study/ StudyScreen, StudyViewModel

Vertical slicing (also called package by feature) groups code by feature first. Each feature gets its own folder, or its own module, with all three layers inside it:

exam/
  data/ ExamHistoryRepositoryImpl
  domain/ ExamHistoryRepository
  presentation/ ExamScreen, ExamViewModel
study/
  data/ ProgressRepositoryImpl
  domain/ ProgressRepository
  presentation/ StudyScreen, StudyViewModel

The first example is how my app module is organized, so it follows horizontal slicing. The presentation layer has one folder per feature, but data and domain are grouped by type (models, repositories, use cases). The second example shows how the same files would look if I had sliced the app vertically.

I chose this because the app is small, and most features share the same data. The exam, study and profile screens all read the same questions and the same progress. In a vertical structure, I’d have to decide which feature owns the progress data, or create a shared “core” module that most features depend on anyway.

Horizontal slicing has trade-offs too:

A change to one feature touches several folders. Adding a field to the exam results means editing data, domain and presentation.
Feature boundaries are not enforced. Nothing stops the study screen from using something meant only for the exam screen.
It’s harder to split up later. In a large app with several teams, vertical slices let each team own a feature and build it on its own.

My modules are a mix. Inside composeApp, the code is sliced horizontally. But auth and payment are separate modules, each owning one feature from its outside service up to the interfaces it provides. I didn’t split them out to follow vertical slicing. I split them out so the free build could leave them out. Still, it shows that the two approaches can live together: horizontal where features share most of their code, and separate modules where a feature needs a clear boundary.

If the app grows, the first step I’d take is to move each screen group (exam, study, profile) into its own feature module (vertical slicing), with a shared core module for the questions and progress data.

App Module Source Sets

Layers split the code by job. Source sets split it by platform.

A source set is a folder of code that is compiled for a specific set of targets. In a KMP project, the code you write in commonMain is compiled for every platform, while androidMain and iosMain are compiled only for their platform.

My app module has these source sets:

composeApp/src/
├── commonMain/ shared by Android and iOS (most of the app)
├── androidMain/ Android only
├── iosMain/ iOS only
├── androidFree/ Android, free build only
├── androidFull/ Android, full build only

Shared Code in commonMain

Almost the whole app lives in commonMain: screens, ViewModels, exam logic, Room database, question data, navigation and localization. For DI, I used Koin, a DI library for Kotlin. Here is part of the shared Koin module:

val sharedModule = module {
    // Repositories
    single<QuestionRepository> { QuestionRepositoryImpl(get(), get(), get(), get(), get(), get()) }
    single<ProgressRepository> { ProgressRepositoryImpl(get(), get(), get(), get()) }

    // Use cases
    factoryOf(::CalculateReadinessUseCase)

    // ViewModels
    viewModelOf(::ExamViewModel)
    viewModelOf(::StudyViewModel)
    // ...
}

Testing the Koin Setup

Koin works differently from Hilt, another popular DI library for Android. Hilt checks the dependency graph when you build the app. If a class needs something that nobody provides, the build fails. Koin connects everything while the app runs. A missing binding still compiles fine, and the app crashes only when a screen first asks for it. That could happen on a user’s phone.

To catch this early, I added a unit test that initializes the Koin configuration and verifies the dependency graph:

@RunWith(RobolectricTestRunner::class)
class KoinGraphTest {

    @After
    fun tearDown() = stopKoin()

    @Test
    fun everyBindingResolves() {
        val koin = startKoin {
            androidContext(ApplicationProvider.getApplicationContext())
            modules(listOf(androidModule, sharedModule))
        }.koin

        koin.get<QuestionRepository>()
        koin.get<ExamViewModel>()
        koin.get<StudyViewModel>()
        koin.get<SettingsViewModel>()
        // ...
    }
}

The test uses Robolectric, a library that simulates the Android environment, so it can run as a normal unit test on your computer.

Platform Code with expect and actual

Some things only the platform can do. Asking a user to rate the app is one of them. Android uses Google Play’s In-App Review API, while iOS uses StoreKit. Kotlin handles this with expect and actual. You declare something in commonMain with expect and each platform provides its own version with actual.

// in commonMain
interface AppReviewController {
    suspend fun requestReview()
}

@Composable
expect fun rememberAppReviewController(): AppReviewController

In androidMain, the Android version asks Google Play to show the prompt:

@Composable
actual fun rememberAppReviewController(): AppReviewController {
    val context = LocalContext.current
    return remember(context) { AndroidAppReviewController(context) }
}

private class AndroidAppReviewController(private val context: Context) : AppReviewController {
    override suspend fun requestReview() {
        // Android-specific in-app review code
    }
}

In iosMain, the iOS version asks StoreKit:

@Composable
actual fun rememberAppReviewController(): AppReviewController =
    remember { IosAppReviewController() }

private class IosAppReviewController : AppReviewController {
    override suspend fun requestReview() {
        // iOS-specific in-app review code
    }
}

The screen that shows the prompt after a passed exam lives in commonMain, and it doesn’t know which platform it’s running on.

A pattern I ended up using a lot: keep the expect part small. Here it’s one function, and the rest is a normal interface. In tests, I can replace the interface with a fake, so the shared code stays easy to test.

Wrapping Up

Most of my app lives in commonMain, and each platform only adds the few things it can do on its own. Layers keep the code organized by job, source sets keep it organized by platform, and a few separate modules keep the outside services apart.

In Part 3, I cover product flavors: how the same codebase builds a free and a full version of the app, and how the free version leaves the sign-in, sync and payment code out entirely.

Thanks for reading! If you’re preparing for the “Leben in Deutschland” test, you can try the app on Google Play.

See all parts of the series on Medium

From Idea to Google Play: The Challenges of My First KMP App

Avik Sharma Chowdhury — Thu, 01 Oct 2026 18:52:18 +0000

The story behind an exam prep app built with Kotlin Multiplatform and Compose Multiplatform

Part 1 of the series “Building an Exam Prep App with Kotlin Multiplatform”

More and more companies are adopting Kotlin Multiplatform (KMP) for their mobile apps. The main motivation is to share business logic across platforms.

If you’re a mobile developer working on a product with separate native Android and iOS apps, you’ve probably noticed inconsistencies between the two, in business logic, UI/UX and other areas. These differences are often hard to remove once they exist.

One way to avoid them is to share the same business logic and UI across both platforms, and keep only the platform-specific parts native. That’s where KMP and Compose Multiplatform (CMP) shine.

Who This App Is For

A few months ago, I took the “Leben in Deutschland” test (“Life in Germany”). It’s a required step when you apply for permanent residency or citizenship in Germany. While preparing, I tried several apps and websites, but none of them really fit what I needed. So I decided to build my own.

The result is Leben in DE: Einbürgerungstest, a free Android app with all 460 official questions, mock exams in the real format, and localization. It works offline and doesn’t need an account.

This article is the story behind it, plus the lessons and tips I picked up along the way.

Study mode: each question and answer with an English translation

Vocabulary Refresher: key German words from the question

Settings: themes, language and your federal state

Why I Built It

The reason is twofold.

First, to learn Kotlin Multiplatform and get hands-on experience by building and shipping a real consumer-facing app. I read a lot of blogs and docs on KMP, watched tutorials on YouTube; however, none of it really clicked until I started building things on my own.
Second, to build something of my own: from planning to execution to shipping the product.

The Journey in Short

February 2026: registered for the exam, planned the app and set up the project.
March: built the CI/CD pipeline (automated builds on every change): unit tests, signed release builds, and the other plumbing a real release needs.
April: built the first MVP (minimum viable product) with the core features: practice questions, mock exams and progress tracking.
May: added sign-in and cloud sync with Supabase (a hosted Postgres database with a login service), and subscriptions with RevenueCat (a service that handles in-app purchases with Google Play and the App Store). Everything worked end to end.
June: ran a closed test on Google Play with a small group of testers. I also used the app a lot to prepare for my own exam. The short mock exams were especially useful, and I ended up scoring 100%. :)
July: based on what I learned, decided to launch for free and split the app into two versions.
August: did the split. The free version became lean, and sign-in, sync and subscriptions moved into a separate “full” version.
September: ran a few rounds of internal testing, then released the free version on Google Play.

Rethinking the Release Plan after the MVP

My original plan was a free app with a paid tier. Paying users would get sign-in, sync across devices and a few handy extra features.

I already knew my target audience: expats living in Germany who were preparing for the exam. What I didn’t know was whether they’d find it useful, which features they’d rely on, or whether any of them would pay for sync. So I decided to launch completely free and revisit the premium idea later, with real data.

First attempt: a feature flag

My first move was a single feature flag in the shared Kotlin code: one true/false value that decides whether the paid features exist. Because it was a compile-time constant, the compiler could strip out any code behind it when it was off. With the flag off, the app never started Supabase or RevenueCat, and all sign-in and premium screens disappeared.

From a user’s point of view, this worked. Under the surface it got messy. The Supabase, RevenueCat and Google Sign-In libraries were still packed inside the app, which made the app size bigger. The app still asked for Google Play’s billing permission even though it sold nothing. And the checks were spread across several screens, so each new feature meant another check to remember.

Second attempt: separate modules and two builds

I moved sign-in, sync and payments into their own modules, which are separate parts of the project that can be included in a build or left out. Then I set up two product flavors for building different versions of an app from the same code:

free: the current version on Google Play. It doesn’t include the sign-in, sync or payment modules at all, so the app is smaller and contains only what it uses.
full: everything, including sign-in, cloud sync and subscriptions.

High-level architecture of the free and full flavors

What I Learned

Learn who your users are before you charge them. I built sync and payments before I had a single user. The work isn’t lost, since it lives on in the full build. However, launching free earlier would have taught me more, sooner.
Hiding a feature and removing it are different things. A feature flag can hide a feature from users, but its code still ships inside the app. To leave code out of a build, you need to separate it at the build level.
Wrap third-party libraries in your own types. Let only one small part of your app talk to a library directly. That part converts the library’s data into simple types you define, and the rest of the app only uses those. In my app, RevenueCat’s own data type had spread across several screens. Before I could move payments into a separate module, I had to replace it everywhere with my own type that answers one question: does this user have premium? Now that conversion happens in one place inside the payment module, and switching payment providers would mean changing only that one place.
KMP let me share most of the app, and the platform-specific parts took the most time. Screens, logic, the question data and the local database are all shared. Sign-in, billing setup and crash reporting needed separate code for each platform, and they took longer than I planned.

Tips for Your First KMP App

Working with Android and iOS

Android Studio covers most of the work. I wrote nearly all the code there, and I could build and run the iOS app from Android Studio too.
Some things need Xcode. I opened Xcode, Apple’s development tool, to set up signing so the app would run on my own iPhone, and to add iOS-only libraries like Firebase through Swift Package Manager (Apple’s built-in tool for adding libraries). You’ll also need a Mac for any iOS work.
Build both platforms often. If you mostly build for Android day to day, the iOS build can break without you noticing. It happened to me.
Start with everything in shared code. Only write platform-specific code when you have to. KMP handles this with expect and actual: shared code declares that it expects something to exist, and each platform provides the actual version.

Builds and Dependencies

Keep all library versions in one file. Gradle’s version catalog (libs.versions.toml) lists every library and its version in one place, so every module uses the same versions.
Adopt Gradle convention plugins early if your project has several modules. Convention plugins are small plugins you write yourself to hold the dependencies your modules share, so each module’s build file stays short and consistent. I will write more on this in the project structure article.
Expect upgrades to come in groups. In KMP, the Kotlin version, Compose Multiplatform and some build tools need to match each other. Upgrading one can require upgrading the others, so I upgrade in small steps and read the release notes first.
Keep secrets out of your repository. My API keys, the app signing key and the Firebase config file (google-services.json) are stored as GitHub Actions secrets (encrypted values that only the automated builds can read). The build pulls them in when it runs, so none of them is ever committed to the code.

Automated Builds (CI)

Set up CI early. CI (continuous integration) means your project is built and checked automatically every time you push code. I added GitHub Actions in the second week. Every pull request runs the unit tests, measures code coverage and posts the result as a comment on the pull request, runs Android Lint to catch common mistakes, and checks that the free build contains no paid libraries.
Use branch names to trigger releases. When I push a branch whose name starts with release/, CI runs the tests and then builds a signed app bundle, the file you upload to Google Play. A branch starting with build-apk/ gives me a signed APK instead, which I can install directly on a test phone. To prepare a release, I create a branch like release/1.4, push it, and a few minutes later the signed file is ready to download.
Turn important rules into CI checks. My free build must not contain any payment or sync libraries, so CI lists the free build’s dependencies on every change and fails if any of them appears.

Shipping and Testing

Add crash reporting early. I added Firebase Crashlytics to both platforms in the second month. It was helpful to get more insights during internal and closed testing.
Test purchases without paying. Google Play lets you add license testers: accounts that can go through the whole purchase flow without being charged.
Plan for database changes. When you change the structure of your local database, write a migration so users keep their progress after an update. My database has changed three times so far.
Keep notes as you go. I keep a document in the project explaining why I made each decision. It has saved me a lot of time when I came back to code weeks later.

Closing Thoughts

Thanks for reading this far. :)

This project did what I hoped it would. I learned Kotlin Multiplatform by shipping a real app, and I built something of my own that people can use today. If you’re preparing for the “Leben in Deutschland” test, or know someone who is, I’d be glad if you gave Leben in DE: Einbürgerungstest a try. Next, I plan to dive deeper into the key product decisions behind the app, with code from the project and the trade-offs behind each choice.

Next in the series: Part 2, How I Structured My First KMP App: Modules, Layers and Source Sets.

See all parts of the series on Medium