fix(uniffi): register the Bytes custom type once, in livekit-common

[pblazej]

bytes::Bytes was registered with custom_type! in both livekit-uniffi and livekit-datatrack. A remote type can only be registered once per UniFFI component: each emits its own public typealias Bytes and FfiConverterTypeBytes, and cargo-swift compiles every component file into one Swift module — invalid redeclaration of 'Bytes'. UniFFI's own duplicated helpers coexist because they're fileprivate; custom_type! emits public, so they don't. Patched until now by a perl regex in swift-workarounds, which is deleted here.

livekit-common now owns the registration and every component borrows it:

uniffi::use_remote_type!(livekit_common::Bytes);

Owning a registration means being a component — custom_type! resolves crate::UniFfiTag, and bindgen rejects metadata belonging to no namespace (Unknown namespace for CustomType). So livekit-common gains an optional uniffi feature, enabled transitively by livekit-uniffi, and a third generated Swift file. That file had to be added to uniffi-swift.yml — the publish step enumerates sources rather than globbing, so an unlisted component silently ships a package that can't build. Costs 4,160 B on the cdylib (1,107,856 → 1,112,016), leaving 66 KiB under the iOS gate.

Verified: livekit-common and livekit-datatrack still build without the feature; the three-file Swift module compiles; client-sdk-swift main builds clean against the generated package, tests included; the xcframework carries all three headers in one framework modulemap.

Alternatives for the collision

Option	Verdict
Keep the perl regex	Fragile — matches literal generated formatting, so it silently no-ops when uniffi's Swift templates shift — and Swift-only, so Kotlin and Python kept shipping two declarations.
Let livekit-datatrack own it	Free (80 B, no new component), but an unintuitive home for a generic byte buffer, and any future component would have to depend on livekit-datatrack to borrow it. Was the first version of this PR.
Collapse to one component — drop uniffi from livekit-datatrack and mirror its types with #[uniffi::remote]	Removes the class outright and returns the duplication below. But ~150 lines of mirrored Rust, hand-written adapters for the two with_foreign traits, and dropping #[non_exhaustive] from two enums. Separate PR.

Upstream: #2933 (open) is this bug, and this PR takes the external-type route it proposes. #2126 (open) — no #[uniffi::remote(Trait)] in 0.31 or 0.32 — is why collapsing needs trait adapters. #2802 (open) is the same conflict across separate UniFFI libraries.

Alternatives for the duplication

Not addressed here. Each component re-emits the whole FFI runtime: ≈19 KB across three of them — 8.3 KB native and ~10.6 KB of Swift code+data, from two measured per-component deltas of ~4.2 KB and 5,287 B.

Option	Verdict
Hoist the shared Swift runtime into one internal file	Worse — prototyped at +14,592 B on the linked binary, because it destroys the per-file specializations that make the duplicate copies cheap. Buys ~5% compile time.
Wait for upstream to emit the common part once	Asked for twice, declined twice. Not in flight.
Collapse to one component	The only thing that actually returns it.

Upstream: #408 / #409 (closed) asked to eliminate re-declared Swift helpers and were resolved with the UNIFFI_SHARED_H guard plus fileprivate — duplicates left to coexist rather than removed. #2257 (closed) asked to combine the per-crate outputs; closed without a feature. #2153 (open) is the only live proposal that would share the runtime, and also documents the Python breakage: bindgen writes from . import livekit_datatrack into a flat out-dir with no __init__.py, giving ImportError: attempted relative import with no known parent package. #2930 (open) is the Swift → bindings-pipeline migration such a change would land on.

[github-actions]

Changeset ✓

This PR includes a changeset covering all affected packages:

Package	Bump
livekit	patch
livekit-api	patch
livekit-common	patch
livekit-data-stream	patch
livekit-datatrack	patch
livekit-ffi	patch
livekit-uniffi	patch

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

[ladvoc]

Wait, what happens if you simply do this:

uniffi::use_remote_type!(bytes::Bytes);

At least the docs for this macro imply this would work.

[pblazej]

@ladvoc looks like it won't work:

error[E0425]: cannot find type `UniFfiTag` in crate `bytes`

The first path segment isn't the crate that defines the type — it's the crate whose registration you're borrowing. The macro expands to <Bytes as FfiConverter<bytes::UniFfiTag>>, and bytes isn't a UniFFI crate, so it has no UniFfiTag. The docs are genuinely misleading here: their example borrows from another uniffi crate, so the path reads like a plain type path. You need a crate that called setup_scaffolding!().

[1egoman]

Nice, I'm a fan of the livekit-common approach!

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 3 additional findings in Devin Review. (Configure)