The comments in the snippet below reflect how we deal with this in our organisation:

version: 2
updates:
- package-ecosystem: gradle
  directory: "/"
  schedule:
    interval: daily
  registries: "*"
  groups:

    # All patch updates together, may be merged when CI is green.
    patch-updates:
      update-types: [ "patch" ]

    # All minor updates together. Requires green CI + manual check.
    minor-updates:
      update-types: [ "minor" ]

  # Space left: 3 PRs of ungrouped major updates. Requires green CI + manual check.
  open-pull-requests-limit: 5

# These update less often, so we leave them ungrouped.
- package-ecosystem: github-actions
  directory: "/"
  schedule:
    interval: weekly
  open-pull-requests-limit: 3

Documentation: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups–

See also: other ways to group dependency updates: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates

Why group them?

Easier update management. We try to stay up-to-date with our dependencies, but upon introducing this it turned out we’re 13 patch and 28 minor updates behind. Grouping helps us stay up-to-date with less overhead.

Assuring quality

As commented in the snippet, we deal with testing as follows:

• Patch updates group PR: can be merged as soon as PR is green (build + tests succeed);
• Minor updates group PR: requires green CI + a manual check on device or emulator;
• Major update PRs: these each also require a manual check on a device or emulator, next to green CI.

Note that updates that you’re not ready for yet can still be ignored by including them in the configuration.

Inside each PR the grouped updates are listed, including release notes (if available):

Link to the presentation on Google Slides: https://docs.google.com/presentation/d/1PAQgNRK6bRjNw6BaqVwGlwMA5LwmqQWSccLyJ6yG5sw/edit?usp=sharing.

A year ago I wrote Popular apps using Kotlin Multiplatform (KMP) in 2023 — and what you can learn from them. More apps have joined since then (like Forbes and Bolt), but in this post I’m focusing on one step further: user interface. Compose Multiplatform for iOS has been officially promoted to beta today, but companies have already successfully been using it in production for a while! Let’s take a look at a couple of these apps. I asked several developers to describe their experience with using Compose Multiplatform (informally abbreviated “CMP”) on iOS, and here’s what they said.

Links are included to both the Android and iOS versions of publicly available apps, so you can give them a try for yourself (and maybe see if can spot some Material ripples ).

To give an indication of the size/popularity, I include download numbers from Android, as Apple doesn’t publish those numbers. Screenshots are marketing pictures provided by the developer.

Instabox (internal apps)

The developers at Swedish logistics company Instabox started building their internal iOS apps (used by many thousands of users) with SwiftUI, but after seeing a Compose demo running on iOS they built a prototype, showed it to their CTO, who liked it, and then continued working on it. They were able to build the prototype in only a couple of weeks, because the app was already structured for and with Kotlin Multiplatform.

In an episode of the Talking Kotlin podcast (from August 2023), the developers elaborated their choice and process of working with CMP. They’re particularly happy about how native APIs are simple to use with KMP and how “just being able to move files to [common]” is a strong point of Kotlin Multiplatform.

“It’s fantastic just to keep your expertise in Kotlin and to be able to make this nice app still. I feel it’s cross-platform done right.”

Instabee developer Johannes Svensson

At KotlinConf 2024 a talk called “Compose Multiplatform on mobile at Instabee for over a year” will be given. I will update this article once a recording is available.

When asked what the biggest thing was they had to rewrite themselves, they mentioned navigation. At the time it wasn’t multiplatform yet, but lead developer Johannes told me they’ll most probably adopt the now-multiplatform Compose Navigation in the near future. Currently, the apps are using Voyager for navigation with some custom code on op of it (for back gesture handling, for example).

Markaz (1M+)

Users can buy and sell products online through this app. Everything from business logic to UI is shared Kotlin code. It’s aimed at the Pakistan market, so it may not be available in all countries. In a recent update, iOS’ back swipe gesture was added, on top of the basic iOS look & feel offered by Compose Multiplatorm out of the box, like native scrolling.

