Has anyone been able to improve the iOS build time...
# multiplatform
j
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.
f
Do you build in static or dynamic binary?
Apparently, building in dynamic a multi module is faster
j
Looks like what is exported to iOS side is dynamic but I also have static = true for each iOS target.
Copy code
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)
...
I will try to change isStatic to false in that one spot and see if it makes a difference
🙏 1
@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.
f
In that case, I guess, you need to create a standalone framework and use it as a classic library
It depends of the organization of your project
Like Distributing your module as spm package, you find some reading on google
j
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.
f
Oh, the classic way Yeah, you could use the link task or even run the test directly for each module
But it’s just for validation of your module not the integration inside an app.
Also don’t forget to use explicitApi it can help you to reduce the build time for iOS
👍 1
j
I also didn't have build caching enabled, that should help also
j
Curious if you saw much difference in build times by setting isStatic to false?
j
@John O'Reilly nope, there was not a noticeable difference for me, build caching was the biggest factor so far
j
ok, thanks
f
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.
j
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.