NYTimes-KMP: one shared domain, nine platform front ends

A shared domain under nine platform front ends

The project is a Kotlin Multiplatform sample of the New York Times app, and its central claim sits in the first sentence of the description: a shared domain covering networking, storage and Molecule view models. Everything above that layer is platform specific. The domain is described as driving Compose Multiplatform user interfaces for Android, Desktop on Linux, macOS and Windows, and Web in both JS and WasmJs flavours, plus a separate Jetpack Compose for Wear OS build, a dual Compose and SwiftUI experience on iOS, and a WPF, WinUI 3 and MAUI set of native Windows hosts.

Counting the run configurations listed in the project gives nine build targets from one source tree: android, wear, ios, desktop, js, wasm, and three separate Windows variants. That is the practical scale of the exercise. The value of the sample is not the article rendering, it is the demonstration that a single domain implementation can be consumed by three different UI toolkits without being rewritten.

The Gradle task list is the whole run matrix

Running the sample is mostly a matter of picking the right Gradle invocation, and the project publishes one command per target. Android and Wear OS are built as debug assemblies, desktop is run directly, and the two web targets each have a browser development run variant, one for JS and one for WasmJs.

./gradlew :app:android:assembleDebug

./gradlew :app:desktop:run

./gradlew :app:web:jsBrowserDevelopmentRun

./gradlew :app:web:wasmJsBrowserDevelopmentRun

./gradlew :app:wear:assembleDebug

The Wear OS target is a separate module rather than a flavour of the Android app, which is the tell that this is more than an Android multiplatform project with extra targets bolted on. The same file names a jsBrowserDevelopmentRun and a wasmJsBrowserDevelopmentRun for the web module, so the browser target is deliberately exercised twice against the two Kotlin web backends.

iOS and Windows need toolchains outside Gradle

Two of the nine targets do not run from the Gradle wrapper at all. The iOS application is built through Xcode with an explicit project, scheme and configuration, which is what a Compose Multiplatform project needs when the Compose side is embedded in an Xcode project.

xcodebuild -project app/ios/ios.xcodeproj -scheme NYTimes -configuration Debug

The Windows targets are launched through dotnet against three different project files, one per host framework.

dotnet run --project app\windows\WpfApp\WpfApp.csproj

The mechanism behind that is worth understanding. The project packages Kotlin/Native compiled for MinGW as NuGet packages with a helper project called kotlin-native-nuget, which is how a .NET host such as WPF or WinUI 3 can consume Kotlin code at all. The repository keeps detailed build notes for the WPF, WinUI and MAUI hosts in a separate README under app/windows, so the dotnet invocation above is the entry point rather than the full procedure. Plan for two toolchains, Gradle and dotnet, on the Windows side, and for Xcode on the iOS side.

Wear OS and iOS step outside the shared Compose layer

The claim that one shared UI layer covers every platform is not quite what the project describes. Three targets reuse the shared Compose Multiplatform code: Android, Desktop and Web. Wear OS instead uses Jetpack Compose for Wear OS, the wearable specific toolkit, while consuming the same shared domain and the same view models. iOS runs a dual experience where Compose and SwiftUI appear side by side, bridged by SKIE, which exposes Kotlin APIs such as Flows in a form Swift code can call directly.

That is the more interesting engineering statement in the project. It says the domain layer is portable to a wearable and to a native Apple UI, and that the interface layer is portable only where the tooling allows it. The platform list in the description is therefore a statement about what can share business logic, not about how many UI frameworks exist in the tree. Any team copying this structure should copy that distinction rather than assume one toolkit everywhere.

Decompose and Molecule define how state travels

The state model is assembled from two libraries that are named separately in the project. Decompose, together with a Router library, handles navigation, and Molecule is used for modelling state, with the view models described as living in the shared domain layer. Because the view models are domain objects rather than Android ViewModels, the same state holder can feed a Compose screen, a SwiftUI view or a WinUI page without a platform adapter in between.

Supporting libraries fill in the surrounding concerns: Ktor for networking, Kotlinx Serialization for content negotiation, Kotlinx Datetime for date handling, KStore for storage, and Compose-imageloader for image loading. The choice of Ktor and Kotlinx Serialization means the network layer and the payload format are shared as well, so the same client code talks to the same API on every platform.

One caveat on structure: the README lists the libraries but does not document the domain module layout in detail, and it gives no error handling or caching policy for the Ktor client. The sample shows the wiring rather than the hardening.

An API key from New York Times gates every build

The single most important line for anyone trying this is short and sits near the top of the description: to build and run the sample you need an API key from the New York Times, requested through the developer.nytimes.com site. This is not a mock data project. The app talks to the real New York Times API, so a key is a prerequisite rather than a nice to have.

That has two consequences. First, onboarding is gated on a third party approval process, so a team cannot evaluate the sample fully offline in the five minutes it takes to clone and run a Gradle task. Second, the exact way the key is passed in is not spelled out in the README, which describes the requirement but does not show a properties file, a local secret or an environment variable name. You will have to look at the source to see where the key is read from, and any code that handles it should keep it out of version control.

For a sample whose purpose is architectural, this is a notable friction point, and it is worth knowing before you commit an afternoon to it.

Apache-2.0 with recent commits and no releases

The licensing is the simplest part of adopting this project. The repository is released under Apache-2.0, with the licence text stored as LICENCE.md at the top level. That is a permissive licence with no copyleft obligation, which means you can read the code, modify it and ship your own version of the sample without negotiating terms, provided you keep the notice and disclaimer in place. The sample does not carry a copyleft restriction on its own source, though the New York Times name and content in the interface are a separate matter from the code licence.

On maintenance, the repository is not archived and the last push was on 2026-09-28. It publishes no GitHub releases, so there is no versioned artefact to depend on and no changelog to read; you track upstream by commit. The README badge shows Kotlin 2.4.0, which is the clearest anchor for how recent the code is. For a template, tracking the main branch is the normal expectation, and the permissiveness of the licence makes that easy to do.

Where a shared domain template stops short of production

The hard limits are visible in the structure rather than hidden. There is no CI or release pipeline described beyond a build workflow badge, no published binaries, and no documented versioning scheme. There is no testing guidance in the README, and for a project whose whole argument is about sharing code safely across nine targets, that absence matters, because shared code is exactly where a broken assumption travels to every platform at once.

The domain layer also takes its data from the New York Times API, so its shapes reflect one content source. A team with a different backend would keep the architecture and replace the models, which is more work than the README implies.

The alternative approach worth comparing is not another vendor product but the simpler one: Compose Multiplatform alone, without the Wear OS, SwiftUI and Windows host layers. That route covers Android, Desktop and Web with a single toolkit and a single build system, and it is the right choice for many teams. NYTimes-KMP earns its extra complexity where you actually need a wearable target, a native Apple interface or a .NET host, and it is the wrong shape for a team that ships on one or two of those platforms.

Editorial conclusion

NYTimes-KMP earns a place in the reading list of teams shaping a Kotlin Multiplatform stack, because it shows how one domain layer can feed Compose, SwiftUI and native Windows hosts without forking the business logic. It is the wrong starting point for a product team that lacks a New York Times API key, for a left-to-right single platform app, or for anyone needing a battle tested news client rather than a reference implementation. Check first that you can obtain the API key, then confirm your toolchain can build the host platform you actually ship, because the Windows and iOS targets need dotnet and xcodebuild rather than plain Gradle.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. xxfast/NYTimes-KMP on GitHub