Add both libraries as git submodules and resolve them through Gradle composite builds instead of remote publications, so local changes to either library are picked up by the app build directly. Submodules: * secp256k1-frost-kmp (github.com/ac-cord-ac/secp256k1-frost-kmp) at 2478403 -- BIP-327 FROTH/FROST signing over secp256k1, KMP. * lightning-kmp-app (github.com/kngako/lightning-kmp-app) at 6745d88 -- phoenix business logic on top of lightning-kmp-core. Both submodules carry a local commit aligning them with this build's AGP 9.1.1 / Kotlin 2.4.10 (AGP version must match across a composite build or the android variants fail attribute matching). settings.gradle.kts: * includeBuild() both submodule checkouts. * lightning-kmp-app's project stays named ':library' (compose-resources derives its Res package from the project name), so an explicit dependencySubstitution maps the coordinate the app declares, fr.acinq.phoenix:lightning-kmp-app, onto that project. * Drop the jitpack.io repository: it only served com.github.kngako, which is no longer consumed as a binary. composeApp/build.gradle.kts: * commonMain gains ac.cord.auxiliary:library:1.0.0 (secp256k1-frost-kmp, substituted by the composite build). * commonMain replaces com.github.kngako.lightning-kmp-app:library (via JitPack) with fr.acinq.phoenix:lightning-kmp-app:1.0.0 (substituted by the composite build). lightning-kmp-core still comes from Maven Central. * Remove the RestoreJitPackClassifier component-metadata rule and the javax.inject import: it only existed to repair the artifact classifiers JitPack drops from the apple metadata variants, which no longer applies. gradle/libs.versions.toml: * Remove the now-unused lightningKmpApp version and the com.github.kngako lightning-kmp-app catalog entry. Verified: ./gradlew :composeApp:compileCommonMainKotlinMetadata :composeApp:compileDebugKotlinAndroid
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…