“We started working with KMP back in 2021. We had only ten days to build an app for both Android and iOS. We thought about Flutter, but we needed camera features, QR scanning et cetera. So, Kotlin Multiplatform made more sense. We went with a native UI + KMP for sharing business logic and we were able to complete the app in only seven days. Our main product was pure native at that time but we revamped it in November 2022 and shared the business logic with KMP and UI in Jetpack Compose.

We did not have ios app at that time. The motivation was that whenever we needed an iOS app, we would have the business logic ready and we would only need to build the native UI layer. In November 2023, the number of customers asking for an iOS app shot up and we decided what to do. Again, working in a startup we had tight deadlines. Compose was pre-alpha, but we decided to go with it. We ported our Jetpack Compose code to Compose Multiplatform. Dialogs, flow rows and such were not yet available, so we wrote custom components. We were using voyager and wrote custom code on top of it for our needs.

We ported the app to iOS in only 28 days with camera experience, payment integrations and much more. When we launched, there were memory leaks initially, but it’s very smooth now. The team had zero experience on UIkit prior to this, but writing UIkit in kotlin really helped us in writing custom components.”

Markaz developer Kashif Mehmood

Markaz
App Store: https://apps.apple.com/pk/app/markaz-resell-and-earn-money/id6470020517
Play Store: https://play.google.com/store/apps/details?id=com.markaz.app

Wrike (1M+)

Unveiled at KotlinConf today: Wrike is using Compose on iOS in production, for their calendar part of the app. The lead developer said the following during the keynote video (link at the end of this post):

“We’ve decided to go ahead with Compose Multiplatform for building the calendar view. In less than 3 months, it was live on the App Store and Google Play. And the best part: this efficiency came without the need to learn a new language or hire a new development team, by just leveraging our existing knowledge of Kotlin.”

Wrike technical lead Alex Askerov

Wrike
App Store: https://apps.apple.com/ms/app/wrike-work-as-one/id890048871
Play Store: https://play.google.com/store/apps/details?id=com.wrike

Campus (100K+)

Campus – Schedule of classes (original name: Кампус – Расписание занятий) is an app for university students to keep track of their lesson schedule. The app is mostly native, but uses Compose Multiplatform for the “courses” section (the second tab in the app). The developer integrated CMP in the middle of 2023, shortly after it reached alpha state.

“We wanted to test a hypothesis with new content for our users. It was supposed to be a new standalone section, practically unrelated to the rest of the application. Since it was just a hypothesis and we were unsure if we would keep it in the app at all, we needed a solution with minimal effort. However, in case the experiment was successful, we wanted the ability to develop this section further and integrate it more tightly with the application.

At that time, the project already used shared Kotlin Multiplatform logic, but the entire UI was native. For the new section, we considered either Compose Multiplatform or WebView. Both solutions allowed us to conduct the experiment quickly. But with WebView, if the experiment succeeded, we would have to discard the work done and re-implement it using native tools (and shared Kotlin logic), whereas with Compose we immediately get ready-made shared logic, a ready-made Android UI, and if desired, we could replace the UI on iOS with a native version. Therefore, we chose Compose Multiplatform.

Subsequently, the section remained on Compose Multiplatform (and is still available). However, we integrate Redwood by CashApp too – the main screen of the application is made using it. With Redwood, we can get a native UI from the shared Compose code, without drawing with Skia, providing users with a 100% native look and feel. Compose Multiplatform on iOS still has drawbacks compared to the native UI, but it allows for very fast deployment on both platforms, and in the future, if desired, we can replace the iOS UI with a native one while keeping the shared logic.”

IceRock (Campus developer) CTO Aleksey Mikhailov

Кампус – Расписание занятий (Campus)
App Store: https://apps.apple.com/ru/app/кампус-расписание-занятий/id1534975833
Play Store: https://play.google.com/store/apps/details?id=ru.dewish.campus

Ashampoo Photo Organizer (upcoming)

The first version of Ashampoo Photos for iOS was written in SwiftUI. As soon as Compose Multiplatform became available, the developer switched development. The new version built with Compose UI is being tested and not yet available at the time of writing this post. However, with Compose Multiplatform running on more than “just” mobile platforms, the software is also available for Windows (and soon MacOS) at https://www.ashampoo.com/photo-organizer.

