a611277d5d
None of these are imported by any source file in composeApp, generated sources
included, and none is the kind of dependency that gets used without an import.
androidx.paging:paging-common no androidx.paging import anywhere; no DAO
androidx.paging:paging-compose returns PagingSource and nothing calls
collectAsLazyPagingItems, so the Room-Paging
integration that would need it is not in use
androidx.work:work-runtime-ktx no Worker, CoroutineWorker or WorkManager
reference, and no provider or initializer entry
in AndroidManifest.xml
okhttp3:okhttp-coroutines redundant rather than unused: quartz-android
1.14.0 depends on it and at 5.5.0, which was
already upgrading this declaration's 5.4.0. It
stays on the runtime classpath either way
com.ionspin.kotlin:bignum no com.ionspin import. Arrived in a10dc1a with
lightning-mobile support, not with
secp256k1-frost-kmp, though frost was the last
thing in the tree that used bignum at all
no.synth:kmp-zip no no.synth import
no.synth:kmp-zip-okio
The catalog entries and the pagingCommon, workRuntimeKtx and okhttp version refs
go with them, since each was referenced exactly once and nothing else in this
build points at them. lightning-kmp-app also declares work-runtime-ktx, but reads
it from its own catalog, so it is unaffected.
Deliberately kept:
app.cash.sqldelight looks unused by the same test -- no .kt file under
composeApp/src imports it -- but composeApp holds .sq schemas for three databases
(ChannelsDatabase, PaymentsDatabase, AppDatabase) and the generated sources import
it in 29 files. The runtime, the coroutines extensions and the platform drivers
all stay.
compose.desktop.currentOs and kotlinx-coroutines-swing in jvmMain are untouched,
but worth flagging: the `jvm()` target is commented out, so that source set and the
files under composeApp/src/jvmMain are not built. Whether they are dead or waiting
for the desktop target to come back is a decision about the target, not about a
dependency, so this commit leaves both alone.
Commented-out declarations elsewhere in the file -- room vs room3, kspIosX64,
kspJvm -- are left as the migration markers they are.
`:composeApp:assembleDebug` passes and the APK still packages libsecp256k1-jni.so
for all four ABIs.
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…