Droidcon's app is one Compose Multiplatform codebase with the SwiftUI copy deleted

One codebase, three targets, and the reason it matters here

DroidconKotlin holds the mobile applications for Global Droidcon events plus a web app, built with Compose Multiplatform to run on Android, iOS and the web via Kotlin/JS.

That sentence is a summary of a lot of engineering, and the project is a good example of why the Kotlin Multiplatform ecosystem exists. A conference has an app, and the conference runs in several countries, and each country has a slightly different schedule and a different set of sponsors, and the app is built and released for each conference. Doing that three times, once per platform, in three languages, is a maintenance cost that a volunteer team pays badly.

The repository structure shows the multiplatform layout. There is an android/ directory, an ios/ directory, a web/ directory, and the shared code in shared/ with a shared-ui/ directory alongside it, plus a kotlin-js-store/ directory for the web target and a venuemaps/ directory for the venue maps feature. The Gradle setup is a settings.gradle.kts and a build.gradle.kts at the root with a gradle.properties, and the gradlew wrapper with gradlew.bat for Windows.

The app content is domain specific. The repository has a docs/ directory, an APISummaryFormat.md, a StructuredInstructionFormats.md, a CodeCommentCleanup.md, a DroidconIosDocumentation.md and an IOSDEV.md, plus LINEAR_CONTEXT.md which is a note for working with the Linear issue tracker, and a CLAUDE.md for AI-assisted work. There are also TimeZonesAndroid.txt and TimeZonesiOS.txt, which is a detail that says more about the domain than about the code: a conference app that runs in several countries has to get time zones right on each platform, and the two files are a record of that per-platform difference.

There is an updateDates.py at the root, which is presumably the script that keeps those dates current across the schedule, and a privacy.html and a LICENSE.txt.

The SwiftUI version existed and was deliberately removed

The most interesting part of the README is the paragraph headed Compose UI for both, and it is a first-hand account of a migration.

The app has come a long way. It was one of the earliest KMP apps in the iOS app store, and was certainly the first Compose Multiplatform app in the app store, as it was built and released before there was technically a tech preview.

That last clause dates the achievement. A Compose Multiplatform app shipped to the App Store before Compose Multiplatform had a technical preview means the team used an experimental toolchain for a production conference app, and the blog post linked from the README covers the Droidcon NYC iOS app with Compose.

Then the honest part. CMP has come a long way. Back in 2022, the Compose experience on iOS wasn't great. We kept a SwiftUI version of the UI as the main UI for the iOS app, and let you turn on CMP as an early preview. As of March 2025, the SwiftUI version has been removed entirely. Why do the extra work? But, if you want to do a side-by-side, grab a version from main through Feb 2025 and check it out.

So the sequence was deliberate. In 2022 the iOS Compose experience was not good enough to ship, so the team kept SwiftUI as the primary interface and offered Compose as a preview behind a flag. As the tooling improved they removed the SwiftUI code entirely, and the README even tells you how to see the before and after by taking a version from main through February 2025.

That is the shape of a well run migration. The parallel implementation was a temporary scaffold with a stated end date, and the end date was honoured rather than the scaffold becoming permanent, which is what usually happens to parallel implementations.

Firebase is the one thing you must set up before building

The Building section is short and it names the hard requirement.

The apps need a Firebase account set up to run. You will need to get the google-services.json and put it in android/google-services.json for Android, and the GoogleService-Info.plist and put that in ios/Droidcon/Droidcon/GoogleService-Info.plist for iOS.

So the build is not a clone and run, it needs a Firebase project and the platform configuration files that come with it. The path for iOS is nested three levels deep, ios/Droidcon/Droidcon/, which is a small sign of how the Xcode project layout is mirrored into the repository.

The web target is easier, and there is a single Gradle task for it.

./gradlew :web:jsBrowserDevelopmentRun

The task name carries the information. The :web: prefix is the Gradle project, and jsBrowserDevelopmentRun is the Kotlin/JS browser development run task, which is what the Kotlin Multiplatform plugin generates for a JS target. The web app is therefore not a separate frontend, it is the same shared code compiled to JavaScript and run in a browser, and it is developed through the same Gradle build as the mobile apps.

The project is MIT licensed by the look of the LICENSE.txt name, although the repository listing marks the licence as Apache-2.0, and the top level of the README carries a Touchlab logo and links to touchlab.co. The about section says Droidcon Mobile App brought to you by, and the badge points at Touchlab, a consultancy that builds Kotlin Multiplatform tooling, and the subscribe block says they build solutions that get teams started smoothly with Kotlin Multiplatform and ensure their success in production.

A conference app, not a template