“The first version of Ashampoo Photos iOS was written in SwiftUI until Compose for iOS was available. I dropped that SwiftUI version, because it was tiresome to do double work and also it had not all the features because (to my surprise) SwiftUI APIs are lacking. There are a lot of things you just can’t do with SwiftUI – for example handling scrollstates of a list.”

Ashampoo developer Stefan Oltmann

Ashampoo Photo Organizer
App Store: coming soon
Play Store: https://play.google.com/store/apps/details?id=com.ashampoo.photos

Open source: KotlinConf (5K+), Twine RSS Reader (10K+) & FindTravelNow

The last three apps in this list are open source! Don’t skip checking these out if you’re curious to see how exactly they’re built. First off: the official KotlinConf app!

KotlinConf
App Store: https://apps.apple.com/us/app/kotlinconf/id1299196584
Play Store: https://play.google.com/store/apps/details?id=com.jetbrains.kotlinconf
Source code: https://github.com/JetBrains/kotlinconf-app

Then Twine, which is an RSS reader with 10K+ downloads:

Twine – RSS Reader
App Store: https://apps.apple.com/us/app/twine-rss-reader/id6465694958
Play Store: https://play.google.com/store/apps/details?id=dev.sasikanth.rss.reader
Source code: https://github.com/msasikanth/twine

And finally FindTravelNow is a “metasearch travel application” for finding cheap airplane tickets around the world:

FindTravelNow
App Store: https://apps.apple.com/gr/app/findtravelnow/id6471192930
Play Store: https://play.google.com/store/apps/details?id=com.travelapp.findtravelnow
Source code: https://github.com/mirzemehdi/FindTravelNow-KMM

Closing thoughts

I hope this round-up inspires those wanting to move into cross-platform development. Remember that, like with Kotlin Multiplatform in general, if you try any of it but decide to not move further with the multiplatform part, you’re always left with a functioning and modern Android app.

Check out the JetBrains site for more information on how to get started: https://www.jetbrains.com/lp/compose-multiplatform/ and today’s KotlinConf keynote for the Compose iOS beta announcement.

Special thanks to the developers mentioned above who provided valuable input for this article and the community .

Flexibility is one of the key characteristics of Kotlin Multiplatform. It means you can use it where needed, but also that shared code can live next to platform-specific code in the same codebase. Let’s see how that works in practice by taking a well-known app and gradually adopting/migrating it to Kotlin & Compose Multiplatform.

Slides:

Basic usage

Koin Annotations works with a KSP processor that scans for specific annotations and then creates a module{} declaration, as if you would normally write manually. If you’re not familiar with KSP, just know it’s a compiler plugin mechanism that allows for code generation.

I’ll assume starting with a project that’s already configured with Koin, but this article can also serve as a first start guide. Feel free to reply if there are any questions.

1: Configuring the build

First, declare the libraries:

[versions]
koin = "3.5.3"
koin-ksp = "1.3.1"
ksp = "1.9.22-1.0.17"

[libraries]
koin-annotations = { module = "io.insert-koin:koin-annotations", version.ref = "koin-ksp" }
koin-compiler = { module = "io.insert-koin:koin-ksp-compiler", version.ref = "koin-ksp" }
koin-core = { module = "io.insert-koin:koin-core", version.ref = "koin" }
koin-android = { module = "io.insert-koin:koin-android", version.ref = "koin" }

[plugins]
ksp = { id ="com.google.devtools.ksp", version.ref = "ksp" }

Then use these dependencies:

plugins {
    alias(libs.plugins.ksp)
}

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation(libs.koin.annotations)
            implementation(libs.koin.core)
        }
    }
}

dependenies {
    add("kspCommonMainMetadata", libs.koin.compiler)
    // Other compilation targets should be added here, see up in article.
}

For Android, also add implementation(libs.koin.android) in androidMain.dependencies{}.

