Forem: Evgeny Khokhlov

Measuring and minimizing latency in a Kafka Sink Connector

Evgeny Khokhlov — Wed, 17 Jul 2024 07:51:44 +0000

Kafka is often chosen as a solution for realtime data streaming because it is highly scalable, fault-tolerant, and can operate with low latency even under high load. This has made it popular for companies in the fan engagement space who need to transmit transactional with low latency (e.g. betting) to ensure that actions and responses happen quickly, maintaining the fluidity and immediacy of the experience. One of the easiest ways for companies to deliver data from Kafka to client devices is by using a Connector.

Kafka Connectors act as a bridge between event-driven and non-event-driven technologies and enable the streaming of data between systems - with ‘Sink Connectors’ taking on the responsibility of streaming data from topics in the Kafka Cluster to external systems. Connectors operate within Kafka Connect, which is a tool designed for the scalable and reliable streaming of data between Apache Kafka and other data systems.

Unfortunately, traditional approaches to scaling Kafka Connectors and managing extensive loads often prioritize throughput over latency. Considering the distributed nature of Kafka Connect, and a Connector’s dependency on external services, it’s a challenge to optimize end-to-end latency whilst maximizing throughput.

This means that where Kafka has been chosen for its low latency, benefits can be lost when Connectors are introduced. This is particularly problematic in fan engagement applications, and those using transactional data, because latency is critical to their success.

Solving for low latency with the Ably Kafka Connector

Having worked with businesses like NASCAR, Genius Sports, and Tennis Australia, the engineering teams at Ably understand the importance of low latency. So, to support companies looking to stream data between Kafka and end-user devices Ably developed its own Kafka Connector.

Recently, we conducted research to determine the optimal configuration for achieving minimal latency for a Kafka Connector, specifically under a moderate load scenario of between 1,000 and 2,500 messages per second. Let’s look at how we achieved this, and took on the challenge of measuring latency and finding bottlenecks.

Measuring latency and finding bottlenecks

Balancing latency and throughput is a complex task, as improving one often means sacrificing the other. The distributed nature of Kafka Connect and Connector’s dependency on external services make it challenging to understand the impact of your optimizations on end-to-end latency.
To address these challenges, we adopted a comprehensive approach using distributed tracing. Distributed tracing provides a detailed view of a request's journey through various services and components. This end-to-end visibility helps identify where latency is introduced and which components are contributing the most to the overall processing time.
We decided to use OpenTelemetry for distributed tracing. OpenTelemetry is an open-source observability framework that supports over 40 different observability and monitoring tools. It integrates smoothly with various languages and frameworks, both on the frontend and backend, making it an ideal choice for gaining visibility into the end-to-end flow of messages in our Kafka Connect environment.

How did we trace messages inside the Kafka Connector?

1. Instrumenting the load-testing tool

We began by patching our load-testing tool to include OpenTelemetry context in Kafka message headers. This modification allowed us to embed tracing information directly into each message, ensuring that the trace context was carried along with the message throughout its lifecycle.

Distributed tracing relies on context to correlate signals between different services. This context contains information that allows the sending and receiving services to associate one signal with another.

2. Enhancing the Kafka Connector

Next, we patched the Kafka connector to extract the OpenTelemetry context from the message headers. The connector was modified to send traces at key points: when a message was queued and when it was published. By instrumenting these stages, we could monitor and measure the time spent within the Kafka connector itself.

3. Measuring end-to-end latency

Finally, we extended our client application, which listens to the final Ably messages, to include tracing. By doing so, we could capture the complete end-to-end latency from the moment a message was produced until it was consumed. This comprehensive tracing setup allowed us to pinpoint latency bottlenecks and understand the impact of various optimizations on the overall performance.

4. Visualization

To visualize the telemetry data, we used Amazon CloudWatch, which integrates seamlessly with OpenTelemetry. This integration allowed us to collect, visualize, and analyze the traces and metrics with ease:

Although we couldn't find an existing OpenTelemetry library to inject and extract context directly into and from Kafka messages, it was easy to implement this functionality ourselves. We achieved this by implementing simple TextMapGetter and TextMapSetter interfaces in Java. This custom implementation allowed us to embed and retrieve the tracing context within the Kafka message headers, ensuring that the trace information was properly propagated through our system:

// Implement TextMapGetter to extract telemetry context from Kafka message 
// headers 

public static final TextMapGetter<SinkRecord> textMapGetter = 
    new TextMapGetter<>() { 
    @Override 
    public String get(SinkRecord carrier, String key) { 
        Header header = carrier.headers().lastWithName(key); 
        if (header == null) { 
            return null; } 
        return String.valueOf(header.value()); 
    } 
    @Override 
    public Iterable<String> keys(SinkRecord carrier) { 
        return StreamSupport.stream(carrier.headers().spliterator(), false) 
            .map(Header::key) 
            .collect(Collectors.toList()); 
    } 
}; 
 // Implement TextMapSetter to inject telemetry context into Kafka message 
// headers 

public static final TextMapSetter<SinkRecord> textMapSetter = 
    new TextMapSetter<>() { 
    @Override 
    public void set(SinkRecord record, String key, String value) {
        record.headers().remove(key).addString(key, value); 
    } 
};

Fine-tuning with built-in Kafka Connector configuration

With distributed tracing up and running, we were then ready to explore various methods to improve latency in Kafka Connectors.

Partitioning

One of the initial approaches we considered for reducing latency in Kafka was to increase the number of partitions. A topic partition is a fundamental unit of parallelism in Kafka. By distributing the load more evenly across multiple partitions, we anticipated that we could significantly reduce message processing times, leading to lower overall latency. However, during our research, we found out that our clients are not always able to increase the number of partitions due to their application logic constraints. Given these limitations, we decided to shift our focus to other optimization options.

Number of tasks

After deciding against increasing the number of partitions, we next focused on optimizing the tasks.max option in our Kafka Connector configuration. The tasks.max setting controls the maximum number of tasks that the connector can run concurrently. The tasks are essentially consumer threads that receive partitions to read from. Our hypothesis was that adjusting this parameter could help us achieve lower latency by running several tasks concurrently.

During our tests, we varied the tasks.max value and monitored the resulting latency. Interestingly, we found that the lowest latency was consistently achieved when using a single task. Running multiple tasks did not significantly improve, and in some cases even increased, the latency due to the overhead of managing concurrent processes and potential contention for resources. This outcome suggested that the process of sending data into the Ably was the primary factor influencing latency.

Message converters

In our pursuit of reducing latency, we decided to avoid using complicated converters with schema validation. While these converters ensure data consistency and integrity, they introduce significant overhead due to serialization and deserialization. Instead, we opted for the built-in string converter, which transfers data as text.

By using the string converter, we sent messages in JSON format directly to Ably. This approach proved to be highly efficient, since Ably natively supports JSON, and that minimized the overhead associated with serialization and deserialization.

Improving latency with Ably Connector solutions

After thoroughly exploring built-in Kafka Connector configurations to reduce latency, we turned our attention to optimizing the Kafka Connector itself. First we focused on the internal batching mechanism of the Ably Kafka Connector. Our goal was to reduce the number of requests sent to Ably, thereby improving performance.

Experimenting with batching intervals

We conducted experiments with different batching intervals, ranging from 0ms (no batching) to 100ms, using the batchExecutionMaxBufferSizeMs option. The objective was to find an optimal batching interval that could potentially reduce the request frequency without adversely affecting latency.

Our tests revealed that even small batching intervals, such as 20ms, increased latency in both the p50 and p99 percentiles across our scenarios. Specifically, we observed that:

0ms (no batching): This configuration yielded the lowest latency, as messages were sent individually without any delay.
20ms batching: Despite the minimal delay, there was a noticeable increase in latency, which impacted both the median (p50) and the higher percentile (p99) latencies.
100ms batching: The latency continued to increase significantly, reinforcing that batching was not beneficial for our use case.

These results indicated that for our specific requirements and testing scenarios, avoiding batching altogether was the most effective approach to maintaining low latency. By sending messages immediately without batching, we minimized the delay introduced by waiting for additional messages to accumulate.

