DEV Community: Russell Wolf

Multiplatform Settings 1.0.0

Russell Wolf — Sun, 15 Jan 2023 03:12:17 +0000

Today, I've released version 1.0.0 of Multiplatform Settings. That means I'm committed to maintaining the current API surface of everything not marked as experimental until there's a 2.0 release (which I don't currently have plans for). If you need to save simple, unstructured key-value data in your multiplatform apps, I hope you'll consider using it. A lot of you already are!

russhwolf / multiplatform-settings

A Kotlin Multiplatform library for saving simple key-value data

Multiplatform Settings

This is a Kotlin library for Multiplatform apps, so that common code can persist key-value data.

A Korean translation of this readme is available separately, maintained by @wooram-yang

Usage

The Settings interface has implementations on the Android, iOS, macOS, watchOS, tvOS, JS, WasmJS, JVM, and Windows platforms.

Implementation Summary

The following table shows the names of implementing classes and what platforms they're available on.

Class	Backing API	Platforms
`KeychainSettings`²	Apple Keychain	iOS, macOS, watchOS, tvOS
`NSUserDefaultsSettings`¹	User Defaults	iOS, macOS, watchOS, tvOS
`PreferencesSettings`¹	`java.util.prefs.Preferences`	JVM
`PropertiesSettings`	`java.util.Properties`	JVM
`SharedPreferencesSettings`¹	`android.content.SharedPreferences`	Android
`StorageSettings`	Web Storage (localStorage)	JS, WasmJS
`RegistrySettings`²	Windows Registry	MingwX64
`DataStoreSettings`³	`androidx.datastore.core.DataStore`	Android,

…

View on GitHub

Some History

Multiplatform Settings was one of the first Kotlin Multiplatform libraries ever released, with the first version published on May 28, 2018. I called that first version 0.1-alpha, though I would later drop the alpha from the versioning scheme as it's somewhat redundant with 0.x. At the time I always imagined that I would call the library 0.x until the overall Multiplatform tooling was labelled as stable, but that's been a longer process than I originally expected. Now that Kotlin Multiplatform Mobile is officially in Beta and we're seeing a big uptick in interest and usage in the community, this seems like a good moment for it.

What's next?

As I detailed in my last post, there are a couple things still marked as experimental in this first stable release, and without committing to any specific timeline, I'd like to stabilize them in the near future. If you're a user of KeychainSettings, RegistrySettings, multiplatform-settings-coroutines, or multiplatform-settings-serialization, I'm very interested in hearing your feedback on how well they're working for you. Bug reports or issues you've had using these APIs are helpful for improving them, but so are reports that you've used them and they've worked well, because that's what tells me that they're ready for wider use.

What about DataStore?

One thing that's new since I started planning this 1.0 release is that Google announced a preview multiplatform version of the DataStore library. This has a very similar use-case to Multiplatform Settings, so which should you use?

One difference between these two libraries is, Multiplatform Settings focuses on interop with existing platform APIs, while DataStore is a brand new implementation. This means that if you have existing platform code using SharedPreferences, UserDefaults, web Storage, or any of the other platform APIs that Multiplatform Settings supports, you can continue to use that code and it will share its source of truth with your common code using Multiplatform Settings.

If that interop is not a concern for you, then DataStore can also be a great choice. And with the multiplatform-settings-coroutines and multiplatform-settings-datastore modules, you can wrap DataStore in the Multiplatform Settings API, if you want use DataStore in some places and Multiplatform Settings in others. These modules are currently only available on Android and JVM, but I intend to release them on other platforms once the multiplatform DataStore becomes more stable.

Thanks for reading

It's an exciting time to be building things with Kotlin Multiplatform! I hope you find this first stable release of Multiplatform Settings helpful for your KMP projects. Let me know in the issues or discussions if you encounter any problems or have any other feedback.

Looking toward Multiplatform Settings 1.0.0

Russell Wolf — Mon, 25 Jul 2022 00:02:18 +0000

The first version of Multiplatform Settings was released in May 2018. At that time I imagined I would leave it in some form of prerelease 0.x state until Kotlin/Native and Kotlin Multiplatform were fully stable. But it's been over four years now, and plenty of other libraries in the ecosystem have gone 1.0. With the Kotlin Multiplatform Mobile beta on the horizon, I've decided it's about time for Multiplatform Settings to have a stable release.

In preparation for that, I recently released version 1.0.0-alpha01. This includes a number of breaking changes in order to make the API a bit more consistent and intuitive. I've done my best to provide migration aids in the form of @Deprecated annotations which in most cases will allow users to update automatically. But if for some reason you're not ready to do that, version 0.9 was also released recently with almost all the same functionality and none of the breakage.

If you've never heard of Multiplatform Settings or you'd like to take a closer look, be sure check it out on Github!

russhwolf / multiplatform-settings

A Kotlin Multiplatform library for saving simple key-value data

Multiplatform Settings

This is a Kotlin library for Multiplatform apps, so that common code can persist key-value data.

A Korean translation of this readme is available separately, maintained by @wooram-yang

Usage

The Settings interface has implementations on the Android, iOS, macOS, watchOS, tvOS, JS, WasmJS, JVM, and Windows platforms.

Implementation Summary

The following table shows the names of implementing classes and what platforms they're available on.

Class	Backing API	Platforms
`KeychainSettings`²	Apple Keychain	iOS, macOS, watchOS, tvOS
`NSUserDefaultsSettings`¹	User Defaults	iOS, macOS, watchOS, tvOS
`PreferencesSettings`¹	`java.util.prefs.Preferences`	JVM
`PropertiesSettings`	`java.util.Properties`	JVM
`SharedPreferencesSettings`¹	`android.content.SharedPreferences`	Android
`StorageSettings`	Web Storage (localStorage)	JS, WasmJS
`RegistrySettings`²	Windows Registry	MingwX64
`DataStoreSettings`³	`androidx.datastore.core.DataStore`	Android,

…

View on GitHub

Breaking Changes

Here's a quick tour of breaking changes and other updates so you know what to expect.

Implementation class renames

In the early days, there was generally a single implementation of the Settings class per platform, so I gave them names like AndroidSettings, AppleSettings, and JsSettings. This naming scheme couldn't really hold as more implementations like KeychainSettings and DataStoreSettings were added. For the sake of consistency, for 1.0 the platform-based names are all being changed to mark the backing API that the implementation uses. The full list of renames is below.

Old name	New name
AndroidSettings	SharedPreferencesSettings
AppleSettings	NSUserDefaultsSettings
JvmPreferencesSettings	PreferencesSettings
JvmPropertiesSettings	PropertiesSettings
WindowsSettings	RegistrySettings
MockSettings	MapSettings

Update listener changes

