`libAppboyKitLibrary.a` file size is too big for Github

[mathaeus]

The Braze SDK binary (libAppboyKitLibrary.a) has been constantly growing and unfortunately now it exceeds the 100MB file size for checking in files to a Github repository.

For our project we have all our dependencies checked into the repository (which is a common practice when working with cocoapods). A recent update from 3.21.3 to 3.24.1 introduced the problem that we are unable to check-in the binary file due to the following size limit:

https://github.community/t/working-with-large-files-and-repositories/10203

git-lfs is a costly alternative to this and changing our workflow to not have our dependencies checked in is something we will consider, but for sure we can't achieve it super fast.

Is there a way you can reduce the file size to under 100MB?

[LeffelMania]

Nine days without acknowledgement? Same boat over here, had to pin my pod to 3.22.0 so that I could keep all my pods checked into our repo.

[chshapiro]

Hey @mathaeus and @LeffelMania,

We are looking into different options to reduce the size of the binary. We will update this thread when we have new developments.

Thanks!

[mathaeus]

Thanks for the update @chshapiro 👍

[dchakarov]

Thanks for looking into this, we hit the same issue today and decided not to update to the latest SDK for now. Not ideal, hope we get this resolved soon.

[rakesthedon]

my team is also experiencing this issue.

[Bucimis]

Thank you everyone for raising and providing details, we're tackling this with urgency.

For those whose workflows and CI/CD solutions aren't strongly tied to checking-in Pods, we would recommend not checking in our pod (even in the pre-100mb world) if possible since it expands the size of repos and pollutes history. If you are able to adjust your flow to not check-in the Appboy-iOS-SDK pod, you should be able to update to 3.24.1 today.

Going forward, we're exploring replacing our ~100mb .a static library with a ~30mb dynamic framework.

In the meantime, we're also exploring releasing a version of 3.24 with arm64e or another lesser-used architecture stripped from the static library to temporarily bring it back under 100mb.

If you have feedback, concerns, or questions on these approaches, please let us know.

[rakesthedon]

we are using Carthage not cocoa pod and the error occurred with git lfs

[Bucimis]

@rakesthedon if you're using Carthage you should be able to use 3.24.0 (which is functionally identical) without issues. You should also be able to use the dependency-free integration (https://www.braze.com/docs/developer_guide/platform_integration_guides/ios/initial_sdk_setup/carthage_integration/#dependency-free-integration) on 3.24.1 without running into git-lfs issues. Let us know if that works out for you

[rakesthedon]

the issue is still present with the 3.24.0 version and we do not wish to use dependency free integration. And we are also using git lfs

this is the error message that I see in my Jenkins logs Error downloading object: AppboyKit/libAppboyKitLibrary.a (493ea41): Smudge error: Error downloading AppboyKit/libAppboyKitLibrary.a (493ea4171dcf258aca7d9bffeb5c67386533b1391459ee3b77dc61590c1f4b4e): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

[Bucimis]

@rakesthedon thanks for the update, we were able to repro with git-lfs enabled on 3.24.0. Could you give us context as to why you'd prefer not to use the dependency-free integration? To avoid additional time spent building SDWebImage?

[rakesthedon]

@Bucimis it's mostly for time and cost management reason, plus we already use Carthage on another app that does not use lfs and it work fine with version 3.24.1 and we would like to keep our process as similar as possible on both our apps.

[hokstuff]

@rakesthedon, to clarify this part in your last response:

we already use Martha on another app that does not use lfs and it work fine with version 3.24.1

1) When you said "Martha", do you mean "Carthage"? 2) When you said that it works fine with 3.24.1 on your other app, are you saying that you were able to successfully import the Appboy-iOS-SDK (with dependencies) without seeing the error: Error downloading object: AppboyKit/libAppboyKitLibrary.a?

[rakesthedon]

1. whoops! Yes I meant Carthage sorry about that
2. We use the version 3.24.1 on our other app and we also use Carthage but without git lfs

[rakesthedon]

@hokstuff apparently some member of my team are having the same issue when they are trying to do a Carthage bootstrap even with the app that does not use git lfs.

[Bucimis]

@rakesthedon thanks for the insight. We also see that on our end, though it's irregular

[mohammad19991]

My team is also experiencing the same issue, is there any update on this issue?

[Bucimis]

@mohammad19991 @rakesthedon @mathaeus we're scheduling some initial fixes for tomorrow that should solve for large subsets of users/usecases. We'll update more as they roll out

[Bucimis]

@rakesthedon We just released 3.24.2, which should fix Carthage issues seen in 3.24.0 and 3.24.1 for integrations using github "Appboy/Appboy-iOS-SDK". In the future we'll release a Binary Project Spec for the full (deps included) framework that should make that integration more lightweight going forward.

Let us know if you encounter issues building with 3.24.2

[rakesthedon]

@Bucimis it's seems to work for us! thanks a lot!

[mathaeus]

@Bucimis if I understand correctly there will also be a fix for cocoapods? i.e. a 3.24.3 version then?

[Bucimis]

@mathaeus yep we're working on it (specifically, enabling checking in the pod without using git-lfs).

[mohammad19991]

@Bucimis when shall we expect the new update?

[Bucimis]

@mohammad19991 within 1-2 days

[hokstuff]

Hi @mathaeus @mohammad19991 @LeffelMania,

We have now released iOS SDK version 3.25.0 which removes the arm64e architecture and allows you to check in your entire Pods folder into version control without issues. If removing arm64e is a concern, please reach out to us directly at support@braze.com and we will be able to work with you individually.

Let us know if you have any further issues - thank you all!

[mathaeus]

Thanks @hokstuff

If removing arm64e is a concern, please reach out to us directly at support@braze.com and we will be able to work with you individually.

I'm no expert when it comes to architectures, and I'm not sure if the Apple docs are up to date (see below). If they are then for now I don't think there should be an issue if you don't support arm64e (as long as you have a plan to bring it back in the near future?)

App Store Connect and Testflight don’t yet accept submissions with an arm64e slice. Xcode removes this slice from your app bundle when you upload it.

https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication

[mohammad19991]

@hokstuff thanks, it's working now.

[PavelGnatyuk]

I see the same issue with 3.29 update.

git lfs fetch source --all

fetch: Fetching all references... batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access. error: failed to fetch some objects from 'https://github.com/Appboy/appboy-ios-sdk.git/info/lfs'

[Bucimis]

Hi @PavelGnatyuk can you provide the commands you used to repro this and give us more details on how you're integrating? Our releases 3.24.0 and 3.24.1 can't be checked out from source because of the old git-lfs issues, so you should ensure you aren't fetching the repo's full history in source. 3.29.0 doesn't use git-lfs and shouldn't exhibit any issues whether integrated through Cocoapods, Carthage, etc.

[poorvasingh04]

@Bucimis We are also facing similar issue. 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 to compile after this change. Is there a way to reduce CI time?

[Bucimis]

@poorvasingh04 thanks for getting in contact. how are you integrating and which version are you using?

[poorvasingh04]

@Bucimis I am using v 3.30.0 and as said earlier we are using cocoapods for downloading the sdk.