Internal Connector parallelism

Next, we examined the internal thread pool of the Ably Kafka Connector. We observed that messages were often blocked, waiting for previous messages or batches to be sent to Ably. The Ably Kafka Connector has a special option to control thread pool size called batchExecutionThreadPoolSize. To address this, we dramatically increased the number of threads from 1 to 1,000 in our tests. This change significantly decreased latency, since it allowed more messages to be processed in parallel.

Trade-offs and challenges

However, this approach came with a trade-off: we could no longer guarantee message ordering when publish requests to Ably were executed in parallel. At Ably, we recognize the critical importance of maintaining message order in realtime data processing. (Many applications rely on messages being processed in the correct sequence to function properly. Therefore, though it would increase latency, batchExecutionThreadPoolSize can be set to 1 to guarantee message ordering if absolutely required.)

Future directions

Looking ahead, our focus is on developing solutions that increase parallelism without disrupting message order. We understand that maintaining the correct sequence of messages is crucial for various applications. We are actively exploring several strategies to overcome this limitation and will share our findings soon.

How our Ably Kafka Connector insights apply elsewhere

The insights and optimizations we explored are not limited to the Ably Kafka Connector; they can be applied broadly to any Kafka Connector to improve performance and reduce latency. Here are some general principles and strategies that can be universally beneficial:

Understanding and optimizing built-in Kafka configuration

1. Partitions and tasks management:

Partitions: Carefully consider the number of partitions. While increasing partitions can enhance parallel processing, it can also introduce complexity and overhead.
Tasks: Adjusting the tasks.max setting can help balance concurrency and resource utilization. Our research showed that using a single task minimized latency in our scenario, but this might vary depending on the specific use case.

2. Simple converters: Using simpler converters, such as the built-in String converter, can reduce the overhead associated with serialization and deserialization. This approach is particularly effective when the data format, like JSON, is natively supported by the target system.

Optimizing connector-specific settings

1. Batching mechanisms: While batching can reduce the number of requests sent to external systems, our findings indicate that even small batching intervals can increase latency. Evaluate the impact of batching on latency and throughput carefully.

2. Thread pool configuration: Increasing the number of threads in the connector’s internal thread pool can significantly reduce latency by allowing more messages to be processed in parallel. However, be mindful of the trade-offs, such as potential issues with message ordering.

Although these settings are specific to the Ably Kafka Connector, similar options often exist in other Kafka Sink Connectors. Adjusting batch sizes, thread pools, and other configuration parameters can be effective ways to optimize performance.

Conclusion

Based on our experiments with the Ably Kafka Connector, we have achieved remarkable processing latency metrics. With a moderate load of approximately 2,400 messages per second, the connector demonstrated a median (p50) processing latency of under 1.5 milliseconds and a 99th percentile (p99) latency of approximately 10 milliseconds. These figures specifically represent the processing time within the connector, from the moment a message is received to its publication to the Ably service.

Going Swiftly: Using a Swift-only libraries in your Kotlin Multiplatform App

Evgeny Khokhlov — Sun, 19 Mar 2023 19:10:53 +0000

This article demonstrates how to use the Apple CryptoKit in KMM shared module. You'll learn how to create a Kotlin-compatible wrapper in Swift, build it using Swift Klib Gradle Plugin, and provide bindings in KMM shared module through Kotlin/Native cinterop.

By using this technique, developers can access cryptographic algorithms (such as SHA, MD5, AES, ChaChaPoly, and more) in Kotlin Multiplatform without needing to rely on additional libraries. This is particularly beneficial since there are currently no widely-used and reliable cryptographic libraries for Kotlin Multiplatform from verified and respected companies.

Kotlin Multiplatform Mobile (KMM) is an SDK designed to simplify the development of cross-platform mobile applications. You can share common code between iOS and Android apps and write platform-specific code only where it's necessary

