`libAppboyKitLibrary.a` file size is too big for Github and increases time for creating build in CI

[poorvasingh04]

Report

We use cocoapods for dependency. libAppboyKitLibrary.a is very heavy (~84 MB). Though we are able to checkin to git with some warning but our CI takes a lot of time in compilation after this change. Is there a way to reduce CI time?

Describe your environment.

Info	Value
Platform Name	ios
Platform Version	14.1
SDK Version	3.30.0
Integration Method	cocoapods
Xcode Version	Xcode 12.1
Repro rate	100%

What did you expect to happen?

file size should be smaller so that it doesn't affect build time in CI

What happened instead?

CI time is substantially increased

[poorvasingh04]

@Bucimis In continuation to previous issue https://github.com/Appboy/appboy-ios-sdk/issues/234 which is closed, I am creating a new one here.

[poorvasingh04]

@Bucimis

[hokstuff]

Hey @poorvasingh04,

Thanks for bringing this to our attention. We are aware of the size of our static library and have been trying different ways to keep it a reasonable size. In the meantime, can you try using a shallow clone to try to speed up the process by calling git clone --depth 1? This should help with performance by only downloading a truncated history.

Best, Daniel

[poorvasingh04]

@hokstuff you mean shallow clone all pod libraries? I don't want to do that. There are lots of issues with shallow clone. I was looking into following threads. https://github.com/CocoaPods/CocoaPods/issues/7280 https://github.com/CocoaPods/CocoaPods/issues/4989

Can you suggest something else? Is there a way to download shallow clone just AppBoy sdk?

[hokstuff]

Hi @poorvasingh04,

Apologies for the delayed response here. Are you still experiencing this issue? We distribute our SDK in a compiled binary, so it may be difficult to reduce the size directly. Do you know which particular step is taking the most time during importing?

I understand that you are using Cocoapods, but we have recently released a new version to Swift Package Manager that has greatly increased import speeds. If you are interested, you can see the release here.

Thanks!

[poorvasingh04]

@hokstuff Is it possible to optimize the library to reduce its size. 84 MB is very big.

[hokstuff]

@poorvasingh04 The library is that size because it is a compiled library that contains several different architectures together (simulator, device), so it is pretty limited what we can do there.

When you say our CI takes a lot of time in compilation, do you mean that it is taking a while during the "compile time", or are you referencing the entire "build time" (including the time to download a large repo)? Also, is there a reason in your flow that requires you to check-in the large binary file?

We are working on distributing our library using XCFrameworks soon, so that may help the issue you are experiencing depending on the answers to the previous questions. We can keep you updated about that once it is released.

[hokstuff]

@poorvasingh04 We released version 4.0.0 that distributes our library as XCFrameworks on Cocoapods. The encapsulating XCFramework is larger but the binaries are smaller, which may affect your compile time. Please let us know the additional context about your CI setup (above) as well as if the recent changes have helped with the issues you've been seeing.

Thanks!

[poorvasingh04]

@hokstuff thanks for the update. Its the compilation time which is too much. I will update the library and check it again.

[hokstuff]

Hi @poorvasingh04,

Are you still experiencing this issue, or are any of the workarounds mentioned above sufficient?

Best, Daniel

[poorvasingh04]

@hokstuff I am still facing the issue.

[hokstuff]

I'm closing out this issue as a dupe of our issue here because it stems from the same root cause. We are actively working on a long-term, holistic fix to this issue which will help with the cloning a large repo. Feel free to comment on that thread or contact support@braze.com with further concerns - thanks!