In older Kotlin/KSP versions, it was necessary to manually add the KSP output as a source directory with kotlin.srcDir("build/generated/ksp/metadata/commonMain/kotlin"). That’s no longer required as it’s automatically configured now. Same goes for the dependsOn kspCommonMainKotlinMetadata workaround you might find online. That’s why it’s recommended to use the latest dependencies.

2: Replace/add the modules to @Modules

Koin Annotations works by adding a class annotated with @Module in the same gradle module as where the the things to be injected also reside. Here’s how that looks.

You might currently have a manually written module:

val myModule = module {
    single<MyRepository> { MyRepositoryImpl(get(), get(), get()) }
    singleOf(::AnotherClass)
    factoryOf(::MoreThings)
    factoryOf(::OneLinePerClass)
}

This can be replaced with:

@Module
@ComponentScan
class MyModule

Now any class/function that we annotate with @Factory (for factory instances) or @Single (for singletons) inside this gradle module will be picked up by the KSP processor.

@Single
class MyRepositoryImpl(
    private val somethingInjected: AnotherClass
) : MyRepository

Note that it’s not needed to specify that MyRepositoryImpl should be provided when the MyRepository interface is requested to be injected somewhere. Koin binds it automatically. So with this setup, the only thing needed to add something to DI is just one annotation in most cases.

Also, if you’re used to Hilt, you might be tempted to write @Inject constructor. That’s not needed with Koin, the single annotation above the class is enough.

@ComponentScan works by scanning from the current package into deeper packages. If you place your DI stuff in a package com.example.mymodule.di, then it won’t find code in the package com.example.mymodule, even though it’s in the same gradle module. In that case, you can instruct the processor on where it should look by changing the annotation to @ComponentScan("com.example.mymodule").

3: Use the generated modules

After a build, the generated modules are available and we can use them in our Koin init. We can check out that generated code to see if everything went well so far! It’s easy to check what’s being generated by navigating to /build/generated/ksp/[target]/kotlin. Here’s how it looks in one of my projects:

Now let’s reference the generated module. Locate your startKoin function call and update it from this:

import org.koin.core.context.startKoin

startKoin { modules(myModule) }

to this:

import org.koin.core.context.startKoin
import org.koin.ksp.generated.module // Import for the generated modules

startKoin { modules(MyModule().module) }

Note that the module is referenced as a class instantiation MyModule() and we then use .module on it to get the generated module. This is because the code Koin generates is placed in the org.koin.ksp.generated.module package.

Now run the app and see the result. That’s all there is to it!

To summarise:

1. Add KSP + Koin Annotations processor
2. Replace manual modules with @Module/@ComponentScan + annotate classes with @Single/@Factory
3. Reference the generated modules from your Koin start method

Advanced usage

Including Modules

You can include Modules in each other. For example, a NetworkModule might include a separate module that provides Json (de)serialisation support. Including is done through the annotation:

