Loving the latest and greatest Multiplatform work,...

# multiplatform

[Bam]

Loving the latest and greatest Multiplatform work, but we really need to find improvements to build times for iOS. 😅😲
Almost empty project, with multiple modules, running on a Mac M3, with parallel and caching on. 1 hour and 25 min. K

[Pablichjenkov]

Not acceptable, although this is probably something that will happen in a CICD pipeline.
I see from the logs it ran debug and release stuff. Did you measure just one of the modes independently ? Could you share the results

[Bam]

I didn't measure a single mode, but I will attempt to do that a little later and report back.
As might be understandable, I don't want to risk a "clean" happening and then having to wait another hour and a half. 😅

I know it's being worked on, but I didn't expect this.

[tylerwilson]

I cannot point to exactly what it is, but I find my iOS Archive builds take significantly longer since moving to Kotlin 2.0.21 and CMP 1.7.0 and all the latest KSP etc…

[François]

do you generate static or dynamic library for iOS? try both and check the difference

[tylerwilson]

static. According the docs I followed that’s required for CMP

[François]

it’s still working, try it.

[François]

oh, about your bundle Id warning, you can add binaryOption("bundleId", "your.package.name") in the ios framework closure of your module

[Bam]

Sorry for the delay. I haven't been successful in capturing a successful long (1hour+) build, as they tend to run out of heap memory (and each takes over an hour), but have managed to remove a few modules that are not being used at the moment to speed up the build while still highlighting the steps that take the longest. Got a public Gradle Scan of a shorter build that still took 12-min to change a single import for a single module: https://scans.gradle.com/s/sfifqnpztueny

It's still very much the iOS steps that take the vast majority of time.
I've even updated to the latest versions of things in case there were some bugs or something.

My hunch is that this comes down each module within a project needing to do a lot of iOS work, which means that more modules = more iOS work.

The headline here seems a bit scary:
https://scans.gradle.com/s/sfifqnpztueny#timeline

1949 tasks, 174 transforms executed in 10 projects in 12m 5s, with 1103 avoided tasks saving 2h 21m 40.950s

Maybe this helps, maybe it does not. 🙂

[François]

did you try to build with dynamic library ? I got a nice feedback about it https://kotlinlang.slack.com/archives/C3PQML5NU/p1726940677164759

[Bam]

Huzzah for @François 🎉
Thank you for the suggestion. Setting static to false did help.
However, even improved builds with most modules not building takes 35 min K
https://scans.gradle.com/s/cvbiswcimilws

It does however look like it's only release builds that take vast majority of time.
Will attempt a debug build only and see what I end up with.

[Bam]

From clean with cache on:
BUILD SUCCESSFUL in 13s
647 actionable tasks: 306 executed, 289 from cache, 52 up-to-date
https://gradle.com/s/gmu63johg5pza

From clean with cache off:
BUILD SUCCESSFUL in 35s
647 actionable tasks: 595 executed, 52 up-to-date
https://gradle.com/s/j2xfhnymgy6p6

[Bam]

It looks conclusive to me, iOS release builds take, roughly, a billion years to complete.

For anyone finding this in the future, do your development only around debug and only do release builds for shipping stuff. At least until Release build issues have been improved/resolved. 🖖🏼

[Pablichjenkov]

Thanks for sharing these results 🙏. Yes that's typically the workflow. Let the heavy stuff for the ci/cd pipeline.

[Bam]

The only issue I see is that the default Android Studio Actions/Button/etc essentially do "Assemble all modules and all variants", which includes Release builds.
So will have keep that in mind when working, but otherwise shouldn't be a blocker.

[Bam]

Found workaround, that disables the Release variant in Android projects and only builds Debug), in case it becomes useful to anyone:

// Placed inside the android { ... } in a modules build.gradle.kts

// Makes sure dependencies with Release buildTypes fallback to the Debug build
buildTypes {
    getByName("release") {
        matchingFallbacks.add("debug")
    }
}

// Disables Release builds
androidComponents {
    beforeVariants(selector().withBuildType("release")) { variantBuilder ->
        variantBuilder.enable = false
    }
}

CORRECTION: Android Studio ignores this and still attempts to build Release somehow, so best to stick with Gradle commands for now.

[François]

Keep release build for distribution and debug build for developing,
Use expected build task when working with your project,
Release optimization takes time (it’s normal), but much more than the swift/objc, and I didn’t look into why it’s like that.