The original ObservableSettings interface was based around an untyped addListener() function, with the consumer responsible for reading out the current value at the observed key when the listener was called. This was awkward to use, so typed extension functions like addIntListener() were added later to do this work for you, but the core API remained. However, I don't see much use-case for the untyped API, and it makes it more difficult to convert between ObservableSettings and FlowSettings, which only includes typed APIs. So for 1.0 the untyped addListener() will be removed and the extension functions moved into the ObserableSettings interface.

If you maintain a custom ObservableSettings implementation, the migration hopefully shouldn't be too bad because you can leave your untyped addListener() as an internal implementation detail and just call it from the typed methods. This is also what most of the library classes are doing now.

Default values

Going back to the very first release of the library, there are many places across the Multiplatform Settings API surface that take a defaultValue parameter which is returned if the key in question isn't present. These defaultValue parameters almost always have default parameter values, so you could call settings.getInt("key") which would do the same as settings.getInt("key", defaultValue = 0). More recently, nullable getters were added so you can do things like settings.getIntOrNull("key") which will return null if "key" isn't set. This makes for a slightly confusing API where you might be surprised that getInt("key") returns 0 instead of null, so I've opted to remove the default parameter value from the non-nullable getters. This is slightly more verbose in the event that you wanted the library's default values but I think it makes for fewer surprises.

Removing `multiplatform-settings-coroutines-native-mt`

When I first published the coroutines interop APIs, I created two separate modules in an attempt to accomodate people using both the mainline and native-mt coroutines versions. With the new Kotlin/Native memory model on the horizon and understanding that the native-mt branch of kotlinx-coroutines will no longer be maintained, I removed the multiplatform-settings-coroutines-native-mt module in 1.0.0-alpha01. If you were using it, you should migrate to multiplatform-settings-coroutines instead.

Removing experimental markers

Some, but not all, things that were previously marked as @ExperimentalSettingsApi or @ExperimentalSettingsImplementation are no longer annotated to indicate that they will be stable in 1.0. This includes the ObservableSettings and SettingsListener interfaces, and the PreferencesSettings and PropertiesSettings implementations.

Some items remain experimental in 1.0 to indicate that they still aren't well-tested or to allow for the possibility of breaking changes in the future. These include the coroutine and serialization interop APIs, as well as RegistrySettings on Windows and KeychainSettings on Apple platforms. I'm eager for more feedback on all of these things so that they too can become stable, so please let me know what is and isn't working well for you.

The road ahead

After the 1.0 release, the next goal will be stabilizing the APIs and implementations that are still experimental. You can help by providing feedback, fixing bugs, improving testing, or suggesting (and possibly helping implement) other changes.

Coroutines integration

For the multiplatform-settings-coroutines APIs, I want to know if the introduction of SuspendSettings and FlowSettings is helpful. I worry a little that it's a lot of API to accomodate one implementation (DataStoreSettings), but the alternative is wrapping a lot of runBlocking which feels worse. I like the current state of things where you can use the non-coroutine interfaces with internal runBlocking if you want by calling toBlockingSettings() or toBlockingObservableSettings(), because it makes the blocking explicit and opt-in. But I'd like to hear if it works for you too. You can leave feedback in this issue

Serialization integration

For the multiplatform-settings-serialization APIs, I want to know if people find this integration useful. I've already had some good feedback around adding remove() and contains() analogs for serializable values, and there's a PR open that serves as a proof-of-concept. I'd love to hear feedback on that PR or the linked issue. I'd also like to hear what else is missing from these APIs. You can leave feedback in this issue

Apple Keychain integration

The KeychainSettings implementation is experimental because it hasn't been heavily battle-tested yet. If you've tried it, please let me know if it meets your security needs. If you or someone you know is well-versed in the keychain APIs, I'd love a review of whether the implementation is doing everything it needs to in terms of security. You can leave any of this feedback in the related issue

Windows implementation

The RegistrySettings implementation on Windows is experimental largely because I want to add ObservableSettings support, and I want to reserve the possibility of breaking changes until that's in place. If you have ideas about this or want to help out, let me know in the related issue

Linux implementation

At the moment, there is no desktop Linux Settings implementation. I've created various prototypes over the years, but it's not a development environment I spend much time in so I have no insight into what's useful. You can see some of the things I've tried in the PRs linked from this issue. The feedback that's most important to me is what backing API would most useful from an interop perspective if you have some shared and some platform-specific code. It doesn't have to be one of the ones I've already tried.

What's next for 1.0?

Ok that was a lot of text. Thanks for sticking with me as I braindump the state of the library and the roadmap to 1.0 and beyond.

I think I'd like to aim the final 1.0 release for around the Kotlin 1.8 timeframe, which will be sometime this fall. So I'd love to hear what folks think of these changes, and of the library overall. If there's anything else you think should change while the library is still in the pre-1.0 stage, now is the time to let me know!

Trying out the experimental new Kotlin/Native memory model

Russell Wolf — Sat, 07 Aug 2021 15:54:36 +0000

Photo by Victor Serban on Unsplash

Update Aug 12, 2021: This article has been updated with a new section about using the new memory model with kotlinx-coroutines.

If you've been following Kotlin/Native at all over the last couple of years, you'll know that it's memory model has been controversial. Last year, the Kotlin team committed to redesigning it, and this year they promised a preview by the end of the summer. Well, there hasn't been an official announcement yet, but that preview is present in the Kotlin 1.5.30 early-access release.

TL,DR

Update your Kotlin version to 1.5.30-RC
Add kotlinOptions.freeCompilerArgs += listOf("-memory-model", "experimental") to your Kotlin/Native compilations
Add kotlin.native.cacheKind=none to gradle.properties
To use coroutines with the new model, add https://maven.pkg.jetbrains.space/public/p/kotlinx-coroutines/maven to repositories and use version 1.5.1-new-mm-dev1.
Mutate unfrozen objects from different threads

Wait, what?!

Yup! The memory model is controlled with the -memory-model command-line flag. Pass experimental for the new model or strict for the existing one^*. Due to current limitations, you also need to disable compiler caching with the kotlin.native.cacheKind=none gradle property.

^*You can also pass relaxed, but it's probably not a good idea.

You can pass the flag to all your Kotlin/Native targets by doing something like this from Gradle:

kotlin {
    targets.withType<KotlinNativeTarget>().all {
        compilations.all {
            kotlinOptions.freeCompilerArgs += 
                listOf("-memory-model", "experimental")
        }
    }
}

Now you can freely mutate unfrozen state across threads. Let's see what that looks like.

Testing the two models

In the current strict memory model, if you wanted to write a function to run code in a background thread, it might look something like this:

fun <T> doInBackground(action: () -> T): T {
    val worker = Worker.start()
    val future = worker.execute(
        TransferMode.SAFE, 
        { action.freeze() }, 
        { it() }
    )
    return future.result
}

The function takes a lambda, freezes it, and executes it in a new Worker which runs on a background thread. Because the lambda is frozen, the only way we can have mutable state is by using atomics, as in the following test (which can run on the iosX64 target)