@Module(includes = [JsonModule::class]
@ComponentScan
class NetworkModule

Now only including NetworkModule is enough to also get the content of JsonModule in the DI graph.

Extra configuration in Modules

If a class requires something that cannot be automatically provided, you can always manually write the code.

@Module
class MyModule {
    
    @Single
    fun provideSomething(dep: SomeDependency): Something {
        return Something(dep, "extraConfig")
    }
}

Extra configuration in methods

Alternatively, you can also just write a function marked with one of the annotations.

@Module
@ComponentScan
class MyModule

@Single
internal fun provideSomething(dep: SomeDependency): Something {
    // Configuration here...
}

It needs to be in the same gradle module, but not in the same file. This will be picked up by the processor and result in generated code that looks something like the following:

public val MyModule.module: Module = module { single() { Something (dep=get()) } }

Platform-specific code

If you have platform-specific code, you need to run the KSP processor on that target (see Using KSP with KMP: Basic KSP API). The generated module will only be available inside source sets with the same target.

For example, inside [myModule/src/commonMain/kotlin] you can have this:

@Module
@ComponentScan
class NetworkModule

And inside the platform specific module for Android :

@Single
internal fun provideAndroidHttpClient(context: Context) = HttpClient {
    // Extra configuration here...
}

and for iOS :

@Single
internal fun provideAppleHttpClient() = HttpClient {
    // Extra configuration here...
}

If you now compile the project on Android, NetworkModule will be generated in build/generated/ksp/android/androidDebug/kotlin/org.koin.ksp.generated/NetworkModuleGen[package].kt.

And if you compile the project on iOS, NetworkModule will be generated in build/generated/ksp/IosSimulatorArm64/IosSimulatorArm64Main/kotlin/org.koin.ksp.generated/NetworkModuleGen[package].kt.

Any annotated classes inside the [common] code will be available in both platform-specific variants of the module.

If on a higher level you have an AndroidModule and IOSModule, you can simply refer the common module declaration by writing includes = [NetworkModule::class] and the right platform specific generated one will be used automatically.

For Android, if you use koin-android and include androidContext(this@Application) in your startKoin{} block, then you can inject Context anywhere you need it, as its provided by default.

ViewModel and WorkManager on Android

If you’re on Android, you might also have ViewModels and Workers you’d like to easily inject using annotations. The process is similar as above, with a difference in the annotations required. Instead of @Single and @Factory:

• Use @KoinViewModel for ViewModels
• Use @KoinWorker for Workers

These two are available by default in the Koin Annotations library, but note that they’re only available in the androidMain source set.

Scoping modules

Like Koin’s core library, Koin Annotations also has support for scoping with a special @Scope and @Scoped annotation, but those are .. out of scope for this article . See Scopes in Koin Annotations.

Parameters

If you need access to dependencies only accessible on runtime, you can use Koin’s parameter mechanism. The annotation is called @InjectedParam and its usage is explained here: Injected Parameters.

Further reading

• Definitions with Koin Annotations
• Scopes in Koin Annotations

You can reply to this article at https://medium.com/@jacobras/migrating-to-koin-annotations-in-a-multiplatform-project-1e83ba3b5988.

Basic KSP API

First, add the compiler plugin to your version catalog:

[plugins]
ksp = { id ="com.google.devtools.ksp", version = "1.9.22-1.0.17" }

Use the latest release (https://github.com/google/ksp/releases) for the Kotlin version you’re using, in this example KSP 1.0.17 for Kotlin 1.9.22.

Then we can use it. One confusing thing is that normally, we have all our dependencies together in a source set’s dependencies{} block. KSP processors, however, need to be configured outside of the source sets. Here’s how that looks:

plugins {
    alias(libs.plugins.ksp)
}

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation(libs.my.other.dependencies)
            // Not here...
        }
    }
}

dependenies {
    // ... but instead: here!
    add("kspCommonMainMetadata", libs.some.ksp.plugin) // Run KSP on [commonMain] code
    add("kspAndroid", libs.some.ksp.plugin)
    add("kspIosX64", libs.some.ksp.plugin)
    add("kspIosArm64", libs.some.ksp.plugin)
    add("kspIosSimulatorArm64", libs.some.ksp.plugin)
}

Note that there’s a line for each compilation target. Also note that the name for common code here is kspCommonMainMetadata. If you only want to run the annotation processor on common code and not on any target-specific code, than the lines following it can be omitted.

That’s all there is to it! You can now use the generated code. It’s easy to check what’s being generated by navigating to /build/generated/ksp/[target]/kotlin:

In older Kotlin/KSP versions, it was necessary to manually add the KSP output as a source directory with kotlin.srcDir("build/generated/ksp/metadata/commonMain/kotlin"). That’s no longer required as it’s automatically configured now. Same goes for the dependsOn kspCommonMainKotlinMetadata workaround you might find online. That’s why it’s recommended to use the latest dependencies.

Further reading

For more advanced usage with the example of Koin Annotations, see Migrating to Koin Annotations in a multiplatform project.

• kotlinlang.org: KSP Overview

You can reply to this article at https://medium.com/@jacobras/using-ksp-with-kotlin-multiplatform-a-quick-overview-6b858df77b5f

