# kotlin-native Published articles for kotlin-native. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Our Droidcon US 2026 Picks - Sam Hill DevFeed: [Our Droidcon US 2026 Picks - Sam Hill]() Original publisher: [Read original article]() Published: 2026-07-14T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Mobile](), [multiplatform](), [Kotlin](), [kotlin-native](), [AI Development](), [Artificial Intelligence](), [Rust](), [Testing](), [Gradle](), [scaling]() Tags: [2026](), [ai](), [ai-development](), [android](), [droidcon](), [gradle](), [ios](), [js](), [kmp](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [multiplatform](), [rust]() ### AI overview Touchlab previews selected Droidcon USA 2026 talks covering AI and cross-platform mobile development, Kotlin Native project structures, KMP integration with Rust, migration decisions, and mobile testing. ### Source excerpt With Droidcon right around the corner, here are the talks we are most excited about ## Beyond Positions: Kotlin's New Name-Based Destructuring DevFeed: [Beyond Positions: Kotlin's New Name-Based Destructuring]() Original publisher: [Read original article]() Author: Nav Singh Published: 2026-03-18T01:24:50Z Content type: tutorial Language: en Sources: [Stories by Nav Singh 🇨🇦 on Medium]() Topics: [Kotlin](), [Compiler](), [properties]() Tags: [android](), [android-app-development](), [androiddev](), [compiler](), [data-class](), [kotlin](), [kotlin-2](), [kotlin-native](), [properties]() ### AI overview This tutorial explains Kotlin 2.3.20's experimental name-based destructuring declarations, which match variables to properties instead of relying on componentN() position. It also covers the compiler option and supported modes. ### Source excerpt Image generated using Perplexity Name-based destructuring declarations were introduced in Kotlin 2.3.20 and match variables to properties rather than relying on position-based componentN(). Previously, destructive declarations used position-based destruction: data class User(var firstName: String, var lastName: String) val user = User("Alice", "Husseini") // componentN() val(firstName,lastName) = user println(firstName) println(lastName)Drawback of the componentN() based approach Destructuring relies on the order of componentN() functions, lastName receives the value of firstName, and firstName receives the value of lastName 👇 data class User(var firstName: String, var lastName: String) val user = User("Alice", "Husseini") // componentN() val(lastName,firstName) = user println(firstName) -> Husseini println(lastName) -> AliceName-based destructuring ✨ It's an Experimental feature. We can control how the compiler interprets destructuring declarations with the -Xname-based-destructuring compiler option. kotlin { // .. compilerOptions { freeCompilerArgs.add("-Xname-based-destructuring=only-syntax") } }Each variable refers to a property by name.val user = User("Alice", "Husseini") // Name-based destructuring (val firstName = firstName, val lastName = lastName) = userModeshttps://kotlinlang.org/docs/whatsnew2320.html#languageMode -- Name-Mismatch⚠ Warning ⚠Name-Mismatch warningMode -- Complete Position-based destructuring using square brackets []: data class User(var firstName: String, var lastName: String) val user = User("Alice", "Husseini") // componentN() val [firstName,lastName] = userReferences What's new in Kotlin 2.3.20 | Kotlin Stay in touch https://www.linkedin.com/in/navczydev/ JavaScript is not available. navczydev - Overview navczydev.bsky.social Beyond Positions: Kotlin's New Name-Based Destructuring was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story. ## The KotlinConf 2026 talks that we're excited about - Kevin Schildhorn DevFeed: [The KotlinConf 2026 talks that we're excited about - Kevin Schildhorn]() Original publisher: [Read original article]() Published: 2026-03-03T00:00:00Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Kotlin](), [compose-multiplatform](), [kotlin-native](), [iOS development](), [ui](), [amazon](), [Library]() Tags: [amazon](), [android](), [compose-multiplatform](), [ios](), [ios-development](), [js](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [kotlinconf](), [library](), [talks](), [ui]() ### AI overview A Touchlab commentary selects KotlinConf 2026 talks covering Kotlin/Native integration, Kotlin Multiplatform project organization and compilation times, Compose Multiplatform UI performance and animation, and iOS development with KMP at Amazon. ### Source excerpt The KotlinConf 2026 schedule was recently announced and there are a lot of talks to be excited about. We decided to compile a list of the talks we're excited to see. ## Kotlin Coroutines and Swift DevFeed: [Kotlin Coroutines and Swift]() Original publisher: [Read original article]() Published: 2025-09-15T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [kotlin-coroutines](), [Swift](), [Kotlin Multiplatform](), [Structured concurrency](), [async/await](), [kotlin-flow](), [kotlin-native](), [iOS]() Tags: [async](), [cancellation](), [coroutines](), [how-to](), [kotlin](), [kotlin-flow](), [kotlin-multiplatform](), [kotlin-native](), [structured-concurrency](), [swift](), [workshop-learning-programming]() ### AI overview This tutorial explains how to bridge Kotlin Coroutines and Swift's async/await and structured concurrency in Kotlin Multiplatform iOS projects. It covers suspending functions, exception conversion, Kotlin Flow to AsyncSequence, and calling Swift async functions from Kotlin. ### Source excerpt How to use Kotlin Coroutines in Swift projects, or Swift libraries from Kotlin Coroutines. ## SKIE Subplugin API for Kotlin Multiplatform Projects DevFeed: [SKIE Subplugin API for Kotlin Multiplatform Projects]() Original publisher: [Read original article]() Published: 2025-01-17T00:00:00Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [Kotlin](), [kotlin compiler](), [kotlin-native](), [Library]() Tags: [changes](), [compilation](), [complex](), [ios](), [kotlin](), [kotlin-compiler](), [kotlin-multiplatform](), [kotlin-native](), [meta-programming](), [multiplatform](), [plugin](), [skie]() ### AI overview This article introduces SKIE's undocumented subplugin API and explains how it can be used within a Kotlin Multiplatform project. It describes compatibility and build-complexity considerations across Kotlin and SKIE versions, and cautions that the API may change. ### Source excerpt Generate Swift code for your Kotlin Multiplatform project using SKIE subplugins. ## SQLDelight 2.0.1 fixes a Kotlin/Native thread-safety bug DevFeed: [SQLDelight 2.0.1 fixes a Kotlin/Native thread-safety bug]() Original publisher: [Read original article]() Published: 2023-12-21T02:05:15Z Content type: release Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [kotlin-native](), [bug](), [releases]() Tags: [bug](), [kotlin-multiplatform](), [kotlin-native](), [release](), [sqldelight]() ### AI overview SQLDelight 2.0.1 includes a fix for a Kotlin/Native thread-safety bug related to concurrent database operations, along with other fixes. The article recommends upgrading to the new version. ### Source excerpt The 2.0.1 update for SQLDelight is out now and features a crucial bug fix addressing thread safety issues in Kotlin Native. ## KMM: What's Under the hood? DevFeed: [KMM: What's Under the hood?]() Original publisher: [Read original article]() Author: Codeangi Published: 2023-02-22T15:58:32Z Content type: tutorial Language: en Sources: [ymedialabs-innovation - Medium]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Mobile](), [multiplatform](), [kotlin-native](), [LLVM](), [Compiler](), [JavaScript](), [toolchain](), [Development]() Tags: [compilation](), [development](), [javascript](), [kmm](), [kotlin](), [kotlin-beginners](), [kotlin-multiplatform](), [kotlin-native](), [llvm](), [mobile](), [mobile-development](), [multiplatform](), [toolchain]() ### AI overview This article explains Kotlin Multiplatform Mobile (KMM), focusing on how developers can share business logic, data, and connectivity implementation between Android and iOS. It also describes Kotlin/Native compilation through LLVM and Kotlin/JS compilation to JavaScript. ### Source excerpt source There have been many tools for cross-platform development before but offered so little in terms of sharable code, there was always an overhead of writing and maintaining applications in a set-predetermined technology such as Phonegap, ReactNative, and Flutter. Kotlin provides a huge leeway in writing sharable code, especially when you are developing Mobile applications for Android and iOS with similar features. In the real world, it translates into fewer lines of code, fewer bugs, less time, and of course lesser cost of development. Whether you are starting a new project or adding a new feature to an existing one. This article is an effort to interpret KMM in layman's terms, knowing programming helps but is not mandatory.Topics Include: What is KMM, How it works, the Good, and the Bad.source Kotlin is a cutting-edge yet established programming language that offers a range of benefits for developers. One of the key use cases for Kotlin is its ability to share code between mobile platforms through Kotlin Multiplatform Mobile (KMM). By using KMM, developers can create cross-platform mobile apps and share crucial elements like business logic, data, and connectivity implementation between Android and iOS. Kotlin-Native In order to use Kotlin code in iOS, the Kotlin code is first compiled to LLVM bytecode using the Kotlin/Native compiler. LLVM (Low Level Virtual Machine) is a collection of modular and reusable compiler and toolchain technologies. The LLVM bytecode is then compiled using the iOS toolchain and linked with the iOS runtime libraries. The resulting binary is an iOS application bundle (an .app directory) that contains the Kotlin code and the Swift runtime. When the app is run, the Swift runtime loads the Kotlin code and uses it as if it were native Swift code. Kotlin/JS Kotlin/JS provides the ability to trans-compile Kotlin code, the Kotlin standard library, and any compatible dependencies to JavaScript. The current implementation of Kotlin/JS targets ES ## The Evolution of Kotlin Multiplatform Mobile - 2022 Edition - Russell Wolf DevFeed: [The Evolution of Kotlin Multiplatform Mobile - 2022 Edition - Russell Wolf]() Original publisher: [Read original article]() Published: 2022-10-31T18:13:15Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [kotlin multiplatform mobile](), [multiplatform](), [Kotlin](), [Mobile](), [kotlin-native](), [Gradle](), [cocoapods](), [Library](), [swift-package-manager](), [swift-package](), [Maven Central]() Tags: [cocoapods](), [gradle](), [jetbrains](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-mobile](), [kotlin-native](), [libraries](), [maven-central](), [mobile](), [multiplatform]() ### AI overview This retrospective traces Kotlin Multiplatform Mobile from its early experimental stage, when Kotlin/Native memory management, Gradle configuration, and Xcode integration were difficult, to a more mature state with improved memory management, iOS integration through CocoaPods and Swift Package Manager, and better Kotlin-to-Swift interoperability. It also describes growth in the KMM library ecosystem, from about five published libraries in 2018 to more than 1,000 relevant artifacts on Maven Central. ### Source excerpt Kotlin Multiplatform has come a long way in the last few years. As someone who was there when the KMP community first formed, I've seen the ecosystem grow from a few developers trying things out experimentally to a growing number of teams using it in their production apps. With the Kotlin Multiplatform Mobile Beta freshly announced, it's a neat moment to look back on how far everything has come. How It Started In the early days, KMP wasn't very easy for new users. ## Introducing KMMBridge for Teams DevFeed: [Introducing KMMBridge for Teams]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2022-10-10T20:10:44Z Content type: release Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin Multiplatform](), [Mobile](), [Gradle](), [SDKs](), [Tooling](), [Xcode]() Tags: [binaries](), [build-tools](), [gradle](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [mobile](), [sdk](), [xcode]() ### AI overview Touchlab announces KMMBridge, part of its Faktory tooling suite, to help mobile teams publish and consume pre-built Kotlin Multiplatform Mobile Xcode Framework binaries as an internal SDK. The article explains the Internal SDK Flow, in which a team member or CI builds and publishes the framework so iOS developers can integrate it without building Kotlin locally. ### Source excerpt Today we are announcing KMMBridge, part of Touchlab's new Faktory* tooling suite. This set of build tools allows mobile teams to successfully publish shared code faster than ever with Kotlin Multiplatform Mobile. Specifically targeted at iOS publishing, teams can now implement the Internal SDK Flow approach, today's best practice to quickly integrate KMM into production app builds. GitHub - touchlab/KMMBridge: KMMBridge is a set of Gradle tooling that facilitates publishing and consuming pre-built KMM (Kotlin Multiplatform Mobile) Xcode Framework binaries. See https://touchlab.github.io/KMMBridge/intro/ to get started. KMMBridge allows teams to publish and integrate Kotlin Multiplatform Mobile (KMM) Xcode Frameworks as an internal SDK.When you're ready to get started, head to our KMMBridge Quick Start Tutorial.Why We Built a Team-Focused Tool Touchlab has spent years working with teams at different stages of their Kotlin Multiplatform journey. Evaluating KMP, putting KMP into production, and yes, even a fair bit of time talking to teams who looked at KMP and decided against it. One of the key lessons we've learned seems obvious in retrospect. Different types of teams work in different ways. Of course, every team is different. Every situation will be different. However, there are common patterns. Out of the box, the KMP and the Kotlin/Native toolkit will let you build an Xcode Framework, then integrate it locally into your Xcode project. This works well if everybody on the team builds Kotlin. And in an ideal world, everybody would be able to build Kotlin. But in the real world, most teams who have succeeded followed the Internal SDK Flow approach. The Internal SDK Flow Approach As with adopting any technology on a team, early wins help build momentum and confidence so the team can unlock the full potential over time. The Internal SDK Flow has emerged as the best practice to get faster ROI when adopting KMM. At its simplest, this approach means the Kotlin Xcode Framew ## Apollo Kotlin: New Multiplatform Memory Manager DevFeed: [Apollo Kotlin: New Multiplatform Memory Manager]() Original publisher: [Read original article]() Author: Benoit Lubek Published: 2022-08-09T12:05:22Z Content type: news Language: en Sources: [Apollo Blog]() Topics: [Kotlin Multiplatform](), [kotlin-multiplatform-libraries](), [Concurrency]() Tags: [apollo](), [concurrency](), [immutability](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [library](), [mobile](), [multiplatform](), [multithreading](), [performance](), [unit-tests]() ### AI overview Apollo Kotlin 3.5.0 adopts Kotlin Native's new memory manager. The change removes several threading and immutability restrictions, including the requirement to access the library exclusively from the Main thread on Apple targets. Initial benchmarks indicate performance improvements of up to 45%. ### Source excerpt Back in May, we shared about how Apollo Kotlin started supporting the Hierarchical project structure. Following the Kotlin Multiplatform ecosystem, here is some more news, this time about the new Memory Manager. Kotlin Native's Memory Manager Since its early days, Kotlin Native has had specific rules regarding multithreading and immutability: - objects could only be accessed from the thread they were created in - unless they had been "frozen", in which case they could be accessed by multiple... ## What's new with Multiplatform in Apollo Kotlin DevFeed: [What's new with Multiplatform in Apollo Kotlin]() Original publisher: [Read original article]() Author: Benoit Lubek Published: 2022-05-25T10:25:23Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Development]() Tags: [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [latest-release](), [mobile](), [multiplatform](), [release]() ### AI overview This article describes updates to Apollo Kotlin's Kotlin Multiplatform support. Apollo Kotlin 3.3.0 adopts the hierarchical project structure convention, and the project is compatible with Kotlin Native's new memory manager while retaining compatibility with the older manager for libraries. The article also discusses Kotlin version requirements and future adoption plans. ### Source excerpt " Write once, run anywhere ": that age-old dream is still alive today. That is why, when making Apollo Kotlin (then known as Apollo Android) a 100% Kotlin codebase, making it also Multiplatform was inevitable. The potential advantages for users would well be worth the overhead of writing agnostic code. Since then, the Multiplatform ecosystem has been evolving and Apollo Kotlin is keeping up with it. Hierarchical project structure Let's start with the hierarchical project structure (a.k.a. ## Installing the xcode-kotlin Plugin with a Kotlin Native CLI DevFeed: [Installing the xcode-kotlin Plugin with a Kotlin Native CLI]() Original publisher: [Read original article]() Published: 2022-05-18T18:34:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Xcode](), [Command-line interface](), [FIRST Robotics Competition]() Tags: [cli](), [debugging](), [developer-experience](), [developer-tooling](), [featured](), [homebrew](), [ios](), [kotlin-multiplatform](), [kotlin-native](), [xcode]() ### AI overview This article explains replacing the xcode-kotlin plugin's installation script with a Kotlin Native CLI tool. The tool configures the plugin across installed Xcode versions, supports Homebrew installation, removes certain Load Bundle prompts, and provides diagnostic commands. ### Source excerpt The xcode-kotlin plugin allows debugging of Kotlin code running in an iOS application directly from Xcode. ## Speeding up Kotlin Multiplatform DevFeed: [Speeding up Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2022-05-18T09:11:24Z Content type: tutorial Language: en Sources: [YAZIO Engineering - Medium]() Topics: [Kotlin Multiplatform](), [build times](), [Gradle](), [ide](), [Kotlin](), [iOS](), [Android](), [watchOS]() Tags: [android](), [android-studio](), [build-times](), [gradle](), [ide](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [watchos]() ### AI overview The article describes YAZIO's use of Kotlin Multiplatform to share business logic between Android and iOS while maintaining many Gradle modules. It explains that selectively removing Apple targets during common development can reduce Gradle Sync and IDE indexing time, and that this also enables Gradle Configuration Cache in the described setup. ### Source excerpt At YAZIO we are heavily investing into Kotlin Multiplatform and use Kotlin to share all business logic between the iOS and the Android App. Naturally this also leads to a lot of code. Since we modularize our software properly to achieve encapsulation and fast incremental build times, it also means a lot of Gradle modules. 70 modules and counting, to be more precise. And for Kotlin Multiplatform, a lot of Gradle modules means a very long Gradle Sync and IDE indexing time. We tried to mitigate some of that by switching to the latest Macbook Pros, which helped quite a bit. But with all the targets we have (1x Android, 3 x iOS, 4 x watchOS), it still takes 6 minutes for Gradle to sync after adding a new Gradle module. This is a very long time, and worse: It encourages developers to not change any build logic at all and leads to them not adding any more modules. Is moving these files into their own module really worth the six-minute wait?Selectively removing targets The idea here is simple: Fewer targets -- less sync time. We rarely need to touch the platform-specific source sets anyway and 99% of the time, we are developing solely in commonMain . This means that while developing, we can just remove the Apple targets. And it turns out: Apple targets have the most effect on sync times. This is due to the Commonizer, large native distributions and a complicated mechanism that allows you to see what's in your classpath from within the IDE. This is pretty simple to implement. First, add a new property to your gradle.properties file: https://medium.com/media/389dc8cfc03487a54eaeb6f2c62a81f9/href Now, in your build.gradle.kts file(s), simply check for that property before creating the native targets. https://medium.com/media/330ad55c6d767fbd4bfcb96822dc4639/href Et voilà -- it's not blazingly fast, but at least we can work with it. Bonus: Configuration Cache 🎉 The other big benefit that we can now make use of is Gradles Configuration Cache. With the iOS targets, Kotlin Multiplat ## Speeding up Kotlin Multiplatform DevFeed: [Speeding up Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2022-05-18T09:10:34Z Content type: tutorial Language: en Sources: [Stories by Paul Woitaschek on Medium]() Topics: [Kotlin Multiplatform](), [build times](), [Gradle](), [iOS](), [watchOS](), [Android](), [ide]() Tags: [android](), [android-studio](), [build-times](), [gradle](), [ide](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [watchos]() ### AI overview This tutorial describes how YAZIO reduces Kotlin Multiplatform development overhead by selectively removing Apple targets during common development. It discusses Gradle module growth, long synchronization and IDE indexing times, and using Gradle Configuration Cache when iOS targets are absent. ### Source excerpt At YAZIO we are heavily investing into Kotlin Multiplatform and use Kotlin to share all business logic between the iOS and the Android App. Naturally this also leads to a lot of code. Since we modularize our software properly to achieve encapsulation and fast incremental build times, it also means a lot of Gradle modules. 70 modules and counting, to be more precise. And for Kotlin Multiplatform, a lot of Gradle modules means a very long Gradle Sync and IDE indexing time. We tried to mitigate some of that by switching to the latest Macbook Pros, which helped quite a bit. But with all the targets we have (1x Android, 3 x iOS, 4 x watchOS), it still takes 6 minutes for Gradle to sync after adding a new Gradle module. This is a very long time, and worse: It encourages developers to not change any build logic at all and leads to them not adding any more modules. Is moving these files into their own module really worth the six-minute wait?Selectively removing targets The idea here is simple: Fewer targets -- less sync time. We rarely need to touch the platform-specific source sets anyway and 99% of the time, we are developing solely in commonMain . This means that while developing, we can just remove the Apple targets. And it turns out: Apple targets have the most effect on sync times. This is due to the Commonizer, large native distributions and a complicated mechanism that allows you to see what's in your classpath from within the IDE. This is pretty simple to implement. First, add a new property to your gradle.properties file: https://medium.com/media/389dc8cfc03487a54eaeb6f2c62a81f9/href Now, in your build.gradle.kts file(s), simply check for that property before creating the native targets. https://medium.com/media/330ad55c6d767fbd4bfcb96822dc4639/href Et voilà -- it's not blazingly fast, but at least we can work with it. Bonus: Configuration Cache 🎉 The other big benefit that we can now make use of is Gradles Configuration Cache. With the iOS targets, Kotlin Multiplat ## MocKMP : a Mocking processor for Kotlin/Multiplatform DevFeed: [MocKMP : a Mocking processor for Kotlin/Multiplatform]() Original publisher: [Read original article]() Author: Salomon BRYS Published: 2022-01-17T13:29:28Z Content type: tutorial Language: en Sources: [Kodein Koders - Medium]() Topics: [Kotlin Multiplatform](), [Mocking](), [Code](), [test](), [Gradle](), [Programming]() Tags: [gradle](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [ksp](), [mocking](), [multiplatform](), [test](), [tests]() ### AI overview This article introduces MocKMP, a mocking solution for Kotlin Multiplatform. It explains why JVM reflection-based mocking does not work for Kotlin/JS and Kotlin/Native, and describes using Kotlin Symbol Processing to generate mock implementations at compile time. MocKMP includes a runtime API, a symbol processor, test helpers, and a Gradle plugin. ### Source excerpt MocKMP : a Mocking processor for Kotlin/MultiplatformPhoto by Stefano Pollio on Unsplash Recently, when working with Deezer on a Kotlin/Multiplatform project, we came across multiple unit tests that were written in src/androidTest/kotlin, meaning that they were only run on Android. When investing why that choice was made, the answer became evident : there is no mocking system on Kotlin/Multiplatform, and Mockk only supports JVM & Android. Mocking with reflection The JVM reflection is an amazing powerful API, allowing libraries to instrument existing classes and create new implementations at run time. When you write : https://medium.com/media/28a2defcfc5197a7e44d270d4414acd1/href ...the mocking library : Creates a new implementation of the Repository type Sets the behaviour of the getUser method on this mock to return a fake User, whatever the id parameter. Furthermore, a JVM mocking framework is able to create "fake objects" on demand: https://medium.com/media/2e91c376131e77315f319705fd45e8b2/href All of that is done at run time, by instrumenting the JVM runtime, which is not possible with 2 of the 3 types of targets of Kotlin/Multiplatform (Kotlin/JS & Kotlin/Native). A Kotlin Symbol Processor Google KSP allows to inspect Kotlin code at compile time. In essence, it provides a reflection API available at compile time (rather than at run time). KSP also allows to generate Kotlin code according to the code being inspected. This is meta-programming: writing code to generate code according to code. With a Kotlin Symbol Processor, we can generate implementation of interfaces at compile time, and delegate the implementation of said implementations to a mocker delegate. Introducing MocKMP The MocKMP project consists of multiple moving parts that allow to easily generate and configure mocks: A runtime that provides the mocker API A Kotlin Symbol Processor that generates configurable mocks A test helper library to make the use of mocks as easy as possible A Gradle plugin to ma ## Kermit and Crashlytics DevFeed: [Kermit and Crashlytics]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2022-01-05T19:59:46Z Content type: article Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin Multiplatform](), [Crashlytics](), [Kotlin](), [iOS](), [Mobile](), [Monitoring](), [Logging]() Tags: [crash-reporting](), [crashlytics](), [exception](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [logging](), [mobile](), [monitoring]() ### AI overview This article explains how Kermit, a Kotlin Multiplatform logging library, integrates with Crashlytics for crash reporting. It focuses on iOS, where Kotlin exceptions can produce reports that omit the Kotlin stack and exception message, and describes registering an uncaught exception handler to send that information in a separate non-fatal report. The approach results in two reports for each crash event. ### Source excerpt Cross post from https://touchlab.co/kermit-and-crashlytics/ Kermit is a Kotlin Multiplatform logging library. The log is configured on each platform to write to various, potentially platform-specific, outputs, but can be called from shared "common" Kotlin code. Crash reporting tools like Crashlytics allow you to get error reports from remote devices running your software. These tools are very common in mobile app development, and in most cases are critical for monitoring application health in production. Crash reporting for KMP involves a setup similar to other platform-specific libraries that you want to use in a KMP context. You configure each platform according to the documentation from the software vendor, then have some common Kotlin code that can interact with the platform-specific library. Crash reporting is a bit of a special case for iOS. It's a long story, but the summary is the JVM and Kotlin throw unchecked exceptions up the stack, and if unhandled, eventually wind up in a catch-all handler. On iOS, exceptions don't work the same way. When a crash happens the runtime essentially stops and a handler is called. The crash library gathers the state of each thread's stack and sends that to the server. If you call a Kotlin function on iOS and an exception is thrown from somewhere in that Kotlin call stack, the Kotlin runtime will bubble the exception up the stack like it would on the JVM. At the "border", where you first called the Kotlin code, the Kotlin runtime will trigger a crash. If you look at the crash reports you'll see konan::abort() . That's the Kotlin runtime (internally called "konan") force-killing the process. That "works", and if you don't need symbolicated Kotlin crash info, then you're done! However, all of the crash reports will lose potentially vital info. Specifically the Kotlin stack and the exception message. To get that info, we register an uncaught exception handler with the Kotlin runtime, and when a crash originates in Kotlin code, a ## KMM Memory Model -- when to switch? DevFeed: [KMM Memory Model -- when to switch?]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2021-12-23T19:34:40Z Content type: opinion Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin](), [Coroutines](), [Concurrency](), [Library](), [Maintainers](), [releases]() Tags: [bug-fixes](), [concurrency](), [coroutines](), [kmm](), [kmp](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [maintainers](), [releases]() ### AI overview The article discusses when developers should adopt Kotlin Multiplatform's new memory model. It reports that Touchlab plans to use the new model by default for development work, while native-mt releases are being phased out, and considers implications for libraries such as Stately, Atomic-FU, and Koin. ### Source excerpt KMM Memory Model -- when to switch?Brain. It's a brain.Cross posted from https://touchlab.co/kmm-memory-model-when-to-switch/ Touchlab will be defaulting to the "new" memory model for anything that's in dev and/or not hitting production for a few months. That decision will be reviewed if there's some wild performance issue or bug, but otherwise, we're just doing it. On Slack, the team collectively decided to make the switch this afternoon. Why now? Well, the urgency this morning was largely driven by this. 1.6.x will be the last series of native-mt releases and we are effectively decommissioning native-mt in the favour of the new memory model that is supported out-of-the-box in 1.6.0 coroutines release....We encourage developers to try out and evaluate the new MM: that's our bet, we are investing our resources, development and testing in it and the quality of regular coroutine releases (including pre-release testing, a priority of the bug-fixes, extensive support of existing features and so on) is much higher than of native-mt builds. The general vibe is to wait until it's not "experimental", but if you've been working with KMP and Kotlin/Native for any length of time, you're probably used to "experimental". If you wait for something resembling "Beta", the rest of the community will probably have switched long before you did. Such is the life of an early adopter. Also, assuming the new model works "good enough", more people using it will speed up maturity through feedback. That's for client/app work. There are some decisions we (Touchlab), and other library maintainers, need to make around library decisions. Large portions of Stately, if not all of it, will probably be archived (discuss). However, we'll also need at least an OK implementation of concurrent collections. Next, while Atomic-FU covers a lot of what we'd want for concurrency primitives (atomics, locks, etc), we'll need a review to see if we want to completely switch over. Stately may continue on as a "simpl ## KMM Memory Model - when to switch? - Kevin Galligan DevFeed: [KMM Memory Model - when to switch? - Kevin Galligan]() Original publisher: [Read original article]() Published: 2021-12-22T18:52:04Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin](), [kotlin-native](), [Concurrency](), [Library](), [Maintainers](), [Testing]() Tags: [concurrency](), [kmm](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [library](), [maintainers](), [testing]() ### AI overview Touchlab explains why it plans to adopt Kotlin/Native's new memory model for development work and encourages developers to evaluate it. The article discusses the end of native-mt releases, expected library changes, and testing needs. ### Source excerpt Touchlab will be defaulting to the "new" memory model for anything that's in dev and/or not hitting production for a few months. That decision will be reviewed if there's some wild performance issue or bug, but otherwise, we're just doing it. ## Kermit KMP Logging 1.0 DevFeed: [Kermit KMP Logging 1.0]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2021-12-09T18:11:15Z Content type: release Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin Multiplatform](), [log management](), [Library](), [kotlin-multiplatform-libraries](), [Kotlin](), [configuration](), [Gradle]() Tags: [code](), [configuration](), [development](), [gradle](), [kmp](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [libraries](), [logging](), [multiplatform](), [release]() ### AI overview The article announces the stable release of Kermit, a Kotlin Multiplatform logging library. It describes the library as having a simple API, extensibility, performance focus, and progressively more sophisticated configuration, and notes release compatibility issues involving Kotlin 1.6.0 and Android publishing. ### Source excerpt Cross post from https://touchlab.co/kermit-kmp-logging-1-0/Kermit the Log. That's where the name came from. Today we're announcing the stable release of our logging library Kermit GitHub - touchlab/Kermit: Kermit by Touchlab is a Kotlin Multiplatform centralized logging utility. If you've been following me, I've given a few talks on Kotlin KMP library development. In my previous talks I gave some suggestions on what kinds of libraries the community needs. I went out of my way to say avoid building logging libraries. Even way back in 2019, there were already a few options for KMP, so I assumed that topic was handled. Don't build logging libraries After doing some digging, though, nothing really felt like it was done the way we wanted. Also, in early 2020, due in part due to circumstances we're all aware of, we had a few more hands available than planned. We had wanted everybody on the team to get a chance to work on a KMP library, and logging libraries are, if nothing else, conceptually straightforward. After some general architecture chats, the team dove in and made a dev version of Kermit. The plan was to try it out, get some feedback, then make a 1.0 and tell everybody! Then we got super busy. The good news is we got some extra time to think about the library design, and a lot more feedback than you'd think for something we never quite announced. With that feedback, plus more lessons learned shipping KMP code in the meantime, we sat down and made a plan for Kermit 1.0. Kermit 1.0 Kermit has a simple API, is easy to extend, and is focused on performance. Getting started is very easy, but Kermit provides more sophisticated configuration as you move beyond dev into releasing your applications. Rather than a single long post that I'll never finish, we'll wrap this up with basic setup, then go deep on a few other topics in future posts. The list is subject to change, but look for posts on basic setup and usage, production setup, crash reporting integration, and a deep ## Kotlin Native -- Using swift, not Objective-C DevFeed: [Kotlin Native -- Using swift, not Objective-C]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2021-11-19T08:00:42Z Content type: tutorial Language: en Sources: [YAZIO Engineering - Medium]() Topics: [kotlin-native](), [Code generation](), [Swift](), [Objective-C](), [Compiler]() Tags: [android](), [code-generation](), [compiler](), [interop](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [ksp](), [library](), [objective-c](), [swift]() ### AI overview This tutorial explains how YAZIO uses Kotlin Native for shared business logic while providing a Swift-native iOS API. It describes the limitations of Kotlin-to-Objective-C interoperability and shows how KSP and SwiftPoet can generate Swift mappings for Kotlin types such as enums and sealed classes. ### Source excerpt Kotlin Native -- Using Swift, not Objective-C At YAZIO we use Kotlin Native Extensively. The business logic of all new app features is exclusively written in Kotlin. In its core, every screen has one ViewModel which exposes a single Flow that the Android App and the iOS can consume to render the state. On Android, rendering the view state is no burden because it's the language we use in the Android App anyways. However this is different for iOS. While Swift does interop with Objective-C, the public API as seen from Swift is bad. A simple data class is exported as a regular class. The properties are not native Swift types. What should be a Bool becomes a KotlinBoolean. What should be come a Double becomes a KotlinDouble. But what we want is most of the times a struct with Swift types. These are the lesser evils, the greater ones are enums and sealed classes. In Objective-C, they both become regular classes. And therefore lose all the advantages they have when used from Swift. But what we want is a Swift enum. To overcome these restrictions for quite some time our iOS team has created mappings. There is a whole target, dedicated to mapping the Objective-C classes to Swift. Basically when developing a new feature, the whole public API is manually mapped to Swift. This is good because the result is a clean Swift-native API. But that's bad because it's extreme boilerplate and a real productivity killer. What if we could directly generate these mappings and use code generation to handle that for us? Turns out: There are two tools available that make it possible. The first one is KSP. It is basically a library that lets you implement a Kotlin compiler plugin and it gives you hooks to analyze the Kotlin Syntax Tree and generate code based on it. The second one is SwiftPoet. SwiftPoet is a library you can use to generate Swift code from Kotlin, similar to what KotlinPoet and JavaPoet do. Okay, let's get our handy dirty. For the basic setup, just follow the tutorial ## Kotlin Native -- Using swift, not Objective-C DevFeed: [Kotlin Native -- Using swift, not Objective-C]() Original publisher: [Read original article]() Author: Paul Woitaschek Published: 2021-11-19T07:21:13Z Content type: tutorial Language: en Sources: [Stories by Paul Woitaschek on Medium]() Topics: [kotlin-native](), [Kotlin](), [Swift](), [Code generation](), [Objective-C](), [Compiler](), [Library](), [Tutorial]() Tags: [android](), [code-generation](), [compiler](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [ksp](), [library](), [objective-c](), [swift](), [tutorial]() ### AI overview This developer article explains how YAZIO uses Kotlin Native for shared business logic while addressing the limitations of exposing Kotlin types through Objective-C to Swift. It describes manually mapping the generated API to Swift and introduces KSP and SwiftPoet as tools for generating Swift mappings and reducing boilerplate. ### Source excerpt Kotlin Native -- Using Swift, not Objective-C At YAZIO we use Kotlin Native Extensively. The business logic of all new app features is exclusively written in Kotlin. In its core, every screen has one ViewModel which exposes a single Flow that the Android App and the iOS can consume to render the state. On Android, rendering the view state is no burden because it's the language we use in the Android App anyways. However this is different for iOS. While Swift does interop with Objective-C, the public API as seen from Swift is bad. A simple data class is exported as a regular class. The properties are not native Swift types. What should be a Bool becomes a KotlinBoolean. What should be come a Double becomes a KotlinDouble. But what we want is most of the times a struct with Swift types. These are the lesser evils, the greater ones are enums and sealed classes. In Objective-C, they both become regular classes. And therefore lose all the advantages they have when used from Swift. But what we want is a Swift enum. To overcome these restrictions for quite some time our iOS team has created mappings. There is a whole target, dedicated to mapping the Objective-C classes to Swift. Basically when developing a new feature, the whole public API is manually mapped to Swift. This is good because the result is a clean Swift-native API. But that's bad because it's extreme boilerplate and a real productivity killer. What if we could directly generate these mappings and use code generation to handle that for us? Turns out: There are two tools available that make it possible. The first one is KSP. It is basically a library that lets you implement a Kotlin compiler plugin and it gives you hooks to analyze the Kotlin Syntax Tree and generate code based on it. The second one is SwiftPoet. SwiftPoet is a library you can use to generate Swift code from Kotlin, similar to what KotlinPoet and JavaPoet do. Okay, let's get our handy dirty. For the basic setup, just follow the tutorial ## KMM Oddity #2: Initialization order of top-level properties DevFeed: [KMM Oddity #2: Initialization order of top-level properties]() Original publisher: [Read original article]() Author: Yev Kanivets Published: 2021-11-15T15:44:44Z Content type: tutorial Language: en Sources: [xorum.io - Medium]() Topics: [Kotlin Multiplatform](), [kotlin-native](), [Android](), [iOS](), [Redux]() Tags: [android](), [ios](), [kmm](), [kmp](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [mobile](), [redux]() ### AI overview This article examines an initialization-order oddity involving Kotlin top-level properties in Kotlin Multiplatform Mobile. It compares behavior when dependent properties are declared in one file or separate files, including differing initialization sequences in Android and iOS applications. ### Source excerpt Kotlin Multiplatform goes Beta this Spring (2022), so it removes all major hassles (Memory Model and Kotlin/Native concurrency, for example) which KMP developers face. But even with the Stable version (hopefully by the end of 2022), we are going to have a certain number of minor issues or simply oddities while using this relatively young technology (especially with Kotlin/Native). Most of them are already reported in Kotlin's YouTrack, so go check it before stressing out. I've encountered many such issues myself for the past two years with Kotlin Multiplatform Mobile. In this series of articles, I'll share my favorite oddities of KMM with explanations and workarounds (if possible). Top-level properties In Kotlin, we are able to declare top-level (or global) variables, which are accessible from anywhere in the given module or even the whole application. For example, let's say that we have a data class Order: https://medium.com/media/a25461d8a0d6b9b56cb9dd912331f029/href This class has a name and an optional dependency to another Order. The init block is here to help us understand when it's initialized. While it's generally a bad idea to declare instances of such class as a global variable, we are going to do it twice in the same file for now. As you can see, orderB depends on orderA, so it must be initialized first. https://medium.com/media/b290af047e51b599b293e0aca4e01fee/href It's done for demo purposes here, but a real application can require it as well (think about store, reducers, and middleware from Redux architectural pattern, which are all global variables by default). When run, we see the expected order of initialization in logs of both, Android and iOS applications: Init orderA / Init orderB. Single-file initialization order When we have all connected top-level variables in the same file, things are simple. To check it, swap the orderA with orderB. https://medium.com/media/25fc0522be792d1cfa0da6cbd4ec7f90/href Do you see? Android Studio will complain about ## The Evolution of Kotlin Multiplatform Mobile - 2022 Edition (OLD) - Russell Wolf DevFeed: [The Evolution of Kotlin Multiplatform Mobile - 2022 Edition (OLD) - Russell Wolf]() Original publisher: [Read original article]() Published: 2021-11-01T15:31:26Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Kotlin Multiplatform](), [kotlin multiplatform mobile](), [Kotlin](), [multiplatform](), [Library](), [Maven Central](), [jetbrains]() Tags: [evolution](), [jetbrains](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-mobile](), [kotlin-native](), [libraries](), [maven-central](), [mobile](), [multiplatform]() ### AI overview Russell Wolf reviews the evolution of Kotlin Multiplatform Mobile from its early experimental period to broader production use. The article describes improvements in Kotlin/Native memory management, Xcode integration, dependency distribution, Swift interoperability, and the growth of the KMM library ecosystem. ### Source excerpt Touchlab's Russell Wolf looks at how the evolution of KMM has been playing out since the first introduction of Kotlin Multiplatform to today ## Testing the Kotlin/Native Memory Model - Kevin Galligan DevFeed: [Testing the Kotlin/Native Memory Model - Kevin Galligan]() Original publisher: [Read original article]() Published: 2021-10-05T20:16:52Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [kotlin-native](), [Kotlin](), [Testing](), [Gradle](), [GitHub Actions]() Tags: [bugs](), [build](), [github-actions](), [gradle](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [open-source](), [testing]() ### AI overview This tutorial explains how to test Kotlin/Native's new memory model in an open-source library. Using Kermit as an example, it describes configuring Kotlin and memory-model versions with Gradle properties, running tests in GitHub Actions, and reporting bugs to help mature the platform. ### Source excerpt Kotlin/Native's strict memory model has been a common topic of interest and/or concern in the community for some time. The arrival of the new memory model will remove what many consider an adoption blocker. However, creating and testing a new memory model is a significant undertaking. [Next page]()