Kotlin Multiplatform brings a lot of benefits to the project, including increased code reuse, consistent business logic, and faster time-to-market. Additionally, one of its key advantages is the ability to access native APIs for each platform, enabling developers to tap into platform-specific functionality while still maintaining a shared codebase. Unfortunately, this powerful feature has certain limitations for the iOS platform. Kotlin does not have direct interoperability with the Swift language; instead, it relies on interoperability with Objective-C. As a result, there is no built-in support in Kotlin for Swift-only libraries that do not have an Objective-C API. For example, the Apple CryptoKit library cannot be directly accessed from Kotlin. Fortunately, a special Swift Klib Gradle Plugin exists to help overcome this limitation.

In this article, we'll explore how to use this plugin to build a simple Kotlin Multiplatform app that showcases the MD5 hash of a selected file.

The final code of the app can be found in the /examples folder of Swift Klib repository.

Getting Started
Swift Klib
KMM Shared Module
Using In SwiftUI
Resources

Getting Started

To get started, we'll create a Kotlin Multiplatform app using the KMM plugin in Android Studio.

If you run into any issues while creating your Kotlin Multiplatform app, be sure to check out the official KMM tutorial for additional guidance and support.

While this article will focus on the iOS implementation, if you're interested in exploring the Android implementation, you can check out our GitHub repository for more information.

Our first step will be to create a wrapper for the CryptoKit library that provides an Objective-C API for the MD5 hash function:

import CryptoKit
import Foundation

@objc public class KCrypto : NSObject {
    @objc(md5:) public class func md5(data: NSData) -> String {
        let hashed = Insecure.MD5.hash(data: data)
        return hashed.compactMap { String(format: "%02x", $0) }.joined()
    }
}

By utilizing the @objc attribute, we can control which Objective-C API is generated from Swift code and how it will appear in Kotlin. You can find more information about this in the documentation.

It’s important that our class inherited from NSObject and has @objc declarations, that make our Swift code compatible with Objective-C. More about Swift → Objective-C compatibility you can read in the article.

Swift Klib

With the code for our wrapper in hand, we can now proceed to add it to the shared module, which is located in the native/KCrypto directory. Once we've done that, we're ready to set up the Swift Klib Gradle plugin. To add the plugin, simply include it in the plugins section of the shared module's build.gradle.kts file. Here's what the section should look like after adding the plugin:

plugins {
    kotlin("multiplatform")
    id("io.github.ttypic.swiftklib") version "0.2.1"
    //...
}

After adding the Swift Klib plugin, the next step is to add cinterop for the target platforms in the Kotlin Multiplatform Plugin. The good news is that there's no need to configure it or add a .def file, as all the necessary configuration will be handled automatically by the Swift Klib plugin.

kotlin {
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64(),
    ).forEach {
        it.compilations {
            val main by getting {
                cinterops {
                    create("KCrypto")
                }
            }
        }
    }

    //...
}

Next, we need to provide the necessary settings for the Swift Klib plugin in the swiftklib extension. This involves specifying the path and packageName parameters, which will be used by the plugin to generate the necessary bindings.

Here's an example of what the extension configuration might look like:

swiftklib {
    create("KCrypto") {
        path = file("native/KCrypto")
        packageName("com.ttypic.objclibs.kcrypto")
    }
}

In this case, we've specified that the Swift library files are located in the native/KCrypto directory and that the generated package name should be com.ttypic.objclibs.kcrypto. Be sure to adjust these settings to match the specifics of your project.

KMM Shared Module

With the Swift Klib plugin properly configured, we can now access our wrapper for the CryptoKit library in the KMM shared module:

import com.ttypic.objclibs.kcrypto.KCrypto

object FileMd5Hasher {
    fun hash(nsdata: NSData): String {
        return KCrypto.md5(data = nsdata)
    }
}

Now we can use this FileMd5Hasher both in KMM shared module and our iOS app module.

Using in SwiftUI

The final step is to use our FileMd5Hasher to calculate the MD5 hash of a selected file in a SwiftUI app. Here's an example of how we might use FileMd5Hasher to achieve this:

struct ContentView: View {
    @State var fileMd5 = ""
    @State var fileImporterVisible = false