It is worth being clear about what this repository is, because the name DroidconKotlin sounds like a general purpose project and it is not.

It is the application for the Droidcon conference series, and the code is full of the things a conference app needs and a general app does not. The venuemaps/ directory is the venue map feature, which is per-event artwork. The APISummaryFormat.md and StructuredInstructionFormats.md describe the shape of the data the app consumes, the talk schedule and the instructions, and the DroidconIosDocumentation.md and IOSDEV.md are iOS specific notes. The TimeZonesAndroid.txt and TimeZonesiOS.txt record the per-platform time zone handling, and updateDates.py is the script that pushes schedule changes through the app.

That is a real application with a real domain, and the domain is why it is worth reading for a developer. A conference schedule changes daily, the app has to reflect the changes on a schedule, and the schedule is consumed from an API in a structured format. The three platform targets all have to agree about that data, and that is the problem the shared/ and shared-ui/ directories solve.

The final note in the Building section is the one that explains the repository's current state. Prior versions were built and released for each conference, but this updated version is designed to be used for all Droidcon events. As that was a fairly major update, we decided to drop the parallel SwiftUI.

So the direction is consolidation. One application, one UI framework, all the conferences, and a build that produces all three targets from the same Gradle invocation. The trade is that a conference that needs something unusual in the iOS interface now has to do it in Compose Multiplatform or wait for a different solution, and the removed SwiftUI code is the thing that would have allowed exactly that.

Where DroidconKotlin is the wrong choice

The first wrong case is a team that wants a Compose Multiplatform starter. The shared code here is conference software, a schedule, a speaker list, a venue map and a set of sponsors, and the shared-ui/ directory is the Droidcon interface rather than a widget set. Forking it means deleting most of the content and keeping the build wiring, which is still useful, but it is not the same as a clean template.

The second wrong case is a team that needs native iOS behaviour. The project removed its SwiftUI implementation on purpose, so anything that relied on a native iOS widget, a UIKit bridge or an iOS specific interaction pattern now has to be built through Compose Multiplatform or through a platform specific package outside this repository.

The third wrong case is a team without a Firebase account. The build fails without one, and the configuration files are per platform and nested in the platform directories, so a project with a different backend, a self hosted backend or no backend at all, has to restructure the data layer that lives in shared/.

The fourth wrong case is a team that needs something the app does not model. The app is a schedule browser with a map and a chat, and its data structures are shaped for that. Extending it into a different kind of application means replacing the shared layer, and at that point the value of the multiplatform skeleton is the only thing left.

How it differs from three separate applications

The comparison worth making is with the obvious alternative, which is a native Android app, a native iOS app and a web app written separately, and the difference in approach is where the business logic lives.

With three separate applications, the schedule data model is implemented three times. A change to the way a session's speakers are represented has to be made in Kotlin, in Swift and in JavaScript or TypeScript, and the three implementations drift. The visual design drifts too, since the same screen is built with three different toolkits. The teams that build them are often different people, so the coordination cost is not only the code.

With a shared codebase, the schedule model is implemented once in shared/, the presentation is implemented once in shared-ui/, and the platform modules hold the things that genuinely have to be different. On Android that is the Firebase configuration and the packaging, on iOS the plist and the Xcode project, and on the web the JavaScript output and the browser run task.

The second difference is the release. This project produced one build for all three targets, and the README says the previous version was built and released for each conference and this one is designed to be used for all Droidcon events. One build pipeline replacing three per-conference, per-platform release efforts is the concrete payoff, and it is a larger payoff than sharing a data model would be on its own.

The third difference is the cost, and the project is honest about it. Back in 2022, the Compose experience on iOS wasn't great, and the team had to keep a second implementation alive, which is exactly the cost that a shared codebase is supposed to remove. The payoff only arrived once the tooling matured, and until then the team was paying both costs at once.

The fourth difference is the ceiling. A shared codebase caps how far each platform can go native, because the shared UI is the UI. A team that needs a materially native experience on one platform has to either accept the shared limitation or split, and this project chose to split by removing the SwiftUI copy once the shared version was good enough, which is a defensible answer but not a universal one.

Editorial conclusion

DroidconKotlin fits a team that has to ship a conference app for Android, iOS and the web without three separate codebases, and it is a useful reference for anyone doing the same because the README is candid about what the migration cost. It does not fit a team that needs a native iOS interface with platform specific behaviour, since the whole point was to converge on one UI. Before forking it, set up a Firebase account and place google-services.json and GoogleService-Info.plist as the README describes, and note that the project is a conference app rather than a reusable template, with the last push on 2026-07-07.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. touchlab/DroidconKotlin on GitHub