@Test fun oldMemoryTest() {
    val didRunLambda = AtomicReference(false)
    assertTrue(NSThread.isMainThread)
    doInBackground {
        didRunLambda.value = true
        assertFalse(NSThread.isMainThread)
    }
    assertTrue(didRunLambda.value)
}

Here we initialize an atomic boolean to false on the main thread, mutate it to true on a background thread, and assert that it's true from the main thread.

Code like the above is the primary way of handling mutable state across threads in the current memory model (although it's usually hidden deep in the machinery of a library like kotlinx.coroutines), and it still works in the experimental model. But we can also do new things we coudln't do before.

We might naively expect that the new model will just let us drop the atomic and do something like the following

@Test fun newMemoryTest() {
    var didRunLambda = false
    assertTrue(NSThread.isMainThread)
    doInBackground {
        didRunLambda = true // *
        assertFalse(NSThread.isMainThread)
    }
    assertTrue(didRunLambda)
}

However, this will fail at the starred line with an InvalidMutabilityException. Our doInBackground() function freezes the lambda, and the new memory model still respects freeze semantics and doesn't allow frozen things to change. That includes the didRunLambda boolean which is captured from the outer scope.

So let's create a new backgrounding function. Note that this function works only in the new model, and will fail with an IllegalStateException if you use the existing strict memory model.

fun <T> doInBackgroundUnfrozen(action: () -> T): T {
    val worker = Worker.start()
    val future = worker.execute(
        TransferMode.SAFE, 
        { action }, // No more freeze() call
        { it() }
    )
    return future.result
}

Subbing this function into the test allows it to pass in the new model.

@Test fun newMemoryTestUnfrozen() {
    var didRunLambda = false
    assertTrue(NSThread.isMainThread)
    doInBackgroundUnfrozen {
        didRunLambda = true
        assertFalse(NSThread.isMainThread)
    }
    assertTrue(didRunLambda)
}

Coroutines

There's also now a early dev release of coroutines with the new model! It's available from the coroutines internal maven repo, so you need to add it to your repositories:

repositories {
    // ...
    maven(url = "https://maven.pkg.jetbrains.space/public/p/kotlinx-coroutines/maven")
}

Then you can add the coroutines dependency with version 1.5.1-new-mm-dev1:

kotlin {
    sourceSets {
        val commonMain by getting {
            dependencies {
                // ...
                implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.5.1-new-mm-dev1")
            }
        }
        // ...
    }
}

Now you can scrap doInBackground() and doInBackgroundUnfrozen(), and just use withContext():

@Test fun newMemoryCoroutinesTest() = runBlocking {
    var didRunLambda = false
    assertTrue(NSThread.isMainThread)
    withContext(Dispatchers.Default) {
        didRunLambda = true
        assertFalse(NSThread.isMainThread)
    }
    assertTrue(didRunLambda)
}

Further thoughts

It's pretty neat seeing this in action! As the Kotlin team promised previously, existing code written around freeze() in the strict memory model still appears to behave the same in the new experimental model. But we also now have the ability to pass unfrozen things across threads. This should mean that, once the model is finalized, existing code won't need to migrate immediately. However, early adopters of the experimental model will likely need to wait for any concurrency libraries they depend on to update, or else they'll still need to handle the existing freeze() behavior. That work has already begun in kotlinx.coroutines.

Caveats

The experimental new memory model is an undocumented preview release. I haven't tried much beyond what's presented here, and I have no idea what limitations or possible issues there are. Use at your own risk! That said, it might be a nice time to try it out, especially if you maintain library code that handles freeze-related logic currently. Be sure to report any bugs you see, and give JetBrains feedback on if it works for you.

Should I use this in production?

No.

Thanks for reading! Let me know in the comments if you have questions, or you can reach out to me at @russhwolf on Twitter or the Kotlin Slack. And if you find all this interesting, maybe you'd like to work with or work at Touchlab.

Kotlin Coroutines and Swift, revisited

Russell Wolf — Fri, 04 Jun 2021 20:50:38 +0000

Last year I wrote about a pattern for interop between Kotlin coroutines and RxSwift. I appreciate the attention it received, particularly where people have applied it to other reactive frameworks, and even including a code-generation plugin using the same ideas. I figure it's about time I talk about my own updated thinking on these patterns.

If you haven't read the previous article, I suggest going through that first for context.

Kotlin updates

We'll stick to the same repository class as the original article, and walk through exposing it to iOS.

class ThingRepository {
    suspend fun getThing(succeed: Boolean): Thing {
        delay(100)
        if (succeed) {
            return Thing(0)
        } else {
            error("oh no!")
        }
    }

    fun getThingStream(
        count: Int,
        succeed: Boolean
    ): Flow<Thing> = flow {
        repeat(count) {
            delay(100)
            emit(Thing(it))
        }
        if (!succeed) error("oops!")
    }
}

In the previous article, I suggested the following pattern for wrapping suspend functions with callbacks that could run on iOS

class SuspendWrapper<T>(private val suspender: suspend () -> T) {
    init {
        freeze()
    }

    fun subscribe(
        scope: CoroutineScope,
        onSuccess: (item: T) -> Unit,
        onThrow: (error: Throwable) -> Unit
    ): Job = scope.launch {
        try {
            onSuccess(suspender().freeze())
        } catch (error: Throwable) {
            onThrow(error.freeze())
        }
    }.freeze()
}

After having played with these patterns more, a drawback to this emerged. This class expects a CoroutineScope to be supplied by the caller (which will be in Swift) at subscription time. This can be nice for flexibility if it might be called in different contexts, but in the vast majority of cases in practice this will live in some sort of class with its own scope, and it's much more pleasant to work with the scope from Kotlin than from Swift. So let's make the scope a constructor parameter instead.

class SuspendWrapper<T : Any>(
    private val scope: CoroutineScope,
    private val suspender: suspend () -> T
) {
    init {
        freeze()
    }

    fun subscribe(
        onSuccess: (item: T) -> Unit,
        onThrow: (error: Throwable) -> Unit
    ) = scope.launch {
        try {
            onSuccess(suspender().freeze())
        } catch (error: Throwable) {
            onThrow(error.freeze())
        }
    }.freeze()
}

A similar change can be made for FlowWrapper. Now we can manage that scope in the iOS repository class, at the Kotlin level.

class ThingRepositoryIos(private val repository: ThingRepository) {
    private val scope: CoroutineScope =
        CoroutineScope(SupervisorJob() + Dispatchers.Default)

    init {
        freeze()
    }

    fun getThingWrapper(succeed: Boolean) =
        SuspendWrapper(scope) { repository.getThing(succeed) }

    fun getThingStreamWrapper(count: Int, succeed: Boolean) =
        FlowWrapper(
            scope, 
            repository.getThingStream(count, succeed)
        )
}

Now we can drop the scope parameter from the RxSwift subscribe calls.

Swift repository wrappers

The previous article didn't consider Swift-side architecture beyond the createObservable() and createSingle() functions. But in practice you aren't likely to want to call these inline at every call-site. You can add one more wrapper layer in Swift so that the rest of the Swift side of the codebase doesn't need to know about the Kotlin classes at all. For example:

class ThingRepositoryRxSwift {
    private let delegate: ThingRepositoryIos

    init() {
        self.delegate = ThingRepositoryIos(repository: ThingRepository())
    }

    func getThing(succeed: Bool) -> Single<Thing> {
        createSingle(suspendWrapper: delegate.getThingWrapper(succeed: succeed))
    }

    func getThingStream(count: Int32, succeed: Bool) -> Observable<Thing> {
        createObservable(flowWrapper: delegate.getThingStreamWrapper(count: count, succeed: succeed))
    }
}

Now the rest of the code sees only ThingRepositoryRxSwift and its RxSwift API and the Kotlin essentially becomes an implementation detail.

Combine

The other thing I've done more thinking about since the original article is how this can apply to the Combine framework. Combine has a Publisher type which represents an observable stream with a particular type of event and error.

func createPublisher<T>(
    flowWrapper: FlowWrapper<T>
) -> AnyPublisher<T, KotlinError> {
    return Deferred<Publishers.HandleEvents<PassthroughSubject<T, KotlinError>>> {
        let subject = PassthroughSubject<T, KotlinError>()
        let job = flowWrapper.subscribe { (item) in
            let _ = subject.send(item)
        } onComplete: {
            subject.send(completion: .finished)
        } onThrow: { (error) in
            subject.send(completion: .failure(KotlinError(error)))
        }
        return subject.handleEvents(receiveCancel: {
            job.cancel(cause: nil)
        })
    }.eraseToAnyPublisher()
}

This makes use of a PassthroughSubject to handle the heavy lifting, and simply forwards the Flow events from our FlowWrapper callbacks to it. It makes use of the same KotlinError error type as the previous article. Note the eraseToAnyPublisher() call at the end, which cleans up our return type to AnyPublisher<T, KotlinError> instead of Deferred<Publishers.HandleEvents<PassthroughSubject<T, KotlinError>>>. Combine's generic internals are weird but they give us this utility to hide them.

For single-event streams, Combine has a Future type. Unfortunately, there's no eraseToAnyFuture() helper that I could find, so we still end up typed as a multi-event Publisher instead.

func createFuture<T>(
    suspendWrapper: SuspendWrapper<T>
) -> AnyPublisher<T, KotlinError> {
    return Deferred<Publishers.HandleEvents<Future<T, KotlinError>>> {
        var job: Kotlinx_coroutines_coreJob? = nil
        return Future { promise in
            job = suspendWrapper.subscribe(
                onSuccess: { item in promise(.success(item)) },
                onThrow: { error in promise(.failure(KotlinError(error))) }
            )
        }.handleEvents(receiveCancel: {
            job?.cancel(cause: nil)
        })
    }
    .eraseToAnyPublisher()
}

You could also do something similar with a PassthroughSubject, but I suspect (without having profiled extensively) that this version is probably lighter. There's also async/await support on the horizon for Swift, which would be nice to integrate here in the future.

SwiftUI

One of the nice things about using Combine is it integrates well with SwiftUI. You can create a model class like

class ThingModel: ObservableObject {
    @Published
    var thing: Thing = Thing(count: -1)

    var cancellables = Set<AnyCancellable>()

    init(_ repository: ThingRepositoryIos) {
        createPublisher(
            flowWrapper: repository.getThingStreamWrapper(
                count: 100, 
                succeed: true)
            )
            .replaceError(with: Thing(count: -1))
            .receive(on: DispatchQueue.main)
            .sink { thing in self.thing = thing }
            .store(in: &cancellables)
    }
}

and then observe the Thing in a view like

struct ThingView : View {
    @ObservedObject
    var thingModel: ThingModel

    init(_ repository: ThingRepositoryIos) {
        thingModel = ThingModel(repository)
    }

    var body: some View {
        Text("Count: \(thingModel.thing.count)")
    }
}

Isn't this a lot of boilerplate?

There's obviously a lot of layers here, and that can be a bit off-putting. However, I think this sort of layering is a helpful pattern in a lot of Swift/Kotlin interop.

We have two different languages that we're trying to make talk to each other. While for most simple use-cases the interop is handled for us by the compiler, in more complex situations we need to carve out a shared cross-language interface by hand. This will often take the form of a Kotlin wrapper layer that's less idiomatic to Kotlin consumers but is possible for Swift to consume, and then an extra Swift layer to take those Kotlin wrappers and massage them into more idiomatic Swift code.

We shouldn't be surprised that this extra glue code is needed, given the differences in language and environment. Most of it is either things we only need to write once (like the SuspendWrapper class in Kotlin or the createObservable() or createPublisher() functions in Swift), or things that follow very consistent patterns that we might be able to codegen (like creating ThingRepositoryIos based on ThingRepository in Kotlin, or ThingModel in Swift).

Sure, this extra infrastructure wouldn't be needed if we were writing a pure native iOS app in Swift. But we've gained the ability to share Kotlin code into Swift in a more idiomatic way. I tend to think the tradeoff is worth it.

Final thoughts

I'd like to further iterate on all these patterns in some form of codegen library in the future, as compiler plugins start to mature. I'm hopeful for a multiplatform version of Kotlin Symbol Processing to help with this, though this won't be possible before Kotlin 1.5.20 at the earliest due to missing extension points in the Kotlin compiler. Fingers crossed for something this summer I guess.

2023 Update
As of 2023, Touchlab has introduced a new tool to help with flow and suspend interop, as well as sealed classes wrapped as enums. We are pleased to introduce you to SKIE, Swift/Kotlin Interface Extender. For more information and to sign up for a demo, please visit skie.touchlab.co.

If you'd like to play with all of this yourself, updated code samples are available at the following repo:

touchlab / SwiftCoroutines

As before, this includes nullable and non-null versions of both single-event and multiple-event streams, and Swift unit tests to verify it all works correctly. In addition, there's now a SwiftUI display to demo the Combine code, as well as log-based demos of RxSwift and Combine bindings.

Hope you enjoyed this! I'd love to hear feedback, either in the comments or on Slack or Twitter. If you'd like to go deeper, feel free to reach out to Touchlab. We're also hiring!

Multiplatform Settings version 0.7 is out!

Russell Wolf — Sun, 27 Dec 2020 00:37:48 +0000

Today I’ve released version 0.7 of Multiplatform Settings! There's a lot of new features in this one, including integrations with some of the kotlinx libraries which have been incubating in PRs for a long time, so I'm excited to hear what people think.

TL;DR links

Release Notes
Maven Central

Read on for more details on what's new.

Serialization

I've had the idea in my head for a while that I'd like to generalize the existing delegate APIs to enable storing non-primitive data. Thanks to some suggestions from Eugenio Marletti and Leonid Startsev I came to realize how that could be done using kotlinx.serialization, by using its custom format APIs. There's been a PR open for a while which I iterated on as the serialization library adjusted those APIs and approached it's first stable release. Now that the library has reached 1.0, even if most of the encoder/decoder APIs are still experimental, it feels like the right time to release the integration with Multiplatform Settings.

With this, if you have a serializable class like

@Serializable
class User(val nickname: String?)

you can save an instance to Settings by calling

settings.encodeValue(User.serializer(), "user", user)

and retrieve it with

val user: User = settings.decodeValue(
    User.serializer(), 
    "user", 
    defaultValue
)
val nullableUser: User? = settings.decodeValueOrNull(
    User.serializer(), 
    "user"
)

or you could do both via a delegate api

var user by settings.serializedValue(User.serializer(), "user")

Of course, it's no substitute for a structured database like sqlite if you need atomicity for more complex data, but for simple use-cases I hope people find it helpful. I also think it's also a neat demonstration of some less well-known parts of kotlinx.serialization, so I hope it can inspire other interesting custom formats as well.

Coroutines

Similar to serialization, there's been a PR up for a while with Flow extensions on ObservableSettings. That's finally merged in 0.7, with two different artifacts depending on whether you use the native-mt branch of coroutines. I'm not sure having separate artifacts is totally necessary, but I figured it might help avoid people being forced to change which coroutines version they use just to interact with Settings.

Datastore

Until recently I thought Flow APIs would be the only interesting coroutine functionality worth adding to the library, but then the Android team released Jetpack DataStore. This includes a fully suspend-based key-value store intended to replace SharedPreferences. The existing Settings API isn't a great fit for DataStore since everything would need to be wrapped in runBlocking calls internally, which could easily catch consumers by surprise.

To better handle this with fewer surprises, I've added SuspendSettings and FlowSettings interfaces, which are essentially coroutine-based analogs of Settings and ObservableSettings (including that FlowSettings extends SuspendSettings). There's a DataStoreSettings which is the only direct implementation of FlowSettings, but there are also converters Settings.toSuspendSettings() and ObservableSettings.toFlowSettings() which wrap the non-coroutine interfaces in the suspending ones. This lets you use a single suspendable API from common if you're using DataStore on Android.

// Common
expect val settings: FlowSettings

// Android
actual val settings: FlowSettings = DataStoreSettings(/*...*/)

// iOS
actual val settings: FlowSettings = AppleSettings(/*...*/).toFlowSettings()

This feels like a lot of machinery just to interop with one API, but it seems important if DataStore is going to become the new key-value API of choice on Android. I've been watching its development closely and I'm interested to see if other async key-value libraries follow. If they do, Multiplatform Settings will be ready.

Keychain

I've been asked numerous times about secure storage. Android provides EncryptedSharedPreferences as part of androidx.security, which can be passed as a delegate to AndroidSettings just like any other SharedPreferences implementation, but there's no simple equivalent way to get encrypted storage on iOS or any other existing Settings platform. In 0.7 there's a new KeychainSettings implementation available on Apple platforms, which stores data in the Keychain instead of in User Defaults.

I'm not an expert in security or in the keychain APIs, so I'd appreciate feedback as to whether this fits your use-cases and security needs.

Other little things

Typed listeners

In a quality-of-life improvement that I meant to throw in a long time ago and forgot about, there are now extension functions to allow typed listeners for ObservableSettings. Where before you had to write code like

settings.addListener {
    val value = settings.getInt("myInt")
    // do something with value
}

now you can shorten it to

settings.addIntListener("myInt") { value ->
    // do something with value
}

Sample updates

Previously, the sample project got a little too cute with method references and other syntax shortcuts and it made it hard to see what typical usage of the library looks like. I've refactored it to focus more on the core APIs so it's easier to poke around and understand what's going on. I'd like to do more here in the future, since there's a lot of the library currently not touched by the sample app.

Desktop Linux

I've had a PR open for a while now with a desktop Linux Settings implementation based on QDBM. There's no good reason to use QDBM except that I originally prototyped it in the kotlin macos target which includes NDBM with very similar DBM-based APIs. I could merge it but I really have no idea if anyone would want to use it, or if wrapping some other API would be better. I'd very much like to hear from the desktop Linux dev community about what would be useful here since this is the only desktop platform currently missing a first-party implementation.

Hopefully that was a helpful tour of the major new developments in Multiplatform Settings 0.7. I don't get a huge amount of feedback, so please do reach out and let me know what is and isn't working for you in the library, and if there's other features you're looking for. You can leave a comment on this blog, reach out to me on Twitter or Kotlin Slack, file a Github issue, or start a thread on the brand new Multiplatform Settings Github Discussions board. And of course, be on the lookout for more updates to come!

Working with Kotlin Coroutines and RxSwift

Russell Wolf — Mon, 15 Jun 2020 19:07:18 +0000

A recent client engagement involved interop between Kotlin coroutines in shared code, and RxSwift on the iOS side. We did some work to ensure that this could be done in a way that is type-safe and thread-safe. Whether or not you use RxSwift, hopefully this can provide some useful patterns for interop code.

Coroutines are a Kotlin language feature that allows asynchronous code to be written in a way that looks like synchronous code, avoiding the nesting that often comes with callback-based APIs. They're available on all Kotlin platforms, but have some limitations on the native side. The release version of native coroutines is limited to single-threaded use-cases, though there are experimental releases available that are multithreaded with some risk of memory leaks. But while they're a fully-supported language feature of Kotlin, they don't translate to Objective-C and Swift.

RxSwift is a Swift implementation of the Reactive Streams specification. It's one way to handle asynchronous code on Swift, and has many operators for combining and transforming event streams. Though some of the names are different, much of the API will feel familiar to Kotlin developers who have experience with RxJava.

Since Coroutines will almost always be present in shared code, and RxSwift is a common option on the iOS side, hopefully the motivation to communicate between them is clear. So let’s start writing some code.

Common Repository

We’ll work with a dummy repository class that looks like this, defined in src/commonMain

class ThingRepository {
    suspend fun getThing(succeed: Boolean): Thing {
        delay(100)
        if (succeed) {
            return Thing(0)
        } else {
            error("oh no!")
        }
    }

    fun getThingStream(count: Int, succeed: Boolean): Flow<Thing> = flow {
        repeat(count) {
            delay(100)
            emit(Thing(it))
        }
        if (!succeed) error("oops!")
    }
}

From the outside this looks roughly like a real repository might, but with inputs that let us control the output a bit more directly for demonstration purposes. It gives us the ability to test success and error cases for both single-event suspend functions, and multiple-event Flows. The internal delays also give us a chance to cancel things in-flight so we can verify that works as expected.

Of course, if we try to consume this repository from Swift code, we run into some immediate problems. Suspend functions are not visible at all to Swift^*, and while the Flow type is visible, most APIs you might call on it are not. Further, Flow's generic type is not visible to Swift, due to limitations in how generics are translated from Kotlin, though Objective-C, and then to Swift. Generic arguments only make it from Kotlin to Swift when defined on classes, and Flow is an interface.

^*This will be changing somewhat in Kotlin 1.4, where suspend functions will generate a callback function visible to Objective-C/Swift. However, this uses only the language-level suspend function support, and none of the extra functionality from the kotlinx.coroutines library, so it doesn't help with cancellation or the structured concurrency model. We want to be able to control cancellation and threading via CoroutineScopes, so the new stuff in 1.4 won't help here.

Suspend and Flow wrappers

So, let's add some wrapper types that are easier to interact with from Swift. These are iOS-specific, so we can put them in the iosMain source-set. First, SuspendWrapper:

class SuspendWrapper<T>(private val suspender: suspend () -> T) {
    fun subscribe(
        scope: CoroutineScope,
        onSuccess: (item: T) -> Unit,
        onThrow: (error: Throwable) -> Unit
    ): Job = scope.launch {
        try {
            onSuccess(suspender())
        } catch (error: Throwable) {
            onThrow(error)
        }
    }
}

A couple things to highlight here:

The subscribe function is a stand-in for invoking the lambda since that's impossible from Swift, but it also adds some callbacks. This lets us easily hook into the different Rx event callbacks. If we care about other parts of the Rx lifecycle like subscription and disposal we could add other lambdas here and call them at the appropriate time.
There's a scope parameter, which I left in to keep this architecture-agnostic. You could alternatively make the scope internal to the wrapper, if you want to assert that you always call this suspend function in a specific scope. This would be less flexible but would avoid some work on the Swift side.
The generic parameter has an Any upper-bound. Without this, all Swift references to T would be nullable, even if a nonnull type were used for T. If you need to work with nullable types, I recommend having a separate NullableSuspendWrapper which differs only in the generic upper-bound.

But there's still an issue. There's a good chance we'll want to talk to these wrappers in a multithreaded setting. In the default, single-threaded coroutines version, this would require the success and throw callbacks to switch back to the original thread before running, which is a heavy limitation. Things are easier if we use the multithreaded coroutines branch, but we still need to do some work to make this thread-safe for Kotlin/Native.

class SuspendWrapper<T>(private val suspender: suspend () -> T) {
    init {
        freeze()
    }

    fun subscribe(
        scope: CoroutineScope,
        onSuccess: (item: T) -> Unit,
        onThrow: (error: Throwable) -> Unit
    ): Job = scope.launch {
        try {
            onSuccess(suspender().freeze())
        } catch (error: Throwable) {
            onThrow(error.freeze())
        }
    }.freeze()
}

We've added freeze() calls in three key places:

On initialization, so the SuspendWrapper itself can cross threads
On the arguments of each callback, so that emissions or errors can be passed to other threads.
On the Job returned by the subscribe() call, so that it can be cancelled from any thread.

The Flow equivalent is this:

class FlowWrapper<T>(private val flow: Flow<T>) {
    init {
        freeze()
    }

    fun subscribe(
        scope: CoroutineScope,
        onEach: (item: T) -> Unit,
        onComplete: () -> Unit,
        onThrow: (error: Throwable) -> Unit
    ): Job = flow
        .onEach { onEach(it.freeze()) }
        .catch { onThrow(it.freeze()) }
        .onCompletion { onComplete() }
        .launchIn(scope)
        .freeze()
}

This is similar to the structure of SuspendWrapper, except that it wraps a Flow instead of a suspend function. An important but subtle detail is that the catch{} call must come before onCompletion{}, or else the RxSwift stream will end before the error is emitted.

iOS Repository Wrapper

With these function-level wrappers in place, we'll add an iOS wrapper around our ThingRepository that makes use of them:

class ThingRepositoryIos(private val repository: ThingRepository) {
    val scope: CoroutineScope = object : CoroutineScope {
        override val coroutineContext: CoroutineContext
            get() = SupervisorJob() + Dispatchers.Default
    }

    init {
        freeze()
    }

    fun getThingWrapper(succeed: Boolean) = 
        SuspendWrapper { repository.getThing(succeed) }
    fun getThingStreamWrapper(count: Int, succeed: Boolean) =
        FlowWrapper(repository.getThingStream(count, succeed))
}

This piece is the unfortunate boilerplate we need in this scheme. While most of the other bridge code just has to be written once, each repository method must be explicitly wrapped into something visible from Swift, and we wrap the entire repository so we have a place to put them. At scale it would probably be preferable to codegen some version of this, but for something small it's pretty straightforward to write by hand.

Note that we freeze this class to ensure it can safely be touched from a background thread, since it likely will be.

We also declare a scope here. This will be passed as a parameter to the subscribe() calls on SuspendWrapper and FlowWrapper. In this example it's using Dispatchers.Default, which requires using the multithreaded coroutines branch.

Connecting Wrappers to Rx

Armed with our iOS-compatible repository, it's time to move over into Swift. My natural inclination as a Kotlin developer is to add extension functions to SuspendWrapper and FlowWrapper which connect the relevant Rx piping to the callback lambdas inside the subscribe() function. Unfortunately, the following declaration isn't valid here:

extension SuspendWrapper {
    func toSingle() -> Single<T> {
        ...
    }
}

This leads to an error stating Extension of a generic Objective-C class cannot access the class's generic parameters at runtime. I don't have a deep understanding here, but essentially due to the different generic models between Swift and Objective-C, the generic parameter on SuspendWrapper is erased at runtime and so the extension can't be resolved. Luckily, we can still define top-level functions:

func createSingle<T>(
    scope: Kotlinx_coroutines_coreCoroutineScope,
    suspendWrapper: SuspendWrapper<T>
) -> Single<T> {
    return Single<T>.create { single in
        let job: Kotlinx_coroutines_coreJob = suspendWrapper.subscribe(
            scope: scope,
            onSuccess: { item in single(.success(item)) },
            onThrow: { error in single(.error(KotlinError(error))) }
        )
        return Disposables.create { job.cancel(cause: nil) }
    }
}

func createObservable<T>(
    scope: Kotlinx_coroutines_coreCoroutineScope,
    flowWrapper: FlowWrapper<T>
) -> Observable<T> {
    return Observable<T>.create { observer in
        let job: Kotlinx_coroutines_coreJob = flowWrapper.subscribe(
            scope: scope,
            onEach: { item in observer.on(.next(item)) },
            onComplete: { observer.on(.completed) },
            onThrow: { error in observer.on(.error(KotlinError(error))) }
        )
        return Disposables.create { job.cancel(cause: nil) }
    }
}

These functions take in a CoroutineScope and a SuspendWrapper or FlowWrapper, and create the associated Rx type Single or Observable. Rx events get forwarded to the callback lambdas that the wrappers defined, and the Rx disposable is linked to the coroutine Job so that cancellation on the Rx side shuts down the coroutine as well.

By the way, a note on errors

You might note the KotlinError class referenced here. This is a simple wrapper to pass Kotlin exceptions into the Rx error stream, and forward the error message.

class KotlinError: LocalizedError {
    let throwable: KotlinThrowable
    init(_ throwable: KotlinThrowable) {
        self.throwable = throwable
    }
    var errorDescription: String? {
        get { throwable.message }
    }
}

This lets us read out the Kotlin error message from Swift by reading the localizedDescription field on the error, without needing to check its type. This helps avoid extra Kotlin-specific error-handling in Swift.

Usage From Elsewhere in iOS App

The rest of the Swift code can now talk to these observables, like so:

let disposable = createObservable(
    scope: repository.scope,
    flowWrapper: repository.getThingStreamWrapper(count: 3, succeed: true)
).subscribe(
    onNext: { thing in NSLog("next: \(thing)") },
    onError: { error in NSLog("error: \(error.localizedDescription)") },
    onCompleted: { NSLog("complete") },
    onDisposed: { NSLog("disposed") }
)

This will print

next: Thing(count=0)
next: Thing(count=1)
next: Thing(count=2)
complete!
disposed!

So there you have it: type-safe and thread-safe communication from Swift with coroutine APIs defined in our shared Kotlin, via RxSwift.

Next Steps

I didn't emphasize it very heavily above, but only the Swift side of this setup has any knowledge of RxSwift. So if you want to do something similar with some other reactive API (I hear Combine is interesting), you could probably do so without needing to change anything on the Kotlin side.

If you'd like to explore further, you can find the code at the following repo:

touchlab / SwiftCoroutines

Note: The repository has since been updated for the sequel to this blog post, but you can find the state of the code when this post was originally written in the v1 branch

This includes a few extensions on what was presented here:

Both nullable and nonnull versions of all Kotlin wrapper types and Swift wrapper functions
Swift unit tests to verify everything is working
An extra jobCallback parameter in wrapSingle() and its siblings so that the Swift tests can pull the internally-created Job out and verify it gets cancelled when expected.

Hopefully this tour of RxSwift and Coroutines interop was interesting and helpful to you. And if you'd like to go deeper, you can always reach out to Touchlab!

Multiplatform Settings version 0.6 is out!

Russell Wolf — Sun, 26 Apr 2020 20:03:33 +0000

Today I’ve released version 0.6 of Multiplatform Settings! I thought I’d write a few words about what’s been added and what’s still to come.

Windows

One major new feature is a Windows implementation which stores data in the registry. For that I’m thankful for the initial contribution from Andrew Mikhaylov, without which I wouldn’t have known how any of the Windows APIs work. It currently doesn’t implement the listener APIs in ObservableSettings, but it should be possible to get something working in the future, using something like RegNotifyChangeKeyValue. Contributions welcome. If you do native Windows work, let me know if it meets your needs.

no-arg

Another new feature is a new module called multiplatform-settings-no-arg. This is in response to a longstanding friction I’ve heard of from some users, where configuration can seem too complicated. I’ve generally focused the design of Multiplatform Settings around platform interop, with the expectation that you probably have some existing key-value storage that you want to use from both your shared and platform-specific code. But if that doesn’t matter for your use-case, needing to configure things separately from each platform can be frustrating. So the no-arg module lets you call Settings() from common code. Note that this is not currently implemented on Windows, but it is available for other existing platforms. More details in the readme

`keys` and `size` APIs

A minor update is the addition of size and keys APIs, which have been a longstanding to-do item of mine. I held off for a while because they behave unintuitively on Apple platforms, where after a clear() call some keys are still present. However, after realizing that this might already be confusing for the hasKey() API that already exists, I decided that it wasn’t a reason to keep them out of the library.

Listener updates

Finally, this release brings better thread-safety for update listeners on Apple platforms. This is something I’ve been wanting to get back and improve for a long time, and is the biggest reason the listeners are still marked experimental. To avoid forcing all listeners to freeze, there’s a flag you can pass to AppleSettings on creation. If useFrozenListeners is false, you get the pre-existing behavior, where nothing gets frozen but you’ll get freeze exceptions if you update from a background thread and trigger a callback. If useFrozenListeners is true, it is safe to update things from arbitrary threads, but the listener lambda will be frozen, so you must be sure not to accidentally capture mutable state. Try it out and let me know how it works for you! Thanks to Kevin Galligan for feedback on an early draft of the code.

A couple things I’ve had on the to-do list are still in-progress. I’ve done some prototyping of integrations with both kotlinx.coroutines and kotlinx.serialization. The coroutine branch I’ve chosen to hold off on for a little while longer to do some thinking about how to handle threading, but the pull-request is available if you’d like to manually add it to your own code. The serialization integration needs more work in order to avoid calling into internal APIs, and is missing some functionality like collections. I’ve also been doing some prototyping of a desktop Linux implementation using DBM-style APIs. I haven’t been able to get it working yet, but I’d also love to get some feedback on whether that’s actually a useful direction to go in for interop purposes, or if there’s something else better to use.

Full changelog of 0.6 is available here, and you can download it now on jcenter().

Also, as a bonus, I've also published version 0.6-1.4-M1. This is the same as 0.6, but built against the Kotlin 1.4-M1 preview release. Check it out if you like living in the future.

Happy Kotlin!

Kotlin 1.3.70 Reactions

Russell Wolf — Thu, 05 Mar 2020 18:11:44 +0000

Kotlin 1.3.70 is here! As the release blog post says, there’s not much in the way of major landmark new features, but lots of incremental improvements and some interesting little quality-of-life stuff which I’m excited about. It's the first new language version since KotlinConf so it's cool to see some of the things JetBrains has been working on since then, even if a lot of the big-ticket stuff won't come until 1.4.

Before we jump in, a quick reminder for Multiplatform users: Since Kotlin/Native is still in Beta, binaries are not compatible across versions. This means that you shouldn't update your Multiplatform projects until all of your library dependencies have Kotlin 1.3.70-compatible versions. If you're a KaMPKit user, you can follow this issue to see when the libraries we use in that template are ready.

Here's a couple of items in the blog post I thought were noteworthy.

Renaming of experimental annotations

I've been using @Experimental and @UseExperimental for over a year now in Multiplatform Settings, and find it to be a really nice way for libraries to mark more volatile APIs. Simply create an annotation class MyExperimentalApi and annotate it with @Experimental, and then consumers of anything marked @MyExperimentalApi will have to explicitly opt-in to their dependence on experimental behavior.

But I've also noticed some usage in the wild (including in JetBrains' own libraries) where it was more about marking internal APIs they didn't want other people depending on, rather than just APIs that might be unstable. So I'm not surprised that they're renaming these to @RequiresOptIn and @OptIn to broaden the usage.

