# Multiplatform Compose and Gradle module metadata abuse

DevFeed: [Multiplatform Compose and Gradle module metadata abuse](<https://devfeed.tech/articles/multiplatform-compose-and-gradle-module-metadata-abuse-20948.md>)

Original publisher: [Read original article](<https://jakewharton.com/multiplatform-compose-and-gradle-module-metadata-abuse/>)

Published: 2021-11-04T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Compose](<https://devfeed.tech/topics/compose.md>), [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Android](<https://devfeed.tech/topics/android.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [Web](<https://devfeed.tech/topics/web.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [code](<https://devfeed.tech/tags/code.md>), [compose](<https://devfeed.tech/tags/compose.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [module](<https://devfeed.tech/tags/module.md>), [multiplatform](<https://devfeed.tech/tags/multiplatform.md>)

## AI overview

An account of how a multiplatform Compose project uses Kotlin and Gradle across Android, iOS, the web, the JVM, and other native targets. The article explains how Compose UI introduced duplicate Android classes because a custom multiplatform runtime and the official Android runtime used different Maven coordinates, and how Gradle Module Metadata could redirect platform-specific dependency resolution to avoid duplication.

## Source excerpt

My primary work project for the better part of a year (named Redwood) is built on top of Compose1 and runs on every platform that Kotlin supports. This of course means Android, but we also have Compose running on iOS, the web, the JVM, and all other native targets. It's truly a multiplatform Compose project2. Getting Compose to run on all these platforms isn't as hard as you would think. The Compose runtime is written as multiplatform Kotlin code but Google only ships it compiled for Android. JetBrains goes farther by shipping versions compiled for the web and for the JVM. We simply go the whole distance and compile it for every Kotlin target, while also shipping it as a single Kotlin multiplatform artifact. For a year this worked fine. However, Compose UI recently went stable which meant our Android engineers were eager to start using it in the main app (as opposed to just samples). Upon Compose UI's introduction D8 fails with a duplicate class error: > Duplicate class androidx.compose.runtime.AbstractApplier found in redwood-compose-runtime (app.cash.redwood:compose-runtime-android:0.1.0-square.15) and runtime-1.0.0-runtime (androidx.compose.runtime:runtime:1.0.0) The androidx.compose.* types are compiled into Redwood's multiplatform Compose runtime artifact. Compose UI depends on the official Compose runtime for Android which also contains these types. Since the two artifacts have different Maven coordinates, Gradle allows both to be included in the app which eventually causes D8 to complain3. Redwood was already building Compose from the same git SHAs as Google's release builds. Ideally we could use our own builds for every platform except Android, and then point at Google's artifact solely for Android. This would allow Gradle to see the two projects as sharing a common dependency thereby de-duplicating the Compose runtime classes. Gradle module metadata The mechanism by which Kotlin multiplatform artifacts resolve the correct dependency is through Gradle's modu