Compose’ default look and feel is that of Material Design. In Compose Multiplatform, certain elements have been tweaked on iOS to feel more native. For example, since version 1.5 the scroll effect on iOS has been made to imitate that of the platform. However, most of the UI elements still look Material. Let’s take a look at an easy way to obtain more of the iOS native look & feel in your app.

We’re going to use a library called Compose Cupertino. It’s available in several flavours:

• cupertino: iOS-like widgets, built using Compose;
• cupertino-native: wrappers around native UIKit components;
• cupertino-adaptive: adaptive themes/wrappers that use Material Design on Android and the iOS-like widgets from cupertino and some widgets from cupertino-native on iOS (main focus of this article);
• cupertino-icons-extended: more than 800 of the most used Apple SF Symbols (note: these are copyrighted and require adhering to a license agreement);
• cupertino-decompose: native feel of screen transitions & swipe gestures.

In this article, we’re going to see how easy it is to use the Adaptive flavour to improve our apps’ system bars (top bar + navigation/tab bar) and main components (buttons + loading indicators + dialogs). There’s a lot more in the library, so take this post as an introduction to it and not a complete guide. We’re also going to see how we can test the iOS look on Android!

Warning: Composer Cupertino is in the experimental phase. All APIs can change in an incompatible way or even be dropped at any point in time. This tutorial was written for version 0.1.0-alpha03.

How does it work?

The native looking widgets in Cupertino are completely rebuilt iOS components using Compose. What this means is that they’re not actual native components, but rather drawn to look like them. Should we be worried about that? I wouldn’t, because that’s similar to how Compose itself rebuilds Android components. Those are also being drawn on canvas instead of relying on legacy android.view components.

Cupertino Adaptive is built not only on top of the Material components, but also with their API in mind. This means that many Material components you’re using now can be switched out for their Adaptive counterparts in seconds. They’ll still be calling the exact same underlying code on Android, but on iOS they’ll be drawn to look like native components. The exception to these are the adaptive widgets ending in *Native, like AdaptiveAlertDialogNative. That one calls the wrappers from Cupertino Native, which invoke the actual UIKit component for a dialog.

Let’s see it in action! All code is available at https://github.com/jacobras/ComposeCupertinoSample.

Tutorial: Material to Cupertino Adaptive

The sample project we’ll be using has been created with the Kotlin Multiplatform Wizard. I added a scaffold with a toolbar, two tabs, a loading indicator and a dialog, all Material3 components. You can view the starting point codebase here: ComposeCupertinoSample/tree/starting-point.

1: Adding the dependency

We add the dependency to our version catalog and implement it in the app:

// in gradle/libs.versions.toml:
cupertino = { module = "io.github.alexzhirkevich:cupertino-adaptive", version = "0.1.0-alpha03" }

// in composeApp/build.gradle.kts, inside common.dependencies:
implementation(libs.cupertino)

Full commit: ComposeCupertinoSample/pull/2/commits/d7b05ad809bc03cf87c3c58a6f7765f5c6442b92

2: Updating the theme

The AppTheme currently uses MaterialTheme. We need to change that to use the adaptive theme. It has two important parameters: material, which takes our current MaterialTheme, and cupertino, which takes a CupertinoTheme. That one allows customising our iOS look by passing custom colours to darkColorScheme() or lightColorScheme().

// Before
@Composable
fun AppTheme(
    useDarkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit
) {
    MaterialTheme(
        colorScheme = if (useDarkTheme) {
            darkColorScheme()
        } else {
          lightColorScheme()
        },
        content = content
    )
}

// After
@OptIn(ExperimentalAdaptiveApi::class)
@Composable
fun AppTheme(
    useDarkTheme: Boolean = isSystemInDarkTheme(),
    theme: Theme = determineTheme(),
    content: @Composable () -> Unit
) {
    AdaptiveTheme(
        material = {
            MaterialTheme(
                colorScheme = if (useDarkTheme) {
                    androidx.compose.material3.darkColorScheme()
                } else {
                    androidx.compose.material3.lightColorScheme()
                },
                content = it
            )
        },
        cupertino = {
            CupertinoTheme(
                colorScheme = if (useDarkTheme) {
                    darkColorScheme()
                } else {
                    lightColorScheme()
                },
                content = it
            )

        },
        target = theme,
        content = content
    )
}

