Lottie turns out to be 300MB+ in size when fetched through SPM

[AvdLee]

Which Version of Lottie are you using?

Lottie 3.5.0

Expected Behavior

Lottie should not be so large.

Actual Behavior

Lottie is fetched as a 357MB size repository somehow:

avanderlee@Antoines-MacBook-Pro-2 repositories % du -sh */ | sort -hr
357M	lottie-ios-0271592b/
173M	firebase-ios-sdk-a1569f98/
117M	grpc-ios-9a5f03c1/
.....

It's mostly due to this file:

I'm not sure yet how this is possible since the repository currently downloaded is only ~150MB.

Any input is welcome!

[AvdLee]

It might be related to GIT history: https://stackoverflow.com/questions/11050265/remove-large-pack-file-created-by-git

[calda]

A clean clone of the repo is currently 315MB. This is mostly because we have ~100MB of snapshot images from our regression tests checked into the repo (Tests/__Snapshots__/SnapshotTests), plus their git history.

[calda]

We may be able to move the snapshots to LFS, I'll see if this is feasible

[calda]

LFS is super easy to integrate into a repo, but the main issue is that we'd lose the ability to view snapshot diffs in pull requests: https://docs.github.com/en/repositories/working-with-files/managing-large-files/collaboration-with-git-large-file-storage

We'd need some sort of replacement flow for viewing the snapshot diffs caused by a pull request, which is important for reviewing and understanding the changing in a PR.

[AvdLee]

Gotya, that clarifies! So one thing you could do is adding support for binary targets. This is a repo that did it for Firebase: https://github.com/akaffenberger/firebase-ios-sdk-xcframeworks which can be inspiring, but it mostly comes down to providing a binary release.

For example, this is how we reference SwiftLint through a binary target:

.binaryTarget(
    name: "SwiftLintBinary",
    url: "https://github.com/realm/SwiftLint/releases/download/0.49.1/SwiftLintBinary-macos.artifactbundle.zip",
    checksum: "227258fdb2f920f8ce90d4f08d019e1b0db5a4ad2090afa012fd7c2c91716df3"
)

The benefit is that we only have to download that artifact, only the files we really need. It might also have an impact on build times, so it could definitely be something to explore.

[calda]

We now publish xcframework archives as a part of our release process: #1807 (comment)

[calda]

We've adopted Git LFS for our snapshot images. By default a checkout of master is now 213MB, down from 375MB.

[SajjadKharrazi]

i think lottie can have an approach like Branch.io

BranchMetrics/ios-branch-deep-linking-attribution#1053

[AvdLee]

A separate repo sounds quite extreme to me! Just providing artifact bundles to the release should be good enough and a significant step forward already. SwiftLint recently did improve this support as well..

[calda]

@AvdLee, how involved was the process of manually creating and adopting a binary framework? Depending on the complexity, it may make sense for us to document how to do this for folks who are interested (and concerned about the size of the repo as-is).

[AvdLee]

It was doable for me since I'm knowledgeable in the area. However, I believe it should be something Lottie should offer in return for the large repository size. It shouldn't be too complex to write an automated script for it that you can add to the release process. It makes your repository look better and helps the many implementors of this framework.

Ensure to learn from other frameworks providing similar xcframework alternatives.

[xmollv]

That's still a lot compared to the binary framework, which is only 9MB. We've adopted it ourselves and decided to create them manually, but it would be great if that could be supported by Lottie natively until we have a package registry available.

This would be awesome. Lottie is by far the slowest dependency to pull in our case. I've updated to 4.0.0 this morning and SPM reports that it takes a bit more than 2 minutes for Lottie.

[calda]

We now publish xcframework archives as a part of our release process: #1843 (comment)

For example, the 4.0.1 release includes a Lottie.xcarchive.zip attachhment. You can install this into your Xcode project manually, or integrate it using Swift Package Manager:

// You can either use a remote binary dependency where SPM downloads the xcframework from GitHub
.binaryTarget(
  name: "Lottie",
  url: "https://github.com/airbnb/lottie-ios/releases/download/4.0.1/Lottie.xcframework.zip",
  checksum: "b6d8b0b81975d91965b8bb00cffb0eae4b3d94538b6950a90bc1366afd5d4239")

// Or you can download the xcframework locally and include it in your project's git repo:
.binaryTarget(
  name: "Lottie",
  path: "path/to/Lottie.xcframework")

The xframework is only 8.6MB.

[SajjadKharrazi]

@calda when i added .xcframework file manually and upload my app to appStore, i got this error:

ITMS-90863: Apple silicon Macs support issue - The app links with libraries that are not present on Mac:

@rpath/Lottie.framework/Lottie
After you’ve corrected the issues, you can upload a new binary to App Store Connect.

but without .xc everything is ok

[SajjadKharrazi]

also it causes app to crash when build on physical device, but on simulator it does not

[alexfringes]

Unsure if this is helpful, but we might be able to learn something from how @akaffenberger has set up this binary SPM mirror for the Firebase iOS sdk: https://github.com/akaffenberger/firebase-ios-sdk-xcframeworks
Specifically, this includes some project-level changes that seemingly are needed, as well as the script that creates the binary when the original repo releases a new version.

[calda]

That's what we're hoping to set up for Lottie -- I have an early proof-of-concept for this here and should be able to finish setting this up in an official repo early in January.

[alexfringes]

So glad to hear you’re considering rolling an official version. My reply was honestly more meant as a suggestion for the problems @SajjadKharrazi was encountering, which I do not run into with the Firebase binary mirror. E.g., I wonder if the -Objc flag is required atm?

[calda]

Thanks all for the discussion here. We've created a new lottie-spm repo that folks can use with Swift Package Manager. This repo is much smaller than the main repo (~500kb instead of 300mb) so should resolve these repo size issues. It's easier to integrate than XCFrameworks, since it's just a normal Swift package that you can add via Xcode or your Package.swift.

[xmollv]

@calda Thanks for doing this! We've moved to the SPM specific package and so far so good.

[Ernest0-Production]

Hi! The new repository began to grow inadequately in size :/

It has about 20 commits, but it weighs much more than other older repositories like Alamofire, kingfisher

[calda]

That's the .build directory, not just the source checkout. A fresh clone of the lottie-spm repo is only 200kb.

The .build directory probably also includes the XCFramework archives which are downloaded at build time, but not part of the git repository.

[Ernest0-Production]

No) That's repository folder