A side note here since I've seen people miss this: A @RequiresOptIn annotation deliberately leaks to callers so that they're forced to opt-in as well. If you don't want to do that (for instance, because the experimental usage is just an internal implementation detail), you should use @OptIn(MyExperimentalApi::class) instead so you only need to annotate at the direct use-site. You can also pass opt-ins at the command-line or gradle level that apply application-wide.

Double-ended queue implementation: ArrayDeque

This is a neat one which I hadn't been tracking the development of. ArrayDeque is a common default implementation for a Queue or a Stack on the JVM, but no such standard implementation existed on other platforms previously. That will be a welcome addition to people in need of these data structures in common code.

The fact that it's a new implementation even on the JVM rather than delegating to the Java one is interesting, and atypical for Kotlin. I guess the benefit is that it allows them to improve the API some, by allowing it to be treated as a List which isn't possible for the Java implementation. On the other hand it makes it less useful for Java interop. Interestingly, they have not actually added Queue and Stack interfaces to kotlin.collections, so for example you'd get stack behavior by calling addFirst() and removeFirst() rather than push() and pop(). I'll be curious to see if these differences from Java have impact on how people use Kotlin's ArrayDeque.

IntelliJ IDEA support

Now, the completion suggestions include functions declared in objects, including extension functions, object-level overrides, and even functions declared in nested objects.