The method determineTheme() is an expect/actual function that returns Theme.Material from [androidMain] and Theme.Cupertino from [iosMain]. See the full commit for details: ComposeCupertinoSample/pull/2/commits/592b3e2a1d35ff8a9961dbc6739e0e25bf581b95

From the next version of Cupertino the Theme will be determined automatically, making the expect/actual function above redundant.

If we run the app now, nothing changes yet. Everything looks exactly like before, because we haven’t used any adaptive components yet. This demonstrates that on Android, everything will remain the same.

3: Using adaptive components

Now comes the fun part! This is also the easiest change. We locate all material components and replace them with the adaptive wrappers. An example:

// Before
Button(onClick = { showContent = !showContent }) {
    Text("Click me!")
}

// After
AdaptiveButton(onClick = { showContent = !showContent }) {
    Text("Click me!")
}

We’re going to change these other components as well:

The pattern should be clear: Cupertino[ComponentName] for the iOS style components and Adaptive[ComponentName] for the ones that switch based on the platform. For this tutorial, we’ll use all the adaptive ones.

Most of these just require changing the name without changing the parameters. The AlertDialog is an exception, which requires changing text to title and confirmButton to buttons.

Full commit: ComposeCupertinoSample/pull/2/commits/a8da43dd7db1187df15c0fbbca9af3ef705c64bd

If we now run the app again on iOS, we see the following (left simulator shows before, right simulator shows after the changes):

That looks amazing! Dark theme also works on both platforms:

Testing on Android

To test the Cupertino look on Android, all that’s required is changing the determineTheme() method in the Android source set:

actual fun determineTheme(): Theme = Theme.Material3

Further steps & reading

I hope it’s clear how easy this was and how big the impact is. There’s more we can do: using adaptive icons (so we get the iOS ones on iPhone/iPad) or use more native-looking components, but that’s up to you. This has been just a short introduction to getting started with the library.

• GitHub: Compose Cupertino
• GitHub: Compose Cupertino sample app

Flexibility is one of the key characteristics of Kotlin Multiplatform. It means you can use it where needed, but also that shared code can live next to platform-specific code in the same codebase. Let’s see how that works in practice by taking a well-known app and gradually adopting/migrating it to Kotlin & Compose Multiplatform.

Slides (with company references removed):

My ComposeActionMenu library, which provides an easy-to-use action menu like the Android Options Menu, is now built with Compose Multiplatform. The supported targets are Android (like before), iOS and JVM (desktop).

Features

• Icons (optional)
• Selectable/checkable items
• Nested sub menus
• Automatic overflow for items that don’t fit the specified maximum

GitHub

https://github.com/jacobras/ComposeActionMenu

I made a small Kotlin Multiplatform library that allows formatting relative dates and filesizes. It’s called HumanReadable and it’s available on GitHub: https://github.com/jacobras/Human-Readable.

In the current version, 1.2.0, the following 11 languages are supported: Czech, Dutch, English (default), French, German, Italian, Indonesian, Russian, Spanish, Turkish and Ukrainian. The library works with kotlinx-datetime.

Features

Relative time

HumanReadable.timeAgo(now - 134.minutes) // "2 hours ago"
HumanReadable.timeAgo(now + 8.minutes) // "in 8 minutes"

Duration

HumanReadable.duration(5.seconds) // "5 seconds"
HumanReadable.duration(7.days) // "1 week"
HumanReadable.duration(544.hours) // "3 weeks"

File size

HumanReadable.fileSize(333) // "333 B"
HumanReadable.fileSize(2_048, decimals = 1) // "2.0 kB"
HumanReadable.fileSize(21_947_282_882, decimals = 2) // "20.44 GB"

GitHub

https://github.com/jacobras/Human-Readable