Remove swift-collections dependency

[dfed]

Summary

• Replace DequeModule and OrderedCollections imports with minimal internal implementations (Deque, OrderedDictionary, OrderedSet) in Sources/LiveKit/Support/DataStructures/
• Remove swift-collections from Package.swift, Package@swift-6.0.swift, and LiveKitClient.podspec
• Unblocks consumers from being pinned to old swift-collections versions due to library evolution mode / XCFramework compatibility constraints

Details

The actual API surface used was tiny — 3 types, ~14 call sites, all internal. The new implementations are ~180 lines total, matching the existing pattern of lightweight data structures in the repo (RingBuffer, MapTable, TTLDictionary).

Test plan

• xcodebuild build -scheme LiveKit -destination 'platform=macOS' succeeds
• xcodebuild test -scheme LiveKit -only-testing LiveKitCoreTests -destination 'platform=macOS' — all non-E2E tests pass (E2E tests require local server)
• CI passes

🤖 Generated with Claude Code

[pblazej]

Could you inspect the CI build errors? @dfed

Hint: the key is binary distribution (it was downgraded for a reason); the closest comment I could find was apple/swift-collections#546 (comment)

Haven't tested it tho

[pblazej]

After a short test, I see 2 obstacles:

• newer versions do not officially support Swift 5.x toolchain (that won't be an issue soon)
• more importantly, they rely on experimental features and will break library evolution mode, which is crucial for building a xcframework on top of LK - this is a strict requirement for us

I'm happy to merge it once we resolve the latter.

[dfed]

Got it. @pblazej would y'all be interested in a PR that copy/pasted the existing implementation of Deque, OrderedDictionary, and OrderedSet from Swift Collections as internal types such that y'all can remove swift-collections as a dependency? Ideally depending on LiveKit wouldn't restrict adopting apps from using the latest libs from Apple. Happy to update this PR

[pblazej]

@dfed thank you for going the extra mile here!

The problem with binary distribution is pretty common across Apple libs e.g. apple/swift-nio#2897 and already happened to use with swift-logging that we dropped vs bare OSLog.

I think porting the minimal API is better than carrying "a big part of the lib" under Apache as our usage is pretty narrow, the impact of future optimizations (leveraging ownership etc.) is probably negligible.

2 things:

• please rebase on main to include Package@swift-6.2
• you can run https://github.com/apple/swift-collections-benchmark against them to see if there are any bottlenecks vs the reference impl
  • or I'll do it as a part of review - I'm talking mostly about DataChannelPair <- Deque

[pblazej]

collection-bench.zip

Attaching my results - nothing to worry about 🎉

The rest is micro-optimization like:

  // Before (integer division)
  let tail = (head + count_) % buffer.count

  // After (bitwise AND — same result when buffer.count is power of 2)
  let tail = (head + count_) & (buffer.count - 1)

[pblazej]

@dfed can we finalize this PR? I've got some reports on other consumers blocked by that, don't want to duplicate your great work.

[dfed]

Rebased on main (picks up Package@swift-6.2.swift), removed swift-collections from that file in d5da9f1, and applied all your suggestions in 6f144a8. Should be ready for another look!

[pblazej]

🎉