# Speeding up Kotlin Multiplatform

DevFeed: [Speeding up Kotlin Multiplatform](<https://devfeed.tech/articles/speeding-up-kotlin-multiplatform-24747.md>)

Original publisher: [Read original article](<https://medium.com/yazio-engineering/speeding-up-kotlin-multiplatform-61ebf8dae560?source=rss----65bd178b00af---4>)

Author: Paul Woitaschek

Published: 2022-05-18T09:11:24Z

Content type: tutorial

Language: en

Sources: [YAZIO Engineering - Medium](<https://devfeed.tech/sources/yazio-engineering-medium.md>)

Topics: [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [build times](<https://devfeed.tech/topics/build-times.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [ide](<https://devfeed.tech/topics/ide.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [Android](<https://devfeed.tech/topics/android.md>), [watchOS](<https://devfeed.tech/topics/watchos.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-studio](<https://devfeed.tech/tags/android-studio.md>), [build-times](<https://devfeed.tech/tags/build-times.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [ide](<https://devfeed.tech/tags/ide.md>), [ios](<https://devfeed.tech/tags/ios.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>), [watchos](<https://devfeed.tech/tags/watchos.md>)

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