It's nice to see support improving here for this longstanding issue. The pattern of declaring extension functions in objects looks weird at first and doesn't feel all that idiomatic, but when combined with things like the @JvmStatic annotation it's very helpful for maintaining clean interfaces for Java consumers. That means that libraries like KotlinPoet and OkHttp make heavy use of it, and so it's been a pain point that imports often need to be manually added from Kotlin.

Test results for Kotlin/JS and Kotlin/Native are now displayed right in the IntelliJ IDEA, as it has always been for Kotlin/JVM tests.

I am already super pleased about this.
// Detect dark theme var iframe = document.getElementById('tweet-1235041249020858370-825'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1235041249020858370&theme=dark" }

Also, it's not called out in the blog, but a related improvement here is that the iosX64Test gradle task (and the equivalent for other simulator targets) is built-in now, so we no longer have to define it manually. I've lost count of how many times I've copy/pasted that gradle snippet.

New inspection on pointless unary operators.

This is a subtle gotcha that's good to have some tooling help for. If you're not careful when splitting up a long math expression, you might end up with code like this

val a = 2 + 3
    + 4

The compiler will see this as two lines, so a will have the value 5, and not 9 as you might expect. It's a subtle consequence of a language without semicolons, since the parser has to infer where one expression ends and the next begins. Glad we'll have an inspection calling it out, but I'd also love to see a quick-fix to convert it to the form you probably meant:

val a = 2 + 3 +
    4

When the plus sign is at the end of the line, the compiler realizes that the 4 on the next line is part of the same expression and so a would be 9 as expected.

Kotlin/JS

With Kotlin 1.3.70, we have made some long-awaited changes to the documentation and tutorials for the JavaScript target which hopefully makes it easier for people to get started with Kotlin/JS.

Been waiting on this one a while too. There were major updates to the JS gradle plugin API in 1.3.40 but updated documentation has been slow to arrive. Good to have it here now.

Kotlin/Native

Support for multiple Kotlin frameworks in a single application

People have been asking for this for a while. There are some limitations to how multiple-framework applications will work, because each framework will have its own versions of the Kotlin standard library and any other common dependencies. However it should make the iOS developer experience more natural in some cases, especially in large multimodule projects.

Lastly, I thought I’d mention one thing we didn’t see. Incremental experimental support has been increasing over the last few releases for “Hierarchical Multiplatform Projects” (HMPP). This is a new internal model used by the gradle plugin and the IDE to infer things about intermediate shared sources, which differ from traditional common sources in that they can access platform-specific APIs which exist in all platforms the source-set compiles to. An example is accessing iOS APIs from code that is shared between iosArm64 (for iOS devices) and iosX64 (for the iOS simulator). I was hoping to see some details about this in the 1.3.70 announcement, but I guess it’s not quite ready yet. (Hopefully, the bug I encountered right before the release didn’t throw too big a wrench in their plans). Looking forward to seeing what HMPP looks like in Kotlin 1.4 and beyond.

