Using Swift's new async/await when invoking Kotlin Multiplatform code

One of the biggest, and probably most anticipated, announcement at WWDC last week was regarding Swift 5.5’s new concurrency features and, in particular, its new async/await mechanism. This would appear to work in a way that’s very similar to Kotlin Coroutines which should I believe make Swift based async development significantly more approachable for Kotlin developers but also might provide option to allow a more seamless integration between Swift code and Kotlin suspend functions exposed from KMM shared code. This post is primarily aimed right now at capturing notes around exploration of using async/await mechanism to wrap/invoke calls to shared Kotlin code and also to look at what would be involved in potentially propagating cancellations in Swift async code to underlying Kotlin Coroutines. Have more questions than answers right now but hopefully that will change and will update this post if/when it does. (Update: see note at end of post).

Using Realm persistence library in a Kotlin Multiplatform project

It’s always great to see the Kotlin Multiplatform (KMP) library ecosystem continuing to grow and a relatively new addition to that is Realm which describes itself as “a mobile database that runs directly inside phones, tablets or wearables.” and “a replacement for SQLite & ORMs”. An added positive is fact that it’s another example of existence now of multiple different KMP libraries addressing particular functionality…with for example SQLDelight, Kodein-DB, and, somewhat indirectly, Apollo GraphQL libraries providing persistence capabilities (previous articles here have described integrating those). Realm KMP library is in developer preview right now, and is still undergoing active development, but I thought it would be interesting to explore adding it as persistence layer for a KMP sample, FantasyPremierLeague, that I created recently (note that the changes shown here have been pushed to the realm branch of that repo).

Creating SwiftUI Multiplatform project (iOS and macOS) that consumes shared Kotlin Multiplatform non-UI code!

Right now how you understand the word “Multiplatform” probably depends on whether you’re a Swift/SwiftUI developer or a Kotlin one! At a high level:

• SwiftUI Multiplatform is a relatively new capability that allows developing client UIs that target iOS and macOS (and potentially also watchOS and tvOS) using a single code base.
• Kotlin Multiplatform on the other hand is aimed at providing mechanism to share non UI code across a wide range of platforms.

Using Swift Packages in a Kotlin Multiplatform project

When using Kotlin Multiplatform, the Kotlin/Native compiler produces a framework for iOS/macOS corresponding to the shared code module (am assuming single module for purposes of this discussion). A number of different approaches are used then to ensure that the XCode project is wired up to use that framework and that it is regenerated whenever an XCode build takes place after the shared code has been updated. These are typically based on use of CocoaPods plugin or custom gradle packForXCode() type task that’s executed from an XCode run script. What’s common in these approaches is that a say iOS developer needs to have access to the shared Kotlin code and a setup to allow building the framework. Generally this is seen as being the preferred way of working (allowing all developers to update and build the shared code as needed). However there are cases where it does make sense for the shared code to be consumed in XCode as a prebuilt binary and one option for that is to publish/consume the code as a Swift Package. In this article I’m going to outline how this was done for PeopleInSpace project using the Multiplatform Swift Package Gradle plugin.

Wrapping Kotlin Flow with Swift Combine Publisher in a Kotlin Multiplatform project

One area of “friction”, when developing an iOS client that uses Kotlin Multiplatform code, is the consumption of APIs from shared code that expose a Kotlin Flow. This has typically required providing APIs for starting to collect the flow (and passing data back to iOS client through provided closure/lambda) and then for cancelling the flow (through associated job). A related question then is how this process can be integrated in to particular reactive frameworks being used on iOS. One example of such a framework is RxSwift and Russell Wolf wrote an article (and published associated code ) last year that described how to manage process of integrating with that framework. I had started to use Swift’s Combine framework in a number of projects and this article describes exploration to use Russell’s approach with that.

Jetpack Compose and GraphQL, a very merry combination!

There are a number of ways in which Android and iOS development is “converging” at the moment but I think the most exciting area is the adoption of Declarative UI frameworks on both platforms -SwiftUI on iOS and Jetpack Compose on Android. As such, my interest is always piqued, when I see tweets like following from Thomas Ricouard, by what would be involved in creating a Jetpack Compose version of a project like this. An added interest in this case is the use of GraphQL and also saw this as an opportunity to try out the Apollo GraphQL library (and, for bonus points, it’s Kotlin Multiplatform support!). The code shown here is included as part of MortyComposeKMM project on Github.

Comparing use of LiveData and StateFlow in a Jetpack Compose project

I recently updated PeopleInSpace project to make use of Kotlin Flow in shared multiplatform code to poll for the position of the International Space Station (ISS). As part of that work I had initially updated PeopleInSpaceViewModel in the Android app to use StateFlow (along with stateIn()) instead of LiveData. However there were some lifecycle implications of this change when used alongside Jetpack Compose that have caused me to revert, for now, to using LiveData. This article is intended to capture results of that comparison. Note that this is based on Jetpack Compose 1.0.0-alpha07.

Jetpack Compose for the Desktop!

