Hi guys, I have noticed that when we produce a XC...

# multiplatform

[ptsiogas]

Hi guys,

I have noticed that when we produce a XCFramework for our shared code, the ios-arm64 architecture folder is ~4 times larger than the ios-x86_64-simulator . For example for a really small project the ios-arm64 folder is ~30MB and for a large project it’s ~75MB.
Hint: we have tried to produce the XCFramework with both the native plugin and the multiplatform-swiftpackage plugin but we got the same size.

Have you noticed anything similar? Is there a way to reduce its size?

[kpgalligan]

If you're worried about the size of the binary in an actual app, the size on your dev disk of a framework artifact is nowhere near what the binary size will be in a deployed app. You need to run size estimates with Xcode and/or push to the app store and get size estimates. Apple binary size is large relative to, say, Android, and there are things you can do with Kotlin to help reduce it, but you really need to get an accurate measure first.

[kpgalligan]

TL;DR your app won't be 75m because of the framework. It'll be a lot less, but it's hard to predict how much just by size in your dev folder.

[kpgalligan]

Some info:

https://youtu.be/hrRqX7NYg3Q?t=1896▾

[ptsiogas]

@kpgalligan thanks for the answer. I am not worried about the final size of the app because this is tested and it’s fine.
I am particularly worried because we Share KMM module with iOS via Cocoa pods and the pod install process is talking quite a long time.

[kpgalligan]

Ah, well. That's different. You're committing this binary to the repo? KotlinMultiplatformSPExample.xcframework

[kpgalligan]

We just spent a good chunk of time extracting that from a repo because it eventually blew up to 5-6g. You really can't do that at scale. They need to go into zips and get pushed to buckets or whatever.

[kpgalligan]

Each commit was like 50m. It adds up quick.

[kpgalligan]

Even if you got it down to 30m, 20m, it'll just slow the inevitable.

[kpgalligan]

This is what I spend most of my time on now, though. Production packaging and deployment for teams.

[kpgalligan]

Cocoapods and SPM.

[ptsiogas]

You are totally correct. I am thinking of going into a separate repository for the XCFramework but this doesn’t solve the scaling issue.

[ptsiogas]

Have you found a viable workaround?

[kpgalligan]

For an external repo, you could make it work with some kind of an expiration plan, and clean it up with something like https://rtyley.github.io/bfg-repo-cleaner/ on a regular basis, but it's going to be hacky.

[kpgalligan]

We're building a system that pushes to S3 and manages versions. Trying it out with clients now, but it's raw. I'm making changes that get pushed to the client roughly same day. Really in the middle of it. The plan is to be able to have iOS devs clone the repo and avoid building kotlin if they don't want to, but still be able to debug in Xcode if needed.

[kpgalligan]

The trick is getting CI to build and publish binaries without making the dev process too weird. Well, there are other tricks, but that's where I'm currently having trouble. But getting the binaries out of the repo isn't too bad. We've done it a few times for specific situations. You basically need zips and push them somewhere that you can reference from your podspec. How you schedule releases, etc, is kind of dependent on your specific situation.

[kpgalligan]

We have nothing public right now, unfortunately 🙂

[ptsiogas]

I see, we have found a nice tricky issue there 🙂
I will also work on it and report here if I come with a solution.
As KMM becomes more popular, sharing code with iOS is a problem that we need to address with an elegant solution as soon as posible.

[kpgalligan]

As KMM becomes more popular, sharing code with iOS is a problem that we need to address with an elegant solution as soon as posible.

Yeah, that's the past 3 years of my life 🙂

[ptsiogas]

Hello Kevin,
just a thought: if we manage to solve the distribution problem, the Android repo will be fine.
The iOS repo though will continue to grow in every commit that the shared code is changed.
The only way to avoid that is to manage to build the shared code in every iOS build (e.g with a mono repo) and add a gitIgnore rule to avoid committing any shared code framework. This would prevent the use of cocoapods (or SPM) and increase xcode’s build time.

[ptsiogas]

Hello @kpgalligan, I am testing a submodule approach where the iOS is building the KMM binary with build scripts as shown in the guide below:
https://kotlinlang.org/docs/kmm-integrate-in-existing-app.html#use-the-shared-module-from-swift

It seems to work fine so far and it does not upload any binary files at git. The KMM versioning is handled by the Android repository.

[kpgalligan]

It seems to work fine so far and it does not upload any binary files at git.

That should work fine, but all devs would need to build the iOS side locally. We're focused on trying to include a binary somewhere so that iOS devs don't need to have Kotlin builds set up. It's more for larger teams where not everybody is excited about Kotlin and they don't want to disrupt the dev cycle too much.