Cover image credit: JetBrains

Thanks to Justin Mancinelli, Sam Hill, Kevin Galligan, Erik Zambrano, Kevin Schildhorn, and Jeff Namnum for providing feedback on drafts of this post.

DEV Community: Russell Wolf

Multiplatform Settings 1.0.0

russhwolf / multiplatform-settings

A Kotlin Multiplatform library for saving simple key-value data

Multiplatform Settings

Table of contents

Usage

Implementation Summary

Some History

What's next?

What about DataStore?

Thanks for reading

Looking toward Multiplatform Settings 1.0.0

russhwolf / multiplatform-settings

A Kotlin Multiplatform library for saving simple key-value data

Multiplatform Settings

Table of contents

Usage

Implementation Summary

Breaking Changes

Implementation class renames

Update listener changes

Default values

Removing multiplatform-settings-coroutines-native-mt

Removing experimental markers

The road ahead

Coroutines integration

Serialization integration

Apple Keychain integration

Windows implementation

Linux implementation

What's next for 1.0?

Trying out the experimental new Kotlin/Native memory model

TL,DR

Wait, what?!

Testing the two models

Coroutines

Further thoughts

Caveats

Should I use this in production?

Kotlin Coroutines and Swift, revisited

Kotlin updates

Swift repository wrappers

Combine

SwiftUI

Isn't this a lot of boilerplate?

Final thoughts

touchlab / SwiftCoroutines

Multiplatform Settings version 0.7 is out!

TL;DR links

Serialization

Coroutines

Datastore

Keychain

Other little things

Typed listeners

Sample updates

Desktop Linux

Working with Kotlin Coroutines and RxSwift

Common Repository

Suspend and Flow wrappers

iOS Repository Wrapper

Connecting Wrappers to Rx

By the way, a note on errors

Usage From Elsewhere in iOS App

Next Steps

touchlab / SwiftCoroutines

Multiplatform Settings version 0.6 is out!

Windows

no-arg

keys and size APIs

Listener updates

Kotlin 1.3.70 Reactions

Renaming of experimental annotations

Double-ended queue implementation: ArrayDeque

IntelliJ IDEA support

Kotlin/JS

Kotlin/Native

Removing `multiplatform-settings-coroutines-native-mt`

`keys` and `size` APIs