b17901973c
The shared lightning/phoenix logic now lives in kngako/lightning-kmp-app, which publishes a single `:library` module. JitPack serves a repository's submodules under <GROUP>.<ARTIFACT>, hence the com.github.kngako.lightning-kmp-app:library coordinate. The repository is content-filtered to com.github.kngako so it is not consulted for anything else -- an unfiltered jitpack.io entry gets asked about every dependency that misses in mavenCentral, and each miss is a remote round trip. The version is a commit rather than master-SNAPSHOT. For a -SNAPSHOT version JitPack advertises a unique-snapshot maven-metadata.xml (timestamp=<sha>, buildNumber=1) while serving the files under their literal -SNAPSHOT names, so gradle derives library-<target>-master-<sha>-1 and gets a 404 on every artifact. Pinning a commit sidesteps the snapshot machinery entirely and is reproducible; it needs bumping when the fork moves. That leaves the classifier. JitPack rewrites the version inside a published .module file and drops the classifier while doing so, so both the sources and the host-specific metadata variants of each apple target come back naming library-<target>-<ver>.jar -- a file that does not exist, next to the -sources.jar and -metadata.jar that do. The klib and the aar are named without a classifier and so survive the rewrite, which is why the android compilation resolves this dependency perfectly well and only the metadata compilations fail. Every shared ios source set resolves through those, so a component metadata rule puts the -metadata classifier back. It is scoped to the two apple modules and to their metadata variant by name, so it cannot disturb the klib artifacts. Verified: :composeApp:compileCommonMainKotlinMetadata and :composeApp:compileDebugKotlinAndroid both pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is a Kotlin Multiplatform project targeting Android, iOS, Desktop (JVM).
-
/composeApp is for code that will be shared across your Compose Multiplatform applications. It contains several subfolders:
- commonMain is for code that’s common for all targets.
- Other folders are for Kotlin code that will be compiled for only the platform indicated in the folder name. For example, if you want to use Apple’s CoreCrypto for the iOS part of your Kotlin app, the iosMain folder would be the right place for such calls. Similarly, if you want to edit the Desktop (JVM) specific part, the jvmMain folder is the appropriate location.
-
/iosApp contains iOS applications. Even if you’re sharing your UI with Compose Multiplatform, you need this entry point for your iOS app. This is also where you should add SwiftUI code for your project.
Build and Run Android Application
To build and run the development version of the Android app, use the run configuration from the run widget in your IDE’s toolbar or build it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:assembleDebug - on Windows
.\gradlew.bat :composeApp:assembleDebug
Build and Run Desktop (JVM) Application
To build and run the development version of the desktop app, use the run configuration from the run widget in your IDE’s toolbar or run it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:run - on Windows
.\gradlew.bat :composeApp:run
Build and Run iOS Application
To build and run the development version of the iOS app, use the run configuration from the run widget in your IDE’s toolbar or open the /iosApp directory in Xcode and run it from there.
Learn more about Kotlin Multiplatform…