There have been indications in recent times of changes being made that would allow use of Jetpack Compose to develop UI for desktop apps. That became closer to reality today when it was noticed that EAP version of IntelliJ IDE has option now to create projects that target use of Compose on desktop JVM platforms (Windows, Linux, macOS). In this article I’m going to outline initial exploration of using this capability in PeopleInSpace repo. Changes made are included in this branch.

Exploring use of StateFlow in a Kotlin Multiplatform project

Kotlinx Coroutines recently introduced the StateFlow API, described as “A Flow that represents a read-only state with a single updatable data value that emits updates to the value to its collectors”. This is generally seen as a replacement for LiveData on Android but also, importantly, something that can be used in shared Kotlin Multiplatform code.

Using Kodein-DB NoSQL database in a Kotlin Multiplatform project

A big factor in the increasing adoption of Kotlin Multiplatform is the ever growing number of KMP libraries that are becoming available. A new addition to this list, albeit in beta right now, is Kodein-DB, described as an “embedded NoSQL indexed document database for Android, iOS, and client JVM”. In this post I’m going to describe what was involved in adding initial use of Kodein-DB to BikeShare project.

Using Google Maps in a Jetpack Compose app

I’m in process of migrating Galway Bus over to use Jetpack Compose and one particular requirement is the ability to show bus stops (and also bus positions) on a Google Map. It seems like this is something that ultimately will exist as specific Jetpack Compose @Composable but for now it looks like only way to add a map like this is using AndroidView.

Using Koin in a Kotlin Multiplatform Project

The options for adding dependency injection to a Kotlin Multiplatform project have up to now been pretty limited and if, like me, you’ve been using Koin for your Android projects then you’ll have been excited to see following announcement earlier today!

PeopleInSpace hits the web with Kotlin/JS and React

Next up on our Kotlin Multiplatform journey I thought it would be interesting to look at bringing PeopleInSpace to the web….using Kotlin/JS and making use of same Kotlin shared code that we’ve used on other platforms. In line with project in general we’re going to make the minimum changes needed to support this (these posts are primarily aimed at (a) giving people a “flavor” of what’s possible, and (b) providing minimal setup needed to get someone up and running using particular technology). Note also that this is heavily inspired by this excellent Kotlin/JS codelab.

Kotlin Multiplatform running on macOS

Most of the focus of Kotlin Multiplatform has, understandably, been on targeting the development of apps that run on Android and iOS. However, other platforms are supported so when I saw following announcement of SQLDelight’s support for macOS I was curious to see what would be involved in developing a basic app on that platform that uses same shared Kotlin code used in PeopleInSpace (A little bit more background on initial effort working with Android and iOS in following post Minimal Kotlin Multiplatform project using Compose and SwiftUI)

Adding some Storage (to) Space

So, in previous post (Minimal Kotlin Multiplatform project using Compose and SwiftUI) I gave brief overview of PeopleInSpace, a small repository that was designed to illustrate key moving parts of a Kotlin Multiplatform project (running on Android, iOS, and later, watchOS). However, although I’m reluctant to add much else to the project, one key gap was around locally persisting the data we got back from remote server. The somewhat serendipitous combination of following activities in last few weeks also provided further encouragement to add such functionality to the project (1) Neal’s addition of watchOS support to PeopleInSpace, and (2) watchOS support was added to SQLDelight (Kotlin Multiplatform persistence library).

Minimal Kotlin Multiplatform project using Compose and SwiftUI

In previous posts I’ve used GalwayBus repo to illustrate results of various explorations I’ve done in to the use of Kotlin Multiplatform. However I thought there’d be value in creating a more minimal project that would allow clearer illustration of key moving parts of a multiplatform project and thus PeopleInSpace was created. It also provided opportunity to try out use of Jetpack Compose for the Android app (with UI being developed on iOS using SwiftUI - using pretty much same approach outlined in SwiftUI meets Kotlin Multiplatform!).

Exploring SQLDelight Flow support

In Introduction to Multiplatform Persistence with SQLDelight it was mentioned that we still needed way to “manage observing of data updates (some interesting work being done on extension that supports Kotlin Coroutines Flow)”. Well, not long after that SQLDelight 1.1.4 was released with the aforementioned Flow support and this post gives short overview of exploration done to start using it.

Introduction to Multiplatform Persistence with SQLDelight

Most mobile apps store data locally on the device. This could just be some local settings/preferences but frequently also includes caching of data returned from queries to back end services. For at least the latter case that data is typically stored in an SQLite database (and, importantly, SQLite is used on both iOS and Android). There are low level libraries available to access SQLite database but this is normally achieved using libraries that provide a higher level abstraction….these typically being Core Data on iOS and, at least more recently, Room Persistence Library on Android.

SwiftUI meets Kotlin Multiplatform!

Announced at WWDC last week, SwiftUI is a new declarative UI framework that is described as an “innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift.”. This approach to UI development has been popularised recently with emergence of Flutter, something that was also likely the inspiration for Jetpack Compose which was announced at Google I/O a few weeks back (SwiftUI appears to be at a significantly more advanced state of maturity than Jetpack Compose and is available to try out in Xcode 11 beta…but also important to note that it does require iOS 13).