# KMM Memory Model -- when to switch?

DevFeed: [KMM Memory Model -- when to switch?](<https://devfeed.tech/articles/kmm-memory-model-when-to-switch-25950.md>)

Original publisher: [Read original article](<https://medium.com/@kpgalligan/kmm-memory-model-when-to-switch-b1bc39867a75?source=rss-c2f810aa7890------2>)

Author: Kevin Galligan

Published: 2021-12-23T19:34:40Z

Content type: opinion

Language: en

Sources: [Stories by Kevin Galligan on Medium](<https://devfeed.tech/sources/stories-by-kevin-galligan-on-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Library](<https://devfeed.tech/topics/library.md>), [Maintainers](<https://devfeed.tech/topics/maintainers.md>), [releases](<https://devfeed.tech/topics/releases.md>)

Tags: [bug-fixes](<https://devfeed.tech/tags/bug-fixes.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [kmm](<https://devfeed.tech/tags/kmm.md>), [kmp](<https://devfeed.tech/tags/kmp.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [kotlin-native](<https://devfeed.tech/tags/kotlin-native.md>), [maintainers](<https://devfeed.tech/tags/maintainers.md>), [releases](<https://devfeed.tech/tags/releases.md>)

## 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