Has anyone been able to improve the iOS build times when using `embedAndSignAppleFrameworkForXcode ?...

# multiplatform

[Jason]

Has anyone been able to improve the iOS build times when using embedAndSignAppleFrameworkForXcode ?

The build times on our Build Server have basically doubled just building a small set of Shared kotlin code, from 13 min to 30 min.

[François]

Do you build in static or dynamic binary?

[François]

Apparently, building in dynamic a multi module is faster

[Jason]

Looks like what is exported to iOS side is dynamic but I also have static = true for each iOS target.

listOf(
    iosX64(),
    iosArm64(),
    iosSimulatorArm64()
).forEach { iosTarget ->
    iosTarget.binaries.framework {
        baseName = "xxx"
        isStatic = true
    }
}

// Multiplatform modules you want to expose to 'iOS'
targets.withType<KotlinNativeTarget> {
    binaries.withType<Framework> {
        isStatic = false

        export(libs.koin)
        export(libs.androidx.lifecycle.viewmodel)
...

[Jason]

I will try to change isStatic to false in that one spot and see if it makes a difference

[Jason]

@François I was wondering also, for a CI build, do I even need to run the embedAndSignAppleFrameworkForXcode gradle task? Seems like I could get away with just running linkReleaseFrameworkIosSimulatorArm64 and that should limit what gradle is building.

[François]

In that case, I guess, you need to create a standalone framework and use it as a classic library

[François]

It depends of the organization of your project

[François]

Like Distributing your module as spm package, you find some reading on google

[Jason]

i'm using a mono repo right now because we will have a lot of code churn in the shared code which having to publish the shared code as packages/frameworks every build will be time consuming.

[François]

Oh, the classic way
Yeah, you could use the link task or even run the test directly for each module

[François]

But it’s just for validation of your module not the integration inside an app.

[François]

Also don’t forget to use explicitApi it can help you to reduce the build time for iOS

[Jason]

I also didn't have build caching enabled, that should help also

[John O'Reilly]

Curious if you saw much difference in build times by setting isStatic to false?

[Jason]

@John O'Reilly nope, there was not a noticeable difference for me, build caching was the biggest factor so far

[John O'Reilly]

ok, thanks

[François]

From some exchange here, on some project with a lot of modules, using dynamic make the compilation faster.
I guess, here, it’s not the case.

[Jason]

makes sense, the linking phase is omitted when dynamic lib is built. In could be I was already doing a dynamically linked framework as I had isStatic = false when I exported the shared modules.