It's time to release a new version.

[WonderJeffy]

Given that the previous version 4.0.0 has been around for 4 years, it is time to release a new version. Please~

[baveku]

It's coming...........

[dmitrilosev]

Need it

[dmitrilosev]

Or any idea how to install with SwiftPM

[baveku]

Or any idea how to install with SwiftPM

Do you try to install the branch main?
if not working, you can try my repo to install SPM:
https://github.com/baveku/IGListKitSPM

[cendolinside123]

pleasee

[baveku]

I know that the IG team will release it ASAP. v5.0.0 is still in development and testing.

[cendolinside123]

Or any idea how to install with SwiftPM

Do you try to install the branch main? if not working, you can try my repo to install SPM: https://github.com/baveku/IGListKitSPM

I want to install using cocoapod from main branch but keep failed, any idea?

I already set on pod file

pod 'IGListKit', :git => 'https://github.com/Instagram/IGListKit.git', :branch => 'main'

error message:

[!] CocoaPods could not find compatible versions for pod "IGListDiffKit":
  In Podfile:
    IGListKit (from `https://github.com/Instagram/IGListKit.git`, branch `main`) was resolved to 4.1.0, which depends on
      IGListDiffKit (= 4.1.0)

None of your spec sources contain a spec satisfying the dependency: `IGListDiffKit (= 4.1.0)`.

You have either:
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

[WonderJeffy]

use the follow code in your pod file to install from main branch

pod 'IGListDiffKit', :git => 'https://github.com/Instagram/IGListKit.git', :branch => 'main'
pod 'IGListKit', :git => 'https://github.com/Instagram/IGListKit.git', :branch => 'main'

[TimOliver]

Hey folks! I’m so sorry for the lack of communication here. I’ve been seeing this post in my notifications for a while, but I was holding off until I’d talked with the IGListKit owners to decide next steps. Here’s where we’re at now. 🙏

The tl;dr is “We were on track for v5.0, but we got a bit derailed earlier this year, but we should be on track again now”. 🙂

When I looked into what the plan for v5.0 was, I found that there was a list of milestones that still needed to be completed before we could release:

• Finishing the migration of the test automation from Travis CI to GitHub Actions (To allow incoming PRs to be properly tested).
• Adding complete Swift Package Manager support.
• Going through all of the active PRs submitted by the community and merging as many as possible.

I spent a good chunk of this year working on the first two. The CI is now back up and running, and thanks to the efforts of the community, we have such good SPM integration that we were able to use it place of CocoaPods for the IGListKit sample apps. I’ve also spent a lot of time this year updating the code coverage suite, and adding general polish to the sample apps. 😁

I’ve also gone through and merged a fair few of the older PRs, and the ones left behind at this point are ones that need a bit more refinement before they can be merged (tl;dr they worked out here, but when I tried to integrate them into the Instagram app itself, some compatibility issues arose). But regardless, we should be in good shape on that front too.

I thought we were actually ready to roll out v5.0 in the middle of the year, but then that all sadly got derailed when iOS 16.4 launched. When Apple rolled out that version of iOS, they changed the behaviour of UICollectionView to be a lot more strict when mutating state outside of performBatchUpdates. Before, it was simply considered ‘bad practice’ and it could recover on its own, but in iOS 16.4, Apple upgraded the behaviour to a full-blown exception that crashes the app if encountered. Unfortunately, as a result of this, a non-trivial number of surfaces in Instagram started crashing at once. 😱

We’ve fixed all of the crashes related in the app that we could see, but given how transient the issue is, we need to keep monitoring IGListKit to see if there are any cases we may have still missed. To do this, we applied a ‘band-aid’ solution where we manually catch and log the exceptions triggered by this new behaviour. This lets us capture the issue again when and if it arises.

That all being said, everyone I talked to agreed that this manual catching solution shouldn’t be shipped in the public release of v5.0. Causing an exception and crashing is indeed the correct behaviour here. So while we need to keep this mechanism around for IG’s benefit for a little while longer, we don’t want this to be default behaviour in v5.0. 😅

I had a chat with the folks involved with IGListKit, as well as the folks involved with tracking where the exception had been occurring to see what we can do to resolve this situation for v5.0’s release. We agreed that we need to keep the catch solution for the time being, but we can gate it behind IGListKit’s experiments feature. This way, we can keep it enabled internally, but we can make it that it’s not enabled in public releases (at least not by default). 🤩

So I’ll get on that as soon as I can. I’ll also get back to merging the rest of the PRs when I can as well.

In any case, thanks so much for your patience everyone!

If there was one silver lining that came out of this experience, it’s that it was thanks to the feedback in the IGListKit GitHub repo that we received early warning about this impending iOS 16.4 change. This definitely reaffirmed and reinvigorated our commitment to the open source maintenance of IGListKit. 😄