DEV Community: Arseni Kavalchuk

Coding Agents for Software Engineers

Arseni Kavalchuk — Mon, 23 Feb 2026 01:02:36 +0000

Architecture, Context, and Efficient Usage

1️⃣ What Is a Coding Agent?

A coding agent is not just an LLM.

It is a system:

IDE / CLI
    ↓
Agent Runtime
    ↓
Context Builder
    ↓
LLM Inference
    ↓
Tool Execution (fs, git, tests, shell)
    ↓
Loop

The model is only the reasoning engine.
The runtime handles orchestration.

2️⃣ General Architecture of a Coding Agent

A production-grade coding agent includes:

1. Indexing Layer

Repo scanning
Symbol extraction
Dependency graph
Optional embeddings

2. Context Builder

Select relevant files
Inject instructions
Add plan/scratchpad
Add recent edits

3. LLM Inference Layer

Tokenized prompt
Context window constraints
Streaming output

4. Tool Layer

File read/write
Test execution
Git diff/patch
Lint/build commands

5. Loop Controller

Plan
Execute
Validate
Iterate

The model does not “see the repo.”
The agent chooses what to send.

3️⃣ What Is the Context Window?

The context window is:

The maximum number of tokens the model can attend to in a single inference call.

It includes:

System instructions
+ AGENTS.md / policies
+ Scratchpad / plan files
+ Relevant source files
+ Recent conversation
+ Tool outputs
+ Your current request
+ Model output

Everything must fit inside the window.

Large window ≠ send everything.

4️⃣ Where Does Tokenization Happen?

Typically:

The agent runtime tokenizes locally (client-side).
It estimates token usage before calling the model.
The server still processes tokens during inference.

Why client-side tokenization matters:

Avoid exceeding context
Control cost
Control chunking
Optimize file selection

5️⃣ What Actually Consumes Tokens?

In coding workflows, token cost usually comes from:

Large source files
Test files
Logs
Replayed conversation history
Repeated system instructions
Scratchpad growth

Your instruction verbosity is rarely the main cost.
File selection is.

6️⃣ What Makes “Good Quality” Context?

Good context is:

✅ Relevant

Only include files that matter.

✅ Structured

Clear task → constraints → deliverable.

✅ Deterministic

Explicit scope boundaries.

✅ Minimal but sufficient

No narrative fluff.
No repeated architecture explanation.

Bad context is:

Entire repo dump
Long emotional explanations
Old irrelevant chat history
Ambiguous instructions

7️⃣ What Actually Improves Coding Responses?

Not politeness.
Not verbosity.

What improves results:

1️⃣ Clear Scope

Bad:

Improve authentication system.

Good:

Scope:
- src/auth/*
- src/middleware/auth.ts
Do not touch:
- public API
- schema definitions

2️⃣ Explicit Constraints

Examples:

Do not change public interfaces.
Preserve test behavior.
No new dependencies.
Keep diff minimal.

Constraints reduce hallucinated refactors.

3️⃣ Defined Output Format

Example:

Deliverable:
- Unified diff only
- Brief explanation (<150 words)

This reduces drift.

4️⃣ Plan-First Workflow

Instead of:

Implement feature X.

Use:

Step 1: Generate PLAN.md
Step 2: Review plan
Step 3: Implement Step 1 only
Step 4: Run tests

Planning reduces chaotic edits.

8️⃣ Scratchpads and Plan Files

Scratchpad = external reasoning state.

Can be:

PLAN.md
TODO.md
In-memory state
Conversation buffer

Benefits:

Multi-step tracking
Reduced re-reasoning
Human-agent alignment
Safer iteration

But:
The model does not remember it.
The agent injects it into context each time.

9️⃣ Efficient Project Structure for Coding Agents

Recommended:

/AGENTS.md        # Global behavior rules (minimal)
/PLAN.md          # Task plan (editable)
/src/...
/tests/...

AGENTS.md should contain:

Coding standards
Test commands
“Plan first” rule
Guardrails

Keep it short.
It is injected often.

🔟 Efficient Coding Agent Usage Patterns

Pattern A — Constrained Patch

Task:
Optimize middleware performance.

Scope:
src/auth/middleware.ts

Constraints:
- Preserve API
- No new deps

Output:
Unified diff only.

Pattern B — Incremental Execution

Implement only Step 1 from PLAN.md.
Run tests.
Update PLAN.md.
Stop.

Pattern C — Scope Locking

Explicitly limit directories:

Touch only:
src/auth/*
Do not modify:
src/db/*

This prevents token waste and unintended edits.

1️⃣1️⃣ What NOT to Do

❌ Send the whole repo
❌ Re-explain system architecture every turn
❌ Let scratchpads grow unbounded
❌ Leave scope ambiguous
❌ Ask for “improve everything”

1️⃣2️⃣ Big Context Myth

A 1M token context window does not mean:

You should send 1M tokens.
It will be faster.
It will be more accurate.

Longer context:

Increases latency
Increases cost
Increases noise risk

Smart context selection beats large context.

1️⃣3️⃣ Mental Model for Engineers

Treat coding agents like this:

LLM = Stateless reasoning engine
Context = Input data packet
Agent = Orchestrator
Scratchpad = External memory

Your job:
Optimize the data packet.

1️⃣4️⃣ Core Optimization Principles

Structure > verbosity
Relevance > completeness
Constraints > freedom
Iteration > giant prompts
Plan → execute → verify

Final Takeaway

Coding agents perform best when:

The task is clearly scoped
Constraints are explicit
Context is curated
Plans are externalized
History is pruned
Output format is constrained

Effective Ways to Use Locks in Kotlin

Arseni Kavalchuk — Sat, 14 Dec 2024 00:38:10 +0000

In Kotlin, locks play a critical role in ensuring thread safety when multiple threads access shared resources. Here are the common idiomatic ways to use locks in Kotlin:

1. Using `ReentrantLock` with `lock()` and `unlock()`

The most explicit way to use a lock in Kotlin is by calling lock() and unlock() manually. This provides fine-grained control over when the lock is acquired and released.

Example:

import java.util.concurrent.locks.ReentrantLock

class SafeCounter {
    private val lock = ReentrantLock()
    private var count = 0

    fun increment() {
        lock.lock() // Explicitly acquire the lock
        try {
            count++
            println("Incremented to: $count")
        } finally {
            lock.unlock() // Ensure the lock is released even if an exception occurs
        }
    }

    fun getCount(): Int {
        lock.lock()
        return try {
            count
        } finally {
            lock.unlock()
        }
    }
}

fun main() {
    val counter = SafeCounter()
    val threads = List(10) {
        Thread { counter.increment() }
    }
    threads.forEach { it.start() }
    threads.forEach { it.join() }
    println("Final count: ${counter.getCount()}")
}

2. Using `withLock` Extension Function

The withLock extension function simplifies lock usage in Kotlin by managing the lock() and unlock() calls automatically.

Example:

import java.util.concurrent.locks.ReentrantLock
import kotlin.concurrent.withLock

class SafeList {
    private val lock = ReentrantLock()
    private val list = mutableListOf<String>()

    fun add(item: String) {
        lock.withLock {
            list.add(item)
        }
    }

    fun getList(): List<String> {
        lock.withLock {
            return list.toList() // Return a copy for safety
        }
    }
}

fun main() {
    val safeList = SafeList()
    val threads = List(5) { index ->
        Thread {
            safeList.add("Item-$index")
        }
    }
    threads.forEach { it.start() }
    threads.forEach { it.join() }
    println("Final list: ${safeList.getList()}")
}

3. Using `synchronized`

The synchronized keyword offers a simpler alternative for basic synchronization by locking on a specific monitor object.

Example:

class SafeCounter {
    private var count = 0

    fun increment() {
        synchronized(this) { // Synchronize on the instance itself
            count++
            println("Incremented to: $count")
        }
    }

    fun getCount(): Int {
        synchronized(this) {
            return count
        }
    }
}

fun main() {
    val counter = SafeCounter()
    val threads = List(10) {
        Thread { counter.increment() }
    }
    threads.forEach { it.start() }
    threads.forEach { it.join() }
    println("Final count: ${counter.getCount()}")
}

4. Using `ReadWriteLock`

For scenarios with frequent reads and infrequent writes, ReadWriteLock provides separate locks for reading and writing, allowing multiple threads to read concurrently.

Example:

import java.util.concurrent.locks.ReentrantReadWriteLock

class SafeMap {
    private val lock = ReentrantReadWriteLock()
    private val map = mutableMapOf<String, String>()

    fun put(key: String, value: String) {
        lock.writeLock().lock()
        try {
            map[key] = value
        } finally {
            lock.writeLock().unlock()
        }
    }

    fun get(key: String): String? {
        lock.readLock().lock()
        return try {
            map[key]
        } finally {
            lock.readLock().unlock()
        }
    }
}

fun main() {
    val safeMap = SafeMap()
    val threads = List(5) { index ->
        Thread { safeMap.put("Key-$index", "Value-$index") }
    }
    threads.forEach { it.start() }
    threads.forEach { it.join() }
    println("Final map: $safeMap")
}

5. Using Coroutines and `Mutex`

For coroutine-based concurrency, Kotlin offers the Mutex class from kotlinx.coroutines.sync. This is a coroutine-friendly lock that avoids blocking threads.

Example:

import kotlinx.coroutines.*
import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

class SafeCounter {
    private val mutex = Mutex()
    private var count = 0

    suspend fun increment() {
        mutex.withLock {
            count++
            println("Incremented to: $count")
        }
    }

    fun getCount(): Int = count
}

fun main() = runBlocking {
    val counter = SafeCounter()
    val jobs = List(10) {
        launch {
            counter.increment()
        }
    }
    jobs.forEach { it.join() }
    println("Final count: ${counter.getCount()}")
}

6. Using Atomic Variables

For simple scenarios, atomic variables like AtomicInteger and AtomicLong provide a lock-free alternative for thread-safe counters and accumulators.

Example:

import java.util.concurrent.atomic.AtomicInteger

class SafeCounter {
    private val count = AtomicInteger(0)

    fun increment() {
        println("Incremented to: ${count.incrementAndGet()}")
    }

    fun getCount(): Int = count.get()
}

fun main() {
    val counter = SafeCounter()
    val threads = List(10) {
        Thread { counter.increment() }
    }
    threads.forEach { it.start() }
    threads.forEach { it.join() }
    println("Final count: ${counter.getCount()}")
}

When to Use Each?

ReentrantLock + lock/unlock: Use for low-level control, especially when advanced features like interruptible locks are required.
withLock: The idiomatic Kotlin approach for most use cases.
synchronized: Simple and straightforward for basic synchronization.
ReadWriteLock: Ideal for frequent reads and infrequent writes.
Mutex: Best for coroutine-based concurrency.
Atomic Variables: Lightweight and lock-free, perfect for counters and accumulators.

Each approach caters to specific needs based on complexity, performance, and whether you’re working with threads or coroutines. Understanding these options ensures you can write safe and efficient concurrent Kotlin applications.

iOS String to Kotlin ByteArray Performance Analysis

Arseni Kavalchuk — Mon, 18 Nov 2024 01:13:53 +0000

When working with Kotlin Multiplatform (KMP), interoperability between Kotlin and native code can introduce performance bottlenecks. One such case is converting a Swift String into a Kotlin ByteArray. In this article, we analyze the performance of several approaches to improve this conversion process. We write Swift String extension functions and Kotlin ByteArray factory methods using native pointers and system functions like memcpy to optimize performance. Full source code. Refer to How to set up KMP library in iOS for the details about KMP library and integration with iOS.

Kotlin ByteArray API in iOS

The Kotlin ByteArray is exposed to iOS as the KotlinByteArray class, which provides basic methods like get(index) and set(index:value:), and constructors like init(size:). However, this API is inefficient for scenarios requiring high-performance operations on byte arrays.

`KotlinByteArray` Interface

__attribute__((objc_subclassing_restricted))
__attribute__((swift_name("KotlinByteArray")))
@interface KmpLibKotlinByteArray : KmpLibBase
+ (instancetype)arrayWithSize:(int32_t)size __attribute__((swift_name("init(size:)")));
- (int8_t)getIndex:(int32_t)index __attribute__((swift_name("get(index:)")));
- (void)setIndex:(int32_t)index value:(int8_t)value __attribute__((swift_name("set(index:value:)")));
@property (readonly) int32_t size __attribute__((swift_name("size")));
@end

This interface makes random access and element-wise operations slow due to its lack of batch processing capabilities.

Using Native APIs in KMP

KMP common code cannot access native APIs directly, but native parts of the KMP code can leverage platform-specific functions plus using cinterop API. This enables us to optimize byte array copying by using native constructs.

Working with Native Pointers

In Kotlin/Native, the CPointer type is used to interface with raw memory through pointers. Understanding the differences between pointer types like CPointer<Byte> and CPointer<ByteVar> is essential for efficient memory operations and interoperability with native libraries.

CPointer<Byte> represents a pointer to an immutable sequence of bytes. It is typically used when you want to read data from a memory location without modifying its content. This type is ideal for operations where the memory is treated as read-only, such as parsing a buffer or reading data from a constant memory region.

For example:

fun printByteArray(data: CPointer<Byte>, size: Int) {
    for (i in 0 until size) {
        println(data[i])
    }
}

In this case, data points to a sequence of bytes, and the function iterates over the memory to print each byte.

CPointer<ByteVar> is a pointer to a mutable byte variable. It is used for memory regions that can be written to, such as buffers for receiving data or memory blocks that are initialized and modified. The ByteVar type encapsulates a mutable Byte value in Kotlin/Native, allowing operations like setting new values or performing in-place modifications.

For example:

fun setByteArray(data: CPointer<ByteVar>, size: Int, value: Byte) {
    for (i in 0 until size) {
        data[i] = value
    }
}

Here, data is a mutable pointer, and the function writes a specified value to each byte in the memory block.

Default ByteArray Handling

The Kotlin/Native ByteArray.readBytes is a convenient but inefficient function that loops over each byte, as shown below:

@OptIn(ExperimentalForeignApi::class)
fun byteArrayFromPtrReadBytes(data: CPointer<ByteVar>, size: Int): ByteArray =
    data.readBytes(size)

This essentially goes into this implementation in Kotlin:

fun getByteArray(source: NativePointed, dest: ByteArray, length: Int) {
    val sourceArray = source.reinterpret<ByteVar>().ptr
    for (index in 0 until length) {
        dest[index] = sourceArray[index]
    }
}

Optimizing with `memcpy`

Instead of looping, we can use the highly efficient POSIX memcpy:

@OptIn(ExperimentalForeignApi::class)
fun byteArrayFromPtrMemcpy(data: CPointer<ByteVar>, size: Int): ByteArray {
    return ByteArray(size).also {
        it.usePinned { pinned ->
            memcpy(pinned.addressOf(0), data, size.toULong())
        }
    }
}

Testing Approaches

We implemented five test cases to compare performance:

Loop Copy: Convert a Swift String to a byte array using a loop.
ReadBytes: Use ByteArray.readBytes to copy from a pointer.
Memcpy: Use memcpy to copy from a pointer.
Swift UTF8 Byte Array: Convert String.utf8 to a byte array and compare performance with readBytes and memcpy.
Swift UTF8 CString Pointer: Use String.utf8CString with both readBytes and memcpy.

Swift Implementations

Here are the Swift extension functions:

Loop Copy

func toKotlinByteArrayLoopCopy() -> KotlinByteArray {
    let utf8Bytes = Array(self.utf8)
    let kotlinByteArray = KotlinByteArray(size: Int32(utf8Bytes.count))
    for (index, byte) in utf8Bytes.enumerated() {
        kotlinByteArray.set(index: Int32(index), value: Int8(bitPattern: byte))
    }
    return kotlinByteArray
}

Data Pointer with `readBytes`

func toKotlinByteArrayDataPtrReadBytes() -> KotlinByteArray {
    var data = Array(self.utf8)
    let size = Int32(data.count)
    return data.withUnsafeMutableBytes { ptr in
        ByteArrayUtilKt.byteArrayFromPtrReadBytes(data: ptr.baseAddress!, size: size)
    }
}

Data Pointer with `memcpy`

func toKotlinByteArrayDataPtrMemcpy() -> KotlinByteArray {
    var data = Array(self.utf8)
    let size = Int32(data.count)
    return data.withUnsafeMutableBytes { ptr in
        ByteArrayUtilKt.byteArrayFromPtrMemcpy(data: ptr.baseAddress!, size: size)
    }
}

UTF8 CString with `readBytes` and `memcpy`

func toKotlinByteArrayUtf8CStringReadBytes() -> KotlinByteArray {
    var data = self.utf8CString
    return data.withUnsafeMutableBufferPointer { ptr in
        ByteArrayUtilKt.byteArrayFromPtrReadBytes(data: ptr.baseAddress!, size: Int32(strlen(ptr.baseAddress!)))
    }
}

func toKotlinByteArrayUtf8CStringMemcpy() -> KotlinByteArray {
    var data = self.utf8CString
    return data.withUnsafeMutableBufferPointer { ptr in
        ByteArrayUtilKt.byteArrayFromPtrMemcpy(data: ptr.baseAddress!, size: Int32(strlen(ptr.baseAddress!)))
    }
}

Benchmark Results

The results from running 1000 iterations of each method:

Method	Time (ms)
LoopCopy	32.10
DataPtrReadBytes	2.60
Utf8CStringReadBytes	0.89
DataPtrMemcpy	0.06
Utf8CStringMemcpy	0.02

Insights

LoopCopy is the slowest, due to its repeated calls to set(index:value:).
Using readBytes significantly improves performance but is still not optimal.
Memcpy is the fastest method due to its highly efficient memory operations.
The combination of Swift's utf8CString and Kotlin's memcpy achieves the best performance.

Conclusion

For optimal performance when converting a Swift String to a Kotlin ByteArray, use the following:

Kotlin: Implement a ByteArray factory using memcpy.
Swift: Use utf8CString with unsafe buffer pointers.

This combination delivers minimal overhead, unlocking high-performance interoperability in KMP.

The full implementation is in the project on GitHub.

Enhance iOS Development with Kotlin Multiplatform Library

Arseni Kavalchuk — Sun, 17 Nov 2024 18:37:18 +0000

Kotlin Multiplatform (KMP) is a promising approach that enables developers to share business logic across multiple platforms, including iOS and Android, while allowing platform-specific implementations for platform-dependent functionalities. This article demonstrates how to integrate KMP with iOS, showcasing how to expose Kotlin interfaces to Swift, implement these interfaces in Swift, and leverage them in a Swift UI application.

The focus here is to explore an alternative approach that avoids the complexity of expect/actual patterns. Instead, this method streamlines the integration by minimizing the interaction with platform APIs not exposed in KMP.

We’ll build a sample Swift UI application that encrypts, stores, and decrypts data. The business logic resides in Kotlin, while platform-specific functionality is implemented in Swift.

Setting Up the Kotlin Mutliplatform Library in Android Studio

To begin, you’ll need to create a KMP library using Android Studio. For reference, you can use the example project. The build.gradle.kts file for the library includes important configurations for creating a multiplatform library.

Key Steps:

Use basic KMP project structure. See example project for the reference
Define a list of iOS targets iosX64, iosArm64, iosSimulatorArm64 in your build.gradle.kts.
Define XCFramework with a variable and add all targets to the framework
The key point here is that you need to give some meaningful name to your framework as well as using the same name for the framework binary.

The minimal build.gradle.kts file looks like this:

import org.jetbrains.kotlin.gradle.ExperimentalKotlinGradlePluginApi
import org.jetbrains.kotlin.gradle.dsl.JvmTarget
import org.jetbrains.kotlin.gradle.plugin.mpp.apple.XCFramework

plugins {
    alias(libs.plugins.kotlinMultiplatform)
    alias(libs.plugins.androidLibrary)
}

group = "io.github.arskov"
version = "1.0.0"

// Use some name for the framework. It will be used as main import in Swift
val iosXCFrameworkName = "KmpLib"
val binaryName = "kmp-lib"

kotlin {

    androidTarget {
        publishLibraryVariants("release")
        @OptIn(ExperimentalKotlinGradlePluginApi::class)
        compilerOptions {
            jvmTarget.set(JvmTarget.JVM_1_8)
        }
    }

    val xcf = XCFramework(iosXCFrameworkName)
    val iosTargets = listOf(iosX64(), iosArm64(), iosSimulatorArm64())
    iosTargets.forEach {
        it.binaries.framework {
            baseName = iosXCFrameworkName
            xcf.add(this)
        }
    }

    sourceSets {
        commonMain {
            dependencies {
                // Put necessary KMP compatible dependencies here
            }
        }
        commonTest {
            dependencies {
                implementation(libs.kotlin.test)
            }
        }
    }
}

android {
    namespace = "io.github.arskov"
    compileSdk = libs.versions.android.compileSdk.get().toInt()
    defaultConfig {
        minSdk = libs.versions.android.minSdk.get().toInt()
    }
}

Run the Gradle task to build the library, producing an XCFramework for iOS integration.

Application Architecture and Business Logic

Kotlin module contains MultiplatformService which accepts 2 interfaces as dependencies: CryptoProvider and StoreProvider

package io.github.arskov

class MultiplatformService(
    private val cryptoProvider: CryptoProvider,
    private val storeProvider: StoreProvider
) {

    @Throws(StoreException::class, EncryptionException::class)
    fun storeData(data: PlainData, encryptionKey: ByteArray?) {
        if (!data.encrypted && encryptionKey != null) {
            val encryptedData =
                cryptoProvider.encrypt(op = EncryptOp.ENCRYPT, key = encryptionKey, data = data.content)
            val encryptedPlainData =
                PlainData(id = data.id, encrypted = true, updated = 0L, content = encryptedData)
            storeProvider.store(encryptedPlainData)
        } else {
            storeProvider.store(data)
        }
    }

    @Throws(StoreException::class, EncryptionException::class)
    fun loadData(id: Long, encryptionKey: ByteArray?): PlainData {
        val data = storeProvider.load(id)
        if (data.encrypted && encryptionKey != null) {
            val decryptedData = cryptoProvider.encrypt(op = EncryptOp.DECRYPT, key = encryptionKey, data = data.content)
            return PlainData(id = data.id, encrypted = false, updated = 0L, content = decryptedData)
        }
        return data
    }
}

The main idea of the library is accepting the data, perform a provided crypto operation, and store the value in the provided store.

For simplicity, we also have a default in-memory implementation of the StoreProvider, but this could also be implemented on the Swift side. See below.

Now what we want to do is to integrate this MultiplatformService into Swift UI sample application. In Swift when we construct the MultiplatformService we provide a Swift implementation of the CryptoProvider and the StoreProvider.

Building the XCFramework

An XCFramework is a container that supports multiple architectures, allowing your library to work seamlessly on different iOS devices and simulators.

Steps to Build the XCFramework:

Set the Framework Name: Ensure the framework has a clear and unique name, like KmpLib.
Specify Target Platforms: Define architectures such as iosArm64 for physical devices and iosSimulatorArm64 for simulators.
Run the Build Task: Use ./gradlew task to see what are the possible assemble tasks you have. Use the Gradle task ./gradlew assembleKmpLibXCFramework to build the XCFramework. The output will be located in the kmp-lib/library/build/XCFrameworks/{debug|release}/ directory. Gradle generates assembleXCFramework task if you give your framework a name.

Sample Swift UI Application

The Swift UI application demonstrates how to utilize the KMP library for secure data management. Here's a high-level overview of its functionality:

Encryption: Data is encrypted using the CryptoProvider interface implemented in Swift.
Storage: Encrypted data is stored using the InMemoryStoreProvider or a custom implementation.
Decryption: The app retrieves and decrypts the data for display.

Example Workflow:

Input sample data into the app.
Encrypt and store the data using Kotlin’s business logic.
Retrieve and decrypt the data, showcasing the seamless interplay between Swift and KMP.

The app architecture is minimalist yet demonstrates how Kotlin Multiplatform libraries can enhance iOS development.

Importing the XCFramework into Xcode

To use the generated XCFramework in your Xcode project, follow these steps:

Create a new iOS Swift UI project using the Xcode wizard. You don't need any special steps for this, just follow the Xcode instructions.
Click on a project to open a Project Settings.
Under Frameworks, Libraries, and Embedded Content, click the + button.
Add the path to the XCFramework: kmp-lib/library/build/XCFrameworks/debug/KmpLib.xcframework. The framework will appear in the Frameworks section of the Project structure in the left tree panel.

This integration allows Swift to access Kotlin’s business logic.

Implementing KMP Interfaces in Swift

In our example, we’ve imported the KmpLib framework and now we are going to implement its exposed interfaces in Swift. The key interfaces are:

CryptoProvider: Handles encryption and decryption of data.
StoreProvider: Provides storage functionality. In this case, we use the default InMemoryStoreProvider from KMP.
Example of the IosCryptoProvider in Swift that implements the CryptoProvider interface (a protocol in Swift)

import KmpLib

class IosCryptoProvider: CryptoProvider {
    func encrypt(op: EncryptOp, key: KotlinByteArray, data: KotlinByteArray)
        throws -> KotlinByteArray
    {
        // Ensure the key is not empty
        guard key.size > 0 else {
            throw NSError(
                domain: "CryptoError", code: 1,
                userInfo: [NSLocalizedDescriptionKey: "Key must not be empty"])
        }
        // Create a result array of the same size as the data
        let result = KotlinByteArray(size: data.size)
        // Perform XOR encryption
        for i in 0..<data.size {
            let dataByte = data.get(index: i)
            let keyByte = key.get(index: i % key.size)
            result.set(index: i, value: dataByte ^ keyByte)
        }
        return result
    }
}

The ServiceLocator which contains the main code that instantiates and crates a Singleton for MultiplatformService:

import Foundation
import KmpLib

class ServiceLocator {
    static let sharedInstance = ServiceLocator()

    private let mutliplatformService: MultiplatformService!
    private let storeProvider: StoreProvider!

    private init() {
        // Swift implementation of the CryptoProvider protocol exposed from KMP
        let cryptoProvider = IosCryptoProvider()
        // KMP implementation of Stor
        storeProvider = InMemoryStoreProvider()
        mutliplatformService = MultiplatformService(
            cryptoProvider: cryptoProvider, storeProvider: storeProvider)
    }

    func getMultiplatformService() -> MultiplatformService {
        return self.mutliplatformService
    }

    func getStoreProvider() -> StoreProvider {
        return self.storeProvider
    }
}

The ContentView.swift file contains main UI logic:

Set the password for the content encryption
Set the text
Button to encrypt and store the content
Controls to display the encrypted text in HEX
Button to load and decrypt the content

            Button(action: {
                let service = ServiceLocator.sharedInstance
                    .getMultiplatformService()
                let store = ServiceLocator.sharedInstance.getStoreProvider()
                let plainData = PlainData(
                    id: 1,
                    encrypted: false,
                    updated: 0,
                    content: self.plainDataText.toKotlinByteArray()
                )
                do {
                    try service.storeData(
                        data: plainData,
                        encryptionKey: encryptionKey.toKotlinByteArray())
                    let storedData = try store.load(id: 1)
                    self.encryptedDataText = storedData.content.toHexString()

                } catch {
                    print("error: \(error)")
                }
            })

Important detail, that we also crated some extension functions for KotlinByteArray and String to be able to easily convert between them.

In production this copy operation is not cheap, and especially with the default methods that the KMP exposes for KotlinByteArray, like get(i), set(i, value). We will consider alternatives in the follow up article iOS String to Kotlin ByteArray Performance Analysis .

The running application looks like:

Conclusion

This article provided a step-by-step guide on leveraging Kotlin Multiplatform libraries for iOS development. By following this alternative approach, you can efficiently share business logic across platforms without delving into the complexities of expect/actual APIs. The sample Swift UI application highlights the practical integration of KMP interfaces in Swift, showcasing the potential for streamlined cross-platform development.

For further exploration, check out the complete example on GitHub.

Modern Dependency Injection with Koin: The Smart DI Choice for 2025

Arseni Kavalchuk — Sat, 02 Nov 2024 15:48:44 +0000

In the Kotlin ecosystem, dependency injection (DI) frameworks are essential for managing dependencies, improving modularity, and streamlining application development. Koin has emerged as a popular DI framework for Kotlin developers, especially valued for its simplicity, lightweight nature, and multiplatform support. At the time of writing, Koin 4.0 has been released. Built on Kotlin 2.0, this release introduces a wide range of enhancements and Compose Multiplatform features. As we move into 2025, Koin continues to be an excellent choice, particularly because of its Kotlin-first design, ease of use, and adaptability across platforms.

1. Kotlin-First Design

Koin was developed specifically with Kotlin in mind, making it a truly Kotlin-native DI framework. Unlike other DI frameworks adapted from Java, Koin’s syntax feels natural and intuitive for Kotlin developers. It leverages Kotlin’s expressive language features, resulting in cleaner and more concise code.

Basic Dependency Definition in Koin:

In Koin, dependencies are defined within modules using a domain-specific language (DSL) in Kotlin. For instance, to define a repository and service dependency, you can use the following code:

// Defining dependencies in a Koin module
val appModule = module {
    single { MyDatabase(get()) } // Defines a singleton of MyDatabase
    single { UserRepository(get()) } // Defines a singleton of UserRepository that depends on MyDatabase
    factory { MyService(get()) } // Defines a new instance of MyService whenever it’s injected
}

Explanation:

single: Defines a singleton instance, meaning the same instance of MyDatabase or UserRepository is provided each time it’s needed.
factory: Creates a new instance each time MyService is injected, useful for lightweight or short-lived components.

This concise approach keeps dependency management straightforward, making Koin’s syntax highly readable and less error-prone.

2. Easy to Learn and Integrate

Koin’s simple and intuitive API makes it easy for developers to set up dependency injection without complex configurations. You can define your dependencies directly in Kotlin code without any XML files or annotations, making it easier to onboard new team members and start development quickly.

Setting Up Koin:

To get started with Koin, all you need to do is define dependencies and the configuration in the Gradle project, define your modules and initialize Koin in the Application class:

// Initializing Koin
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()

        // Starting Koin with the appModule
        startKoin {
            androidContext(this@MyApp)
            modules(appModule)
        }
    }
}

Explanation:

startKoin: Initializes Koin and loads the provided modules. Here, the appModule defines all necessary dependencies for the application.
androidContext: Provides the Android context to Koin, allowing it to work seamlessly with Android components.

This setup makes it easy to configure and manage dependencies, saving development time and reducing setup complexity.

3. Annotation-Free Dependency Injection

While annotations are supported, one of Koin's standout features is its annotation-free DI configuration, which aligns with the trend toward increased compile-time safety and code clarity. By using Kotlin code rather than annotations to declare dependencies, Koin makes it easier for developers to understand each component's dependencies at a glance.

Defining Dependencies Without Annotations:

Koin uses simple Kotlin functions and classes to define dependencies, avoiding the use of annotations altogether. Here’s an example:

// Define a ViewModel dependency
val viewModelModule = module {
    viewModel { MyViewModel(get()) }
}

// Dependency definition without annotations
class MyViewModel(private val repository: UserRepository) : ViewModel() {
    fun loadUserData() {
        // Business logic to load user data
    }
}

Explanation:

viewModel: A special Koin function for defining ViewModels, which automatically integrates with the Android lifecycle. Here, MyViewModel depends on UserRepository, which is injected by Koin.

Without annotations, the dependencies and their relationships are explicit in the code, making it easier to understand and maintain.

4. Kotlin Multiplatform Support

Kotlin Multiplatform (KMP) has become increasingly popular for developing cross-platform applications. Koin supports multiplatform development, allowing developers to define dependencies that work across Android, iOS, and other platforms seamlessly.

Example of Multiplatform Module:

Here’s how you might set up a common module for a multiplatform project with Koin:

// Defining a common module for multiplatform
val commonModule = module {
    single { NetworkClient() } // Singleton for network client
    factory { DataRepository(get()) } // Factory for repository
}

// Sample KMP service with shared dependency
class NetworkClient {
    fun requestData(): String = "Response from NetworkClient"
}

class DataRepository(private val networkClient: NetworkClient) {
    fun fetchData() = networkClient.requestData()
}

Explanation:

In this setup:

The NetworkClient dependency is shared across platforms.
DataRepository relies on NetworkClient, promoting code reuse and reducing boilerplate.

Koin’s multiplatform modules allow consistent DI practices across platforms, making it easier to maintain and scale cross-platform applications.

5. Enhanced Performance and Lightweight Nature

Koin is lightweight and avoids the overhead of compile-time dependency injection, which can slow down build times. Instead, Koin performs DI at runtime, optimizing build speed and making it especially beneficial for CI/CD pipelines.

Using Singletons and Factories to Control Instance Lifetimes:

Koin’s single and factory functions give you precise control over the lifecycle of your dependencies:

val performanceModule = module {
    single { ExpensiveResource() } // Singleton for a resource-heavy dependency
    factory { LightweightTask() } // Factory for lightweight tasks
}

class ExpensiveResource {
    // Simulate an expensive resource initialization
}

class LightweightTask {
    fun execute() {
        // Execute task
    }
}

By controlling dependency lifetimes with single and factory, you can optimize performance by limiting the instantiation of resource-heavy objects while keeping lightweight tasks efficient.

6. Scalable Modularization

In modern applications, modularization enables teams to work on different features independently, improving scalability and flexibility. Koin’s module system supports this approach by allowing dependencies to be organized into distinct modules that can be loaded or unloaded as needed.

Organizing Dependencies by Feature:

Here’s an example of separating dependencies into modules by feature:

// User feature module
val userModule = module {
    single { UserRepository(get()) }
    factory { UserViewModel(get()) }
}

// Product feature module
val productModule = module {
    single { ProductRepository() }
    factory { ProductViewModel(get()) }
}

Explanation:

Each feature module contains its own dependencies, encapsulating logic and promoting modularity.
Developers can load only the necessary modules for specific features, keeping the dependency structure clean and manageable.

This approach supports modern architecture patterns like MVVM and Clean Architecture, making it easier to scale applications as features and dependencies grow.

7. Community and Ecosystem Growth

Since its release, Koin has fostered a vibrant community that continuously enhances the framework. In 2025, Koin has evolved to support the latest trends in Kotlin and Android development, with frequent updates, plugins, and extensions. The support from its community ensures that Koin remains a future-proof DI framework with reliable and robust features.

As Kotlin Multiplatform becomes more widely adopted, Koin’s community provides resources and plugins that facilitate smooth multiplatform development, further enhancing its value as a versatile and reliable framework.

8. Seamless Testing Capabilities

Testing DI setups can be challenging, but Koin simplifies it with built-in testing modules that allow developers to mock dependencies easily. This feature is particularly useful in test-driven development (TDD) and continuous integration (CI) environments, where testing dependency injection setups is crucial.

Setting Up Test Dependencies:

Here’s an example of setting up test dependencies with Koin:

class MyViewModelTest : KoinTest {
    private val mockRepository: UserRepository = mockk()

    @Before
    fun setup() {
        startKoin {
            modules(module {
                single { mockRepository } // Mocked UserRepository for testing
                viewModel { MyViewModel(get()) }
            })
        }
    }

    @Test
    fun testViewModelFunction() {
        // Testing MyViewModel logic with mock dependencies
    }
}

Explanation:

KoinTest: An interface that integrates Koin into testing environments.
Mocked Dependencies: The real dependencies are replaced with mocks, allowing isolated and controlled testing of components.

With Koin, developers can easily inject mocks and override dependencies, making it simple to maintain robust test coverage and ensure code quality.

9. Flexibility for Any Type of Project

Koin’s flexibility extends beyond Android and mobile applications. As Kotlin’s use expands into backend and web development, Koin has proven to be an adaptable DI solution for a variety of project types. It integrates well with frameworks like Ktor for building backend services, providing efficient dependency management across all application layers.

Example of Koin in a Ktor Project:

fun Application.module() {
    install(Koin) {
        modules(koinModule)
    }

    routing {
        get("/data") {
            val repository: DataRepository by inject()
            call.respondText(repository.fetchData())
        }
    }
}

val koinModule = module {
    single { DataRepository() }
}

class DataRepository {
    fun fetchData() = "Data from repository"
}

Explanation:

Koin’s DI capabilities extend to server-side development, where it integrates smoothly with Ktor, enhancing modularity and maintainability.
The Ktor server can inject dependencies defined in Koin modules, ensuring consistency across all project layers.

Conclusion

Koin’s Kotlin-first design, ease of use, multiplatform support, and lightweight runtime architecture make it a compelling choice for dependency injection in 2025. As Kotlin continues to expand across platforms, Koin’s intuitive and annotation-free approach ensures clear, concise, and maintainable DI setups for modern applications. For Kotlin developers building cross-platform, modular, and testable applications, Koin provides an efficient and future-proof solution for managing dependencies with ease.

Memory Management and Garbage Collection in Kotlin Multiplatform XCFramework

Arseni Kavalchuk — Sun, 27 Oct 2024 19:54:02 +0000

Introduction

In the previous article, we explored manual memory management and garbage collection in Kotlin Multiplatform (KMP) with a focus on shared libraries. KMP's ability to generate shared libraries for C++ projects and frameworks for Apple platforms makes it highly versatile, but each output format brings unique challenges and advantages in memory management. This article dives into using an Apple XCFramework from Kotlin Multiplatform, focusing on memory management and garbage collection (GC) in a Swift-based environment. We’ll highlight key differences from the shared library implementation and observe how automatic memory management in Swift’s ARC simplifies the process.

Building and Using an XCFramework in Swift

Building an XCFramework

Creating an XCFramework with Kotlin Multiplatform is straightforward, especially with Gradle's built-in support for Apple frameworks. The process is defined in the build script, as seen in the Gradle configuration example.

Key steps for building the XCFramework include:

Setting Up Target Platforms: In the kotlin block of build.gradle.kts, specify the Apple targets (iosArm64, iosX64, and iosSimulatorArm64).
Defining XCFramework Output: Use the framework directive to configure the XCFramework output, specifying necessary build parameters like baseName and the output directory.
Building with Gradle: Use the command ./gradlew assembleKmpSampleXCFramework to generate the framework, which can then be imported into an Xcode project. The task name will depend on the XCFramework(name) passed in the build.gradle.kts. In our case it is KmpSample and the task name is assembleKmpSampleXCFramework respectively.

Using the XCFramework in a Swift Project

The XCFramework can be added directly to an Xcode project, allowing seamless use of Kotlin code in Swift. The Swift sample project demonstrates this.

I won't spend much in this article on how do you exactly include the framework into the Swift project. But essentially it just requires creating a Swift project (like a CLI app, programming language: Swift), and drag-n-dropping the KmpSample.xcframework folder from build/XCFrameworks/[debug,release]/ directly into Xcode project.

Now let's focus on the example of invoking Kotlin methods from Swift:

import Foundation
import KmpSample

let clazzInstance = KmpClazz()

// Call interfaceMethod
let resultString = clazzInstance.interfaceMethod()
print("Result from interfaceMethod: \(resultString)")

// Call returnInt
if let intResult = clazzInstance.returnInt() {
    print("Result from returnInt: \(intResult)")
}

// Call returnLong
if let longResult = clazzInstance.returnLong() {
    print("Result from returnLong: \(longResult)")
}

// Passing a byte array to a Kotlin function
var byteArray: [UInt8] = [0xCA, 0xFE, 0xCA, 0xFE, 0xCA, 0xFE, 0xCA, 0xFE]
let size = byteArray.count
byteArray.withUnsafeMutableBytes { rawBufferPointer in
    KmpSampleKt.readNativeByteArray(byteArray: rawBufferPointer.baseAddress!, size: Int32(size))
}

In contrast to the shared library setup, using the XCFramework in Swift reduces the need for manual disposal of resources. Swift's ARC automatically manages object references, freeing developers from the memory management steps required in C++.

Memory Management in Kotlin Multiplatform with XCFramework

Kotlin Native provides a garbage collector (GC) that manages memory for objects created within the Kotlin framework. Although Swift’s ARC handles the lifespan of objects, the GC in Kotlin remains active, especially for objects created internally within Kotlin’s runtime. To monitor GC behavior, pass the -Xruntime-logs=gc=info flag during compilation, as configured in the Gradle build here.

With GC logging enabled, you’ll see output like this when running the framework in a Swift environment:

[INFO][gc][tid#1494899][0.000s] Adaptive GC scheduler initialized
[INFO][gc][tid#1494899][0.001s] Set up parallel mark with maxParallelism = 8 and cooperative mutators
[INFO][gc][tid#1494899][0.001s] Parallel Mark & Concurrent Sweep GC initialized

Observing GC Behaviour

To test how Kotlin GC performs under heavy load, we can simulate high-frequency object creation and disposal in Swift. The sample code in IntegrationGcTest creates millions of KmpClazz instances, calling methods and disposing of objects in a loop. The following code demonstrates this scenario:

import Foundation
import KmpSample

for i in 1...10_000_000 {
    let clazzInstance = KmpClazz()

    // Call interfaceMethod
    let resultString = clazzInstance.interfaceMethod()

    // Call returnInt
    if let intResult = clazzInstance.returnInt() {}

    // Call returnLong
    if let longResult = clazzInstance.returnLong() {}

    if i % 1_000_000 == 0 {
        print("Created \(i) objects")
    }
}

GC Log Analysis for XCFramework in Swift

The full GC log for the example above

The resulting GC log from this loop is extensive. Here’s a segment of the log:

[INFO][gc][tid#1796721][16.128s] Epoch #157: Started. Time since last GC 95913 microseconds.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Root set: 0 thread local references, 0 stack references, 0 global references, 1 stable references. In total 1 roots.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Mark: 2728 objects.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Sweep extra objects: swept 58915 objects, kept 68256 objects
[INFO][gc][tid#1796721][16.138s] Epoch #157: Sweep: swept 65528 objects, kept 2728 objects
[INFO][gc][tid#1796721][16.138s] Epoch #157: Heap memory usage: before 6160384 bytes, after 6422528 bytes
[INFO][gc][tid#1796721][16.138s] Epoch #157: Time to pause #1: 32 microseconds.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Mutators pause time #1: 2884 microseconds.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Time to pause #2: 2 microseconds.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Mutators pause time #2: 10 microseconds.
[INFO][gc][tid#1796721][16.138s] Epoch #157: Finished. Total GC epoch time is 10008 microseconds.
[INFO][gc][tid#1796725][16.145s] Epoch #157: Finalization is done in 6885 microseconds after epoch end.

Key Observations from the GC Logs

GC Epoch Frequency: The XCFramework GC runs frequent epochs due to high object turnover. Compared to shared libraries, there are significantly more GC epochs (157 vs 31), suggesting a more responsive GC handling objects in short-lived scopes. See GC log for the shared library for comparison.
Stable References and Roots: Since objects in Swift go out of scope naturally, stable references are kept to a minimum, which prevents the Kotlin GC from holding on to unreferenced objects, enhancing efficiency.
Performance Impact: Frequent GC epochs show that although ARC handles disposals, Kotlin’s GC is still active and essential in memory management for stable references within the framework.

Summary

Using Kotlin Multiplatform’s XCFramework simplifies memory management in Apple projects by offloading much of the work to Swift’s ARC. This setup reduces the need for explicit disposal, enhancing code readability and reducing potential memory leaks. However, Kotlin Native’s garbage collector still plays an active role, particularly for stable references within the Kotlin framework.

In the next article, we’ll further investigate performance optimization for KMP GC handling in large-scale Swift applications.

References

Manual Memory Management and Garbage Collection in Kotlin Multiplatform Native Shared Libraries

Arseni Kavalchuk — Sun, 27 Oct 2024 16:57:10 +0000

Introduction

Kotlin Multiplatform (KMP) has opened up exciting opportunities for developers to create cross-platform applications using a shared codebase that can run natively on different platforms, including Android, iOS, macOS, Windows, and Linux. One of the core benefits of KMP is its ability to target native environments through shared libraries and frameworks, particularly useful in projects where both C++ and Apple (iOS/macOS) components need to interact with shared logic without redundant implementations.

In this article, we’ll focus on building a shared library and an Apple framework from a Kotlin Multiplatform project. Specifically, we’ll explore the differences between a shared library and a framework, with sample GitHub projects illustrating how APIs are structured and generated in each case. This will be followed by a practical guide on using the shared library in a C++ project and an in-depth look at memory management in Kotlin Native, focusing on how garbage collection (GC) functions within KMP. By the end, you’ll have a solid grasp of implementing and managing a shared library and framework in Kotlin Multiplatform.

Shared Library vs. Apple Framework: What’s the Difference?

We will use the sample KMP project as an example of the native shared library.

The sample class that we are using in this article is:

interface KmpInterface {
    fun interfaceMethod(): String
}

class KmpClazz: KmpInterface {
    fun returnLong(): Long? = 42L
    fun returnInt(): Int? = 42
    override fun interfaceMethod(): String {
        return "KmpClazz"
    }
    ...
}

When working with Kotlin Multiplatform, two primary methods exist for sharing code with native platforms: shared libraries and Apple frameworks. Each serves distinct purposes:

Shared Libraries: Typically generated as static or dynamic libraries (.so, .dll, or .dylib files), these are more common in environments where the target is a native codebase in C++ or similar languages. The generated shared library API reveals how the Kotlin code translates into C-compatible functions and structures.
Apple Frameworks: Produced as .framework bundles, these are exclusive to Apple platforms and cater to Swift and Objective-C interoperability. The framework API example shows the Objective-C bridge generated for the Kotlin code, allowing seamless integration with Apple projects.

The configuration difference for MacOS target can be specified with the following code in build.gradle.kts:

kotlin {
    macosX64 {
        binaries {
            sharedLib(libraryName)
            framework(libraryName)
        }
    }
}

In terms of structure, the shared library is more barebones, focusing on function exports and C-compatible structures. On the other hand, the Apple framework offers a more robust integration, allowing Swift or Objective-C to call Kotlin code more naturally with less manual intervention.

Building and Using a Shared Library in C++ Projects

To use the KMP shared library in a C++ project, some foundational steps include initialization, object creation, and handling pointers and disposal to ensure memory efficiency. Here’s a practical guide to using a KMP shared library in C++ based on the KMP C++ integration sample code.

Steps for Using the Shared Library

Initialization: Begin by initializing the library symbols to access the APIs exported from Kotlin:

   libKmpSample_ExportedSymbols *lib = libKmpSample_symbols();

Object Creation: Instantiate objects and classes from the Kotlin library by calling the relevant constructors.

   libKmpSample_kref_design_KmpClazz clazzInstance = lib->kotlin.root.design.KmpClazz.KmpClazz();

Invoking Methods: Use the lib object to call Kotlin methods and retrieve results.

   const char *interfaceMethodResult = lib->kotlin.root.design.KmpClazz.interfaceMethod(clazzInstance);
   std::cout << "interfaceMethod result: " << interfaceMethodResult << std::endl;
   lib->DisposeString(interfaceMethodResult);  // Dispose of the returned string when no longer needed

Memory Management: Carefully dispose of any objects or pointers obtained from the Kotlin side to avoid memory leaks. This includes invoking DisposeStablePointer for instances not automatically collected by Kotlin Native's garbage collector.

These essential steps provide a structure for incorporating KMP shared libraries in C++ applications, especially when navigating Kotlin’s garbage collection and memory management system in a native environment.

Memory Management in Kotlin Multiplatform Native

Memory management in Kotlin Multiplatform involves balancing explicit disposals in C++ with Kotlin Native’s garbage collection (GC) features. Although Kotlin provides automatic memory management, developers need to handle memory references explicitly when using KMP in C++ or native code.

Kotlin Native Garbage Collection

Kotlin Native incorporates a garbage collector, which is especially crucial in cross-language contexts where unmanaged code (like C++) interacts with managed code (Kotlin). Enabling detailed GC logging helps understand GC behavior, allowing developers to optimize memory handling. To enable GC logs, pass the -Xruntime-logs=gc=info flag in the build configuration, as shown in the sample Gradle build configuration.

Here’s an example GC log output when using this flag:

[INFO][gc][tid#1494899][0.000s] Adaptive GC scheduler initialized
[INFO][gc][tid#1494899][0.001s] Set up parallel mark with maxParallelism = 8 and cooperative mutators
[INFO][gc][tid#1494899][0.001s] Parallel Mark & Concurrent Sweep GC initialized

Managing Objects and References

Using GC doesn’t mean we can ignore memory management entirely in C++. Explicit disposal remains necessary for stable references and objects returned from Kotlin to the native environment. Here’s an example showing how to manage references:

libKmpSample_ExportedSymbols *lib = libKmpSample_symbols();
libKmpSample_kref_design_KmpClazz clazzInstance = lib->kotlin.root.design.KmpClazz.KmpClazz();

// Call and convert the result from returnInt
libKmpSample_kref_kotlin_Int intResult = lib->kotlin.root.design.KmpClazz.returnInt(clazzInstance);
int nativeInt = lib->getNonNullValueOfInt(intResult);
std::cout << "returnInt result: " << nativeInt << std::endl;

// Dispose of stable pointers
lib->DisposeStablePointer(intResult.pinned);
lib->DisposeStablePointer(clazzInstance.pinned);

In this example, the DisposeStablePointer function cleans up memory allocated by the Kotlin library to prevent memory leaks. The following sample script IntegrationGcTest creates 10 millions of KmpClazz instances in a loop to observe GC activity.

Observing GC Behavior with and Without Proper Disposal

With proper disposal:

Created 9900000 objects
[INFO][gc][tid#1544690][9.475s] Epoch #31: Started. Time since last GC 230405 microseconds.
[WARNING][gc,gcScheduler][tid#1544103][9.526s] Pausing the mutators until epoch 31 is done
[INFO][gc][tid#1544690][9.534s] Epoch #31: Root set: 0 thread local references, 0 stack references, 0 global references, 2 stable references. In total 2 roots.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Mark: 32730 objects.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Sweep extra objects: swept 0 objects, kept 0 objects
[INFO][gc][tid#1544690][9.534s] Epoch #31: Sweep: swept 311293 objects, kept 32730 objects
[INFO][gc][tid#1544690][9.534s] Epoch #31: Heap memory usage: before 5767168 bytes, after 5767168 bytes
[INFO][gc][tid#1544690][9.534s] Epoch #31: Time to pause #1: 36 microseconds.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Mutators pause time #1: 18493 microseconds.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Time to pause #2: 0 microseconds.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Mutators pause time #2: 8 microseconds.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Finished. Total GC epoch time is 58878 microseconds.
[INFO][gc][tid#1544690][9.534s] Epoch #31: Finalization is done in 77 microseconds after epoch end.

Root set: 0 thread local references, 0 stack references, 0 global references, 2 stable references. Total GC epoch time is 58878 microseconds.

The full GC log

Without disposal:

Created 9900000 objects
[INFO][gc][tid#1495514][25.624s] Epoch #31: Started. Time since last GC 275504 microseconds.
[WARNING][gc,gcScheduler][tid#1494899][26.363s] Pausing the mutators until epoch 31 is done
[INFO][gc][tid#1495514][26.761s] Epoch #31: Root set: 0 thread local references, 1 stack references, 0 global references, 19894275 stable references. In total 19894276 roots.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Mark: 32666 objects.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Sweep extra objects: swept 0 objects, kept 0 objects
[INFO][gc][tid#1495514][26.761s] Epoch #31: Sweep: swept 311357 objects, kept 32666 objects
[INFO][gc][tid#1495514][26.761s] Epoch #31: Heap memory usage: before 5767168 bytes, after 5767168 bytes
[INFO][gc][tid#1495514][26.761s] Epoch #31: Time to pause #1: 1 microseconds.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Mutators pause time #1: 707412 microseconds.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Time to pause #2: 1 microseconds.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Mutators pause time #2: 8 microseconds.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Finished. Total GC epoch time is 1136902 microseconds.
[INFO][gc][tid#1495514][26.761s] Epoch #31: Finalization is done in 55 microseconds after epoch end.

Root set: 0 thread local references, 1 stack references, 0 global references, 19894275 stable references. Total GC epoch time is 1136902 microseconds.

When objects and references are correctly disposed, GC pauses are minimal, and root references remain low, optimizing application performance.

Summary

Kotlin Multiplatform provides developers with a versatile toolkit for creating shared libraries and frameworks that can be utilized across multiple platforms, with both C++ and Apple frameworks supported seamlessly. By understanding the nuances of shared libraries versus frameworks, developers can choose the best integration approach for their needs, leveraging a common Kotlin codebase.

While Kotlin’s GC simplifies memory management, cross-platform contexts require careful attention to object disposal to avoid performance issues. Proper management of references, enabled by GC insights, helps streamline memory use and maintain application responsiveness. In the following article, we’ll continue exploring GC behavior, particularly within a Swift-based CLI app that interacts with the KMP-built Apple Framework.

References

Kotlin Sequences: Efficient and Lazy Collection Processing

Arseni Kavalchuk — Sun, 20 Oct 2024 18:16:28 +0000

Kotlin Collections Types

Kotlin, a modern programming language that has grown rapidly in popularity due to its concise syntax and powerful features, provides robust support for collections. Collections are a fundamental part of many programming tasks, as they help store and manipulate groups of objects. In Kotlin, the most commonly used collection interfaces are List, Set, and Map. These collection types allow developers to handle data efficiently, depending on the specific use case. Let’s take a brief look at these types. (Please note, that I'm not addressing time complexity of particular operations on different types of collections in this article. This topic requires a separate article.)

List: An indexed collection that allows duplicate elements. In Kotlin, lists are categorized as MutableList (modifiable) and List (read-only). Lists maintain the order of insertion, making them ideal for tasks that require data to be processed in sequence.
Set: A collection that contains no duplicate elements. It is useful when uniqueness is critical. Similar to lists, there are Set (read-only) and MutableSet (modifiable) types. Sets are optimal when checking for membership or avoiding duplicates in the collection is a priority.
Map: A collection of key-value pairs, where each key is unique. Maps are ideal for associative arrays and dictionary-like structures, where each key is mapped to a corresponding value. Again, Map has corresponding read-only Map and read-write MutableMap counterparts.

Here’s an example of these collections in action:

val myList = listOf(1, 2, 3, 4, 5) // Immutable List
val mySet = setOf(1, 2, 2, 3, 4) // Immutable Set, automatically removes duplicates
val myMap = mapOf("one" to 1, "two" to 2, "three" to 3) // Immutable Map

Collections in Kotlin can be mutable (modifiable) or immutable (read-only). This immutability feature aligns with Kotlin's focus on immutability for safer, more predictable code. However, when transforming and filtering data, collections can sometimes become inefficient, especially when working with large datasets.

Kotlin provides alternative API as Sequence<T>, which provides powerful solution to this problem by allowing lazy evaluation of collection transformations.

Essential Methods for Kotlin Collection Filtering and Transformation

Kotlin embraces functional programming paradigms, which encourage writing clean and concise code. Many Kotlin collection operations are based on higher-order functions—functions that take other functions as parameters or return them. This allows Kotlin developers to perform complex data transformations and filtering operations in more convenient way.

Kotlin offers several transformation and filtering methods for collections:

map(): Transforms each element in a collection and returns a new collection with the transformed elements.
filter(): Returns a collection that only contains elements that satisfy a given predicate.
flatMap(): Flattens a nested collection after applying a transformation function, returning a single collection of transformed elements.
sortedBy(): Sorts a collection based on a specific property of its elements.
reduce() and fold(): Both of these methods combine all the elements in a collection into a single result using an accumulator function. The difference is that fold() allows you to specify an initial value for the accumulator.

Here are examples of common transformations and filtering:

val numbers = listOf(1, 2, 3, 4, 5)

// Transform: map
val doubled = numbers.map { it * 2 } // [2, 4, 6, 8, 10]

// Filter: filter
val evenNumbers = numbers.filter { it % 2 == 0 } // [2, 4]

// Flatten: flatMap
val nestedList = listOf(listOf(1, 2), listOf(3, 4))
val flattened = nestedList.flatMap { it } // [1, 2, 3, 4]

These functions are extremely powerful but have one potential downside: when applied to large datasets, they eagerly evaluate every transformation, creating intermediate collections. This eager evaluation can lead to performance issues due to the creation of unnecessary temporary objects in memory. This is where Kotlin’s Sequences come into play.

Kotlin Sequences: Efficient, Lazy Collection Processing

While Kotlin’s regular collections process elements eagerly, meaning all operations are immediately executed and intermediate collections are created, Sequences operate in a lazy manner. This means that transformations on sequences are only performed as elements are needed. This can lead to significant performance improvements when working with large datasets or expensive computations, as intermediate results are not calculated unless they are actually required.

Key Differences Between Collections and Sequences

Eager vs Lazy Evaluation: Collections evaluate operations eagerly, creating intermediate collections, while sequences process elements lazily, avoiding intermediate collections.
Performance: Sequences are more memory-efficient and can outperform regular collections when chaining multiple transformations on large datasets, since they minimize the creation of temporary collections.
Use Cases: Sequences are ideal for processing large datasets or when applying several transformation steps.

Here’s how sequences work in practice:

val numbers = listOf(1, 2, 3, 4, 5)

// Eager evaluation with collections
val eagerResult = numbers
    .map { it * 2 }
    .filter { it % 3 == 0 } 
// Intermediate collections are created for the result of map and filter

// Lazy evaluation with sequences
val lazyResult = numbers.asSequence()
    .map { it * 2 }
    .filter { it % 3 == 0 }
    .toList() // Sequences need to be converted back to a collection for use

In this example, the map and filter operations for the lazyResult sequence are not executed immediately. Instead, each transformation is applied only when necessary, and the entire sequence is processed in a single pass when we call toList(). This lazy approach saves both time and memory.

Benefits of Using Sequences

Efficiency for Large Datasets: Sequences can dramatically improve performance by deferring computations until they are needed.
No Intermediate Collections: Unlike lists, sequences don’t generate intermediate collections between transformations, which reduces overhead.
Composability: Sequences are easy to compose with multiple operations like map, filter, and flatMap, making complex data transformations efficient.

Example: Efficient Sequence Processing

Here’s an example where sequences can make a noticeable difference:

val bigList = (1..1_000_000).toList()

// Regular List processing
val processedList = bigList
    .map { it * 2 }
    .filter { it % 3 == 0 }
    .take(10)

// Sequence processing
val processedSequence = bigList.asSequence()
    .map { it * 2 }
    .filter { it % 3 == 0 }
    .take(10)
    .toList()

In this example, the list processing generates intermediate collections that store the result of the map and filter operations, while the sequence performs all operations lazily, ensuring that only the first 10 elements are processed.

Summary: Critical Differences Between Collections and Sequences

The main difference between Kotlin collections and sequences boils down to their evaluation strategy: eager versus lazy. Regular collections like List and Set eagerly process every transformation, creating intermediate collections, which can negatively affect performance when processing large datasets or performing numerous transformations. In contrast, Sequences process elements lazily, deferring computation until it’s necessary. This leads to more efficient memory usage and faster execution times for complex operations, especially when working with large datasets or streams of data.

To summarize:

Use regular collections when working with small datasets or when eager evaluation won’t cause performance bottlenecks.
Use sequences when working with large datasets or complex chains of transformations to avoid unnecessary intermediate collections and improve performance.

Kotlin sequences provide a powerful mechanism for lazy, efficient data processing, helping developers write cleaner, more performant code.

Match a String with Regular Expression in Bash

Arseni Kavalchuk — Sun, 20 Oct 2024 13:51:14 +0000

In Bash, matching strings against regular expressions (regex) is a common task for parsing and validating data. Bash offers multiple ways to perform regex matching, including using the grep command, and more importantly, the =~ test expression for conditional checks directly in Bash scripts. In this article, we'll explore different approaches to matching strings with regex in Bash, with a focus on the =~ operator.

Ways to Check a String Against a Regex in Bash

Bash provides several tools to check strings against regex patterns. Here are the most common methods:

Using the grep Command

The grep command is a powerful tool to search for patterns in files or standard input. It supports regex matching by default and is widely used for string searching.

echo "teststring" | grep -E "test.*"

Using =~ Test Expression

Bash built-in conditional expressions allow regex matching using the =~ operator within the test [[ ]]. This approach is efficient for matching strings in scripts without relying on external commands like grep.

if [[ "teststring" =~ ^test ]]; then
  echo "Matches!"
else
  echo "No match!"
fi

Using awk

Another way to match regex in bash is with the awk command, which has built-in regex support.

echo "teststring" | awk '/test/'

In this article, we will focus on the =~ operator as it is an efficient and versatile tool for regex matching in Bash scripts.

What are Regular Expressions?

Regular Expressions (regex) are sequences of characters that form search patterns, typically used for pattern matching in strings. They allow users to match complex patterns in text, making them a powerful tool for data parsing, validation, and text processing. Regex is used in many programming languages and tools like Perl, Python, JavaScript, grep, and more.

Basic Symbols and Patterns

Regular expressions consist of literals and special characters (metacharacters) that define the search pattern. Some of the most commonly used regex symbols include:

Dot .: Matches any single character except a newline.
- Example: a.b matches acb, a1b, etc.
Caret ^: Anchors the match at the start of a string.
- Example: ^test matches strings starting with test.
Dollar $: Anchors the match at the end of a string.
- Example: test$ matches strings ending with test.
Asterisk *: Matches zero or more occurrences of the preceding character or group.
- Example: ab*c matches ac, abc, abbc, etc.
Plus +: Matches one or more occurrences of the preceding character or group.
- Example: ab+c matches abc, abbc, but not ac.
Square Brackets ([]): Matches any one of the enclosed characters.
- Example: [abc] matches a, b, or c.
Escape Sequence \: Escapes special characters, allowing them to be treated as literals.
- Example: \.com matches .com instead of treating . as a wildcard.
Parentheses (): Groups multiple characters or expressions.
- Example: (ab)+ matches ab, abab, etc.
Pipe |: Acts as a logical OR operator to match different alternatives.
- Example: a|b matches a or b.

Regex Pattern Examples

Here are a few examples of common regex patterns:

Email validation: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$. This pattern matches simple email addresses.
Phone number: ^$\d{3}$ \d{3}-\d{4}$. Matches phone numbers in the format (123) 456-7890.
URLs: ^https?:\/\/[^\s/$.?#].[^\s]*$. Matches URLs starting with http or https.

Regular expressions are invaluable in scripting for tasks like validation, substitution, and parsing of structured text.

Using =~ Test Expression in Bash

The =~ operator allows you to perform regex matching directly within Bash scripts, which is especially useful for writing conditional logic based on patterns. Let's explore its usage with an example of matching a host name that follows a canonical domain pattern, such as cdn.mydomain.com.

Example 1: Basic Domain Name Matching

Here is a simple Bash script that uses =~ to check if a string matches a domain pattern:

#!/bin/bash

hostname="cdn.mydomain.com"

if [[ $hostname =~ ^cdn\.[a-zA-Z0-9]+\.[a-z]{2,}$ ]]; then
  echo "Valid CDN domain"
else
  echo "Invalid domain"
fi

Explanation:

^cdn\. ensures the hostname starts with cdn..
[a-zA-Z0-9]+ matches the domain name portion (letters and numbers).
\.[a-z]{2,}$ matches the top-level domain (like .com, .net).

Example 2: Matching Subdomains

You can also expand this logic to handle more complex subdomain patterns:


#!/bin/bash

hostname="static.cdn.mydomain.com"

if [[ $hostname =~ ^[a-z]+\.(cdn\.)[a-zA-Z0-9]+\.[a-z]{2,}$ ]]; then
  echo "Valid subdomain"
else
  echo "Invalid subdomain"
fi

This example allows the first part of the hostname to be dynamic, matching subdomains like static.cdn.mydomain.com or images.cdn.mydomain.com.

Example 3: Extracting Parts of a Domain

In some cases, you may want to capture parts of the string using regex groups and BASH_REMATCH to extract relevant information:

#!/bin/bash

hostname="images.cdn.mydomain.com"

if [[ $hostname =~ ^([a-z]+)\.(cdn\.)[a-zA-Z0-9]+\.[a-z]{2,}$ ]]; then
  echo "Subdomain: ${BASH_REMATCH[1]}"
else
  echo "No match"
fi

In this case, ${BASH_REMATCH[1]} will store the first captured group, i.e., the subdomain (images in this case).

Summary

Matching strings with regular expressions in Bash is a common task for processing and validating input. While grep and other external tools provide regex capabilities, the =~ operator is a native Bash feature for in-line regex matching, making it efficient and easy to use in scripts. By mastering regular expressions and using the =~ test expression, you can handle complex pattern matching, validate data like domain names, and even extract specific parts of strings for further processing in your Bash scripts.

DEV Community: Arseni Kavalchuk

Coding Agents for Software Engineers

Architecture, Context, and Efficient Usage

1️⃣ What Is a Coding Agent?

2️⃣ General Architecture of a Coding Agent

1. Indexing Layer

2. Context Builder

3. LLM Inference Layer

4. Tool Layer

5. Loop Controller

3️⃣ What Is the Context Window?

4️⃣ Where Does Tokenization Happen?

5️⃣ What Actually Consumes Tokens?

6️⃣ What Makes “Good Quality” Context?

✅ Relevant

✅ Structured

✅ Deterministic

✅ Minimal but sufficient

7️⃣ What Actually Improves Coding Responses?

1️⃣ Clear Scope

2️⃣ Explicit Constraints

3️⃣ Defined Output Format

4️⃣ Plan-First Workflow

8️⃣ Scratchpads and Plan Files

9️⃣ Efficient Project Structure for Coding Agents

AGENTS.md should contain:

🔟 Efficient Coding Agent Usage Patterns

Pattern A — Constrained Patch

Pattern B — Incremental Execution

Pattern C — Scope Locking

1️⃣1️⃣ What NOT to Do

1️⃣2️⃣ Big Context Myth

1️⃣3️⃣ Mental Model for Engineers

1️⃣4️⃣ Core Optimization Principles

Final Takeaway

Effective Ways to Use Locks in Kotlin

1. Using ReentrantLock with lock() and unlock()

Example:

2. Using withLock Extension Function

Example:

3. Using synchronized

Example:

4. Using ReadWriteLock

Example:

5. Using Coroutines and Mutex

Example:

6. Using Atomic Variables

Example:

When to Use Each?

iOS String to Kotlin ByteArray Performance Analysis

Kotlin ByteArray API in iOS

KotlinByteArray Interface

Using Native APIs in KMP

Working with Native Pointers

Default ByteArray Handling

Optimizing with memcpy

Testing Approaches

Swift Implementations

Loop Copy

Data Pointer with readBytes

Data Pointer with memcpy

UTF8 CString with readBytes and memcpy

Benchmark Results

Insights

Conclusion

Enhance iOS Development with Kotlin Multiplatform Library

Setting Up the Kotlin Mutliplatform Library in Android Studio

Key Steps:

Application Architecture and Business Logic

Building the XCFramework

Steps to Build the XCFramework:

Sample Swift UI Application

Example Workflow:

Importing the XCFramework into Xcode

Implementing KMP Interfaces in Swift

Conclusion

Modern Dependency Injection with Koin: The Smart DI Choice for 2025

1. Kotlin-First Design

Basic Dependency Definition in Koin:

Explanation:

1. Using `ReentrantLock` with `lock()` and `unlock()`

2. Using `withLock` Extension Function

3. Using `synchronized`

4. Using `ReadWriteLock`

5. Using Coroutines and `Mutex`

`KotlinByteArray` Interface

Optimizing with `memcpy`

Data Pointer with `readBytes`

Data Pointer with `memcpy`

UTF8 CString with `readBytes` and `memcpy`