    var body: some View {
        VStack(spacing: 10) {
            if fileMd5 != "" { Text("File's MD5 hash:").font(.title) }
            if fileMd5 != "" { Text(fileMd5) }
            Button(action: {
                fileImporterVisible.toggle()
            }) {
               Text("Choose File")
            }
        }.fileImporter(
             isPresented: $fileImporterVisible,
             allowedContentTypes: [.pdf],
             allowsMultipleSelection: false
         ) { result in
             do {
                 guard let selectedFile: URL = try result.get().first else { return }
                 guard let data = try? Data(contentsOf: selectedFile) else { return }
                 fileMd5 = FileMd5Hasher.shared.hash(nsdata: data)
             } catch {
                 // Handle errors
             }
         }
    }
}

While Kotlin has no direct interoperability with Swift, the Swift Klib Gradle plugin provides a solution for accessing Swift-only APIs in Kotlin Multiplatform shared modules. In this article, we explored how to use the Swift Klib plugin to create a wrapper for the CryptoKit library and calculate the MD5 hash of a selected file in a KMM app.

By following the steps outlined in this article, developers can easily integrate Swift-only APIs into their Kotlin Multiplatform projects, and take full advantage of the unique features and functionality provided by both languages.

Resources

Swift Klib v0.2.0 is out

Evgeny Khokhlov — Sun, 26 Feb 2023 17:07:10 +0000

Swift Klib Gradle Plugin v0.2.0 is released.

ttypic / swift-klib-plugin

Gradle Plugin for injecting Swift code into Kotlin Multiplatform Mobile shared module

Swift Klib Gradle Plugin

This gradle plugin provides easy way to include your Swift source files in your Kotlin Multiplatform Mobile shared module and access them in Kotlin via cinterop for iOS targets. It is useful for:

Accessing Swift-only libraries (e.g. CryptoKit)
Creating a Kotlin-Friendly Swift API
Learning how Swift <-> Kotlin interoperability works

Note: Plugin has been tested on Gradle 7.5+, Xcode 15+

Installation

Using the plugins DSL:

plugins {
    id("io.github.ttypic.swiftklib") version "0.6.4"
}

Using legacy plugin application:

buildscript {
  repositories {
    maven {
      url = uri("https://plugins.gradle.org/m2/")
    }
  }
  dependencies {
    classpath("io.github.ttypic:plugin:0.6.4")
  }
}

apply(plugin = "io.github.ttypic.swiftklib")

Add this to the project-level gradle.properties file (if it’s not already included).

#Kotlin Multiplatform
kotlin.mpp.enableCInteropCommonization=true

Usage

Plugin works together with Kotlin Multiplatform plugin.

Prepare Swift code

Place your Swift…

View on GitHub

This gradle plugin provides easy way to include your Swift source files in your Kotlin Multiplatform Mobile
shared module and access them in Kotlin via cinterop for iOS targets. It is useful for:

Accessing Swift-only libraries (e.g. CryptoKit)
Creating a Kotlin-Friendly Swift API
Learning how Swift <-> Kotlin interoperability works

This release contains:

Fix: add a step to clean old build files in the build directory
Light refactoring of source code

Swift Klib Gradle Plugin is out

Evgeny Khokhlov — Wed, 08 Feb 2023 22:40:02 +0000

I am thrilled to announce the release of new Gradle plugin for Kotlin Multiplatform Mobile development - Swift Klib! It designed to make it easier for you to integrate and manage Swift sources in your KMM shared module. With Swift Klib, you can now easily include your Swift source files in your KMM shared module and access them in Kotlin via cinterop for iOS targets.

Use cases

Although Swift Klib was originally created to access Swift-only Libraries in Kotlin, it is also ideal for several other things. Here are a few:

Learning how Swift <-> Kotlin interoperability works

You can get hands-on experience with the interoperability of Swift and Kotlin. You can start with simple examples, such as the Hello World example in the plugin's repo, and observe how bindings are created in Kotlin. Then you can make changes, add more code, and observe the results.

Accessing Swift-only libraries

There is no direct interoperability between Kotlin and modern Swift libraries without an Objective-C API, such as ActivityKit, CryptoKit, Combine, etc. Swift Klib fills this gap by allowing you to easily create Kotlin-friendly wrappers in Swift and access them in your Kotlin code.

Creating a Kotlin-Friendly Swift API

Kotlin uses Objective-C APIs for libraries, that's why the automatic bindings for iOS libraries can produce an API that may be unfamiliar to those familiar with the Swift API. For example, the Swift UserDefaults.standard translates to NSUserDefaults.standardUserDefaults in Kotlin. With Swift Klib, you can create wrappers for the API you want to use and have full control over it.

I hope you enjoy using Swift Klib and can't wait to see what you'll create with it. If you have any questions or feedback, please don't hesitate to create an issue on GitHub.

Happy coding!

KMM: writing Kotlin API for Swift - 7 things you need to know

Evgeny Khokhlov — Sun, 05 Feb 2023 12:22:23 +0000

This article is true for Kotlin 1.8

Kotlin Multiplatform Mobile (KMM) has been in beta for a while, first stable release is coming, API is safe to use and that's a perfect time to give it a try!

KMM has powerful bidirectional interoperability with Objective-C/Swift (kudos to Kotlin/Native), but it also has some limitations and tricky parts. It's not easy to write Kotlin API for your shared module that works nicely in Swift. I've tried to summarize all the things I've come across so far and learned the hard way. Where applicable I also provided links to documentation to help give you extra context.

Consider `abstract class` instead of `interface` in Kotlin API for Swift

Swift Protocols generated from Kotlin Interfaces don't have methods from kotlin.Any. When you are writing code in Kotlin you are often working with interfaces and implicitly using methods from Any. You can compare instances, print them or for example collect them in HashMap.

This code works pretty well in Kotlin:

interface Vehicle

class Garage {
    private var parkedVehicle: Vehicle? = null

    fun park(vehicle: Vehicle) {
        when (parkedVehicle) {
            null -> {
                parkedVehicle = vehicle
            }
            vehicle -> {
                println("$vehicle already parked")
            }
            else -> {
                println("garage is occupied")
            }
        }
    }
}

But in Swift part this interface Vehicle is translated to protocol Vehicle and can't be treated that way, it doesn't have any kind of equals or hashCode.

class SwiftGarage {
    private var parkedVehicle: Vehicle? = nil

    func park(vehicle: Vehicle) {
        if (parkedVehicle == vehicle) { // Compile error: 'Vehicle' cannot be used as a type conforming to protocol 'Equatable' because 'Equatable' has static requirements
            print("\(vehicle) already parked")
        }
    }
}

Of course you could cast Vehicle to NSObject.

class SwiftGarage {
    private var parkedVehicle: Vehicle? = nil

    func park(vehicle: Vehicle) {
        if (parkedVehicle == nil) {
            parkedVehicle = vehicle
        } else if ((parkedVehicle as! NSObject) == (vehicle as! NSObject)) {
            print("\(vehicle) parked")
        } else {
            print("garage is occupied")
        }
    }
}

It will work, but it doesn't look nice.

On the other hand Kotlin classes: regular and abstract maps methods of kotlin.Any (equals(), hashCode() and toString()) to the methods isEquals:, hash and description in Objective-C, and to the method isEquals(_:) and the properties hash, description in Swift. Also they conform Equatable, Hashable protocols in Swift.

In addition you can extend them to adopt and conform to any new protocol in Swift.

That's why it better to provide abstract class instead of interface where it's possible, when you are creating Kotlin API for shared module.

Don't rely on generics interface in your Kotlin API for Swift

Generics interoperability can only be defined on classes, not on interfaces (protocols in Objective-C and Swift) or methods. So ideally your Kotlin API shouldn't include generic interfaces.

Swift Generic generated from Kotlin Generics has limitations

Kotlin/Native has no direct Kotlin <-> Swift interoperability, it uses Kotlin <-> Objective-C and Objective-C <-> Swift interops to make it works. That's create some limitation.

For example Kotlin and Swift define nullability as part of the type specification, while Objective-C defines nullability on methods and properties.

That's why this class in Kotlin

class Container<T>(private val value: T) {
    fun get(): T = value
}

transforms to

public class Container<T> : KotlinBase where T : AnyObject {
    public init(value: T?)
    open func get() -> T?
}

in Swift.

Fortunately there is an easy trick to make our get function non-nullable. You need to provide non-null type constraint (e.g. kotlin.Any)

class Container<T: Any>(private val value: T) {
    fun get(): T = value
}

now it will translate as expected.

Another interesting thing with generics is that in Swift part they have AnyObject constraint (maybe you've noticed it in previous example).

That means that we can't use Swift struct with them. It also means if we want to initialize our Container class with String or Int we got compiler error

let containerInt = Container(value: 1) // Generic class 'Container' requires that 'Int' be a class type 
let containerString = Container(value: "one") // Generic class 'Container' requires that 'String' be a class type

There is a solution for this too. You need to cast Swift values to Objective-C one's:

let containerInt = Container(value: 1 as NSNumber)
let containerString = Container(value: "one" as NSString)

This code will compile just fine.

Avoid name collision even in different packages

All Kotlin classes and interfaces from shared module get into one Swift module. That's why having two (or more) classes or interfaces with the same name even if they are located in different packages can cause problems. Kotlin/Native deals with it by adding _ to the name in Swift module. For example if you have Utils class defined in 3 different packages in your shared module in Kotlin, you get Utils, Utils_, Utils__ in Swift.

It is not very obvious how to match these Swift classes with Kotlin's. That's why it's better to create unique names in Kotlin part.

Another option is to use experimental @ObjCName() annotation which tells Kotlin/Native how to translate names.

Include 3rd party libraries into shared module

When you are building your app in KMM, sometimes you need to pack some libraries along with project files in the shared module. For example if you are using Decompose you need to access it's Value class in Swift.

In order to do this, there is an export method in your Framework DSL in gradle build. If you are using regular framework setup you need to find binaries.framework block in your shared module build.gradle.kts. And if you are using cocoapods look at cocoapods.framework block. In this block you need to add export methods with all libraries you want to include.

it.binaries.framework {
    baseName = "shared"
    export("org.example:exported-library1:1.0")
    export("org.example:exported-library2:1.0")
}

And also make sure that libraries decelerated in export are api dependencies. Export only works with api dependencies.

iosMain.dependencies {
    // ...
    api("org.example:exported-library1:1.0")
    api("org.example:exported-library2:1.0") 
}

This very well explained in Kotlin documentation

Provide Kotlin API that doesn't make you invoke coroutine inside coroutine

The Kotlin/Native memory manager has a restriction on calling Kotlin suspending functions from Swift and Objective-C from threads other than the main one.

For example if you have Kotlin class

class Client {
    suspend fun getToken(): String
    suspend fun invokeSmth(token: String)
}

And planning to use it in swift like this:

func handleButtonClick() {
    client.getToken { token, _ in
       client.invokeSmth(token: token) { _ in
           print("Invoked!")
       }
    }
}

It won't work, app will crash while executing nested coroutine. To prevent this you could wrap calling of second coroutine in DispatchQueue.main.sync

func handleButtonClick() {
    client.getToken { token, _ in
       DispatchQueue.main.sync {
           client.invokeSmth(token: token) { _ in
               print("Invoked!")
           }
       }
    }
}

Or else you could turn on experimental flag kotlin.native.binary.objcExportSuspendFunctionLaunchThreadRestriction=none in your gradle.properties. But it's better to avoid this situations by creating additional method in Kotlin part:

class Client {
    suspend fun getToken(): String
    suspend fun invokeSmth(token: String)
    suspend fun getTokenThenInvokeSmth(token: String) {
        val token = getToken()
        invokeSmth(token)
    }
}

When you explore KMM articles, check article date before you read it

There are a lot of articles already has been written about Kotlin Multiplatform Mobile for the last 5 years. KMM api has been changed and improved since then. Inevitably some of very popular articles are outdated.

Good examples are articles about Kotlin/Native memory models. If there are advices about freezes and a lot of limitation, they are about old memory model which is deprecated now.