# Stories by Kevin Galligan on Medium Stories by Kevin Galligan on Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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 ## 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 ## 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 ## Testing the Kotlin Native memory model DevFeed: [Testing the Kotlin Native memory model]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2021-10-03T16:35:56Z Content type: tutorial Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin](), [kotlin-native](), [GitHub Actions](), [Gradle](), [Testing](), [Open Source](), [Xcode](), [macOS]() Tags: [build](), [github-actions](), [gradle](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [macos](), [memory](), [open-source](), [testing](), [xcode]() ### AI overview A practical guide to testing Kotlin/Native's experimental new memory model. It explains how to enable the model through Gradle properties, run library tests across Kotlin versions and memory-model configurations, and report bugs using a sample project. ### Source excerpt Memory joke 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. It is tempting to wait until the new memory model is "ready", but the community can help accelerate the maturing of the platform by testing the new model and reporting bugs. We are starting to run our open source library tests against the new memory model. Just turning it on for Kermit found a relatively minor issue. If you publish a library, it would be great if you could turn on the new memory model and see if things work. Although everybody's config is different, here's how we do it. Kermit's Kotlin version is in the gradle.properties file. GROUP=co.touchlab VERSION_NAME=1.0.0-rc4 KOTLIN_VERSION=1.5.31 # etc... Kermit/gradle.properties at main - touchlab/Kermit That makes turning on the memory model simple. We can pass in a different Kotlin version and memory model flag, both as gradle properties. Currently we run tests 3 times. First with Kotlin 1.5.31, which is our published version. Then Kotlin 1.6.0-M1, but with the strict memory model, then Kotlin 1.6.0-M1 and the new memory model. In the Github Actions script, here are the lines: - name: Build run: ./gradlew build --no-daemon --stacktrace - name: Build 1.6 run: ./gradlew build -PKOTLIN_VERSION=1.6.0-M1 --no-daemon --stacktrace - name: Build 1.6 nmm run: ./gradlew build -PKOTLIN_VERSION=1.6.0-M1 \ -Pkotlin.native.binary.memoryModel=experimental --no-daemon \ --stacktrace Param -PKOTLIN_VERSION=1.6.0-M1 sets the Kotlin verison, and -Pkotlin.native.binary.memoryModel=experimental turns on the new memory model. Also FYI, macos-latest is a little old and has Xcode 12.4. macos-11 has Xcode 12.5, which is required for Kotlin 1.6.0-M1. Obviously, if you run those once and they work fine, you don't need to leave them on. We ## Kotlin 1.5.30 and KMM/KMP DevFeed: [Kotlin 1.5.30 and KMM/KMP]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2021-08-27T16:15:39Z Content type: article Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Kotlin](), [multiplatform](), [kotlin-native](), [Concurrency](), [releases]() Tags: [concurrency](), [kmm](), [kmp](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [release]() ### AI overview The article discusses Kotlin 1.5.30 as a significant milestone for Kotlin Multiplatform and Kotlin Multiplatform Mobile. It focuses on the preview of Kotlin/Native's new memory model, which is intended to simplify shared-state access across threads, while noting that it was not yet recommended for production and that important questions remained. ### Source excerpt Kotlin 1.5.30 officially launched just now. There has been a steady stream of Kotlin releases over the last year or so, each with new features and fixes. In other words, business as usual. Since we (Touchlab) are plugging away, day in and out, working on client projects using KMM🐶, it can be easy to lose track of the bigger milestones. Kotlin 1.5.30 feels (numerically speaking) like just another point release, but this is a milestone advance for the platform. 1.5.30 presents a few big features, at least in preview, which will ultimately pave the way for "production ready" mainstream adoption of Kotlin shared code technology. Kotlin 1.5.30 is a turning point in KMP. Here's why.Memory Model Preview One of the most controversial aspects of Kotlin/Native is the concurrency and memory model. There are a lot of takes on it. Whether it was a good or bad thing, and why, is beyond the scope of today's post. However, I talked about it much more than anything else over the last few years because for KMM and KMP to grow, people would need to understand it. Still, it's been a significant blocker for some. That will be changing soon. I would not run the new memory model in production yet 🤞, but you can start experimenting with it now, and expect production deployments to pop up as we settle into 1.6 (I'm guessing :) 🚀. What is this memory model business you ask? Well, in some languages (Java, Swift, etc), multiple threads can read and write shared state. There are a number of ways in which that can be dangerous and error prone. Many languages don't let you access state from multiple threads (JS), some even have memory restriction rules built into the language and compiler (Rust). Kotlin/Native introduced a relatively unique model. In concept, it's interesting, but in practice, it can be confusing and a barrier to adoption. The new memory model will presumably allow unrestricted shared access to state. There are outstanding questions. Will there be equivalents to the JVM concurren ## SQLCipher and KMM DevFeed: [SQLCipher and KMM]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2020-09-23T15:17:52Z Content type: tutorial Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Encryption](), [multiplatform](), [Kotlin](), [iOS](), [SQLite](), [cocoapods]() Tags: [cocoapods](), [configuration](), [encryption](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [multiplatform](), [sqlite](), [upgrade]() ### AI overview A follow-up tutorial explains how to configure SQLDelight with SQLCipher for Kotlin Multiplatform, focusing on the iOS implementation. It covers forcing a fixed SQLiter version, configuring the native driver, disabling SQLite linking, and adding the SQLCipher dependency through CocoaPods. ### Source excerpt Here's a quick little followup to Sam's post: Multiplatform Encryption with SQLDelight and SQLCipher. Recently for a client we needed to implement this with Kotlin 1.4.0, and ran into a couple issues. I'm only going to describe how to get the iOS side working as Android is pretty straightforward (although Android is in the sample and video). Here's KaMPKit updated to use SQLCipher touchlab-lab/KaMPKitSQLCipher The cipher key is hardcoded in code. Do *not* do that in your app. You need to get your key from a more secure source. Here's a video showing edits on KaMP Kit: https://medium.com/media/e66f6e9738b614e0f6e2040ef887c0c1/href SQLiter ran into an issue setting the key for SQLCipher. That apparently used to work, but stopped at some point. There was a PR to fix that, but that was not merged in before 0.7.0 was released. 0.7.0 is used in the current version of SQLDelight, so you'll need to force this fixed version. sourceSets["iosMain"].dependencies { implementation("co.touchlab:sqliter:0.7.1") { version { strictly("0.7.1") } } //etc... } We also had an issue with our custom cocoapods fork, so if by chance you're using that, you'll need to use the latest, which is version 0.12. To configure your SQLDelight driver for native, you need to supply a custom DatabaseConfiguration for SQLiter. val schema = YourDb.Schema //SQLDelight Schema val configuration = DatabaseConfiguration( name = "YourDbName", version = schema.version, create = { connection -> wrapConnection(connection) { schema.create(it) } }, upgrade = { connection, oldVersion, newVersion -> wrapConnection(connection) { schema.migrate(it, oldVersion, newVersion ) } } ,key = yourCipherKey ) val driver = NativeSqliteDriver(configuration) To get this all to work in iOS, as discussed in Sam's post, disable sqlite linking: sqldelight { database("YourDb") { packageName = "co.touchlab.yourapp.db" linkSqlite = false } } Then add the SQLCipher dependency (if using cocoapods) cocoapods[ext] { summary = "Shared code for Y ## Ktor and Kotlin/Native DevFeed: [Ktor and Kotlin/Native]() Original publisher: [Read original article]() Author: Kevin Galligan Published: 2020-09-01T20:05:18Z Content type: article Language: en Sources: [Stories by Kevin Galligan on Medium]() Topics: [Ktor](), [Coroutines](), [Kotlin](), [iOS]() Tags: [bug](), [coroutines](), [ios](), [kotlin](), [kotlin-multiplatform](), [kotlin-native](), [ktor](), [native]() ### AI overview This article explains how Kotlin/Native's evolving memory model and coroutine threading model affect Ktor. It covers the initial single-threaded kotlinx.coroutines implementation, the multithreaded branch, parallel releases, and restrictions involving thread scopes and freezing. ### Source excerpt https://commons.wikimedia.org/wiki/File:Network-cables-1.png The story of coroutines for Kotlin/Native has been complex for a while now, and with the news that the Kotlin/Native memory model will be changing, coroutines for Kotlin/Native will remain a complex story for some time. Ktor is built around coroutines. The coroutines situation fundamentally affects how Ktor functions. There have been multiple moving targets in this story, which has created a lot of confusion and a number of bug reports that kind of cross over the same core issues. In this post, I will attempt to add some clarity to the situation. The Coroutines Situation To be clear, when we're talking about "coroutines", we're generally talking about kotlinx.coroutines. It's technically a separate library, but I can't imagine a realistic situation where you'd actually use coroutines and not include kotlinx.coroutines. Initially, kotlinx.coroutines for Kotlin/Native was single-threaded. You could suspend execution, but not schedule work on different threads. This was due to Kotlin/Native's memory model. Ktor was designed to run on this single-threaded model. Also, as far as I know on iOS, you would need to initiate Ktor calls from the main thread. In late 2019, a draft PR emerged which allowed kotlinx.coroutines to communicate across threads. We'll call this the "MT" branch, for "multithreaded". From this branch, there have been parallel library releases. The current main release is '1.3.9' and the current multithreaded release is '1.3.9-native-mt'. Unless something changes, the parallel branch and release model will likely stay the same for kotlinx.coroutines until the Kotlin/Native memory model update is complete. Ktor Until 1.4, Ktor was still designed to be run with the single-threaded version of kotlinx.coroutines. You *could* run it with the MT version, but you had to be very careful to keep the scope you were in to the main thread and make sure it was never frozen. It's a little complicated to expla