bdk-rn pins uniffi-bindgen-react-native to an exact version, blocking coexistence with other ubrn libraries (+ 1.0 not on npm)

[bennyhodl]

Summary

We maintain a separate React Native library (@bennyblader/ddk-rn) that, like bdk-rn, is generated with uniffi-bindgen-react-native (ubrn). We want to use bdk-rn for the wallet and ddk-rn for DLCs in the same app, but hit three blockers. The core one is a hard version conflict between the two libraries' ubrn pods.

1. All bdk-rn releases pin uniffi-bindgen-react-native to an exact version, so two ubrn libraries can't coexist

BdkRn.podspec (and package.json) pin an exact ubrn version:

# BdkRn.podspec — v1.0.0, v2.2.0-alpha.1, v3.0.0-rc.3 all identical:
s.dependency "uniffi-bindgen-react-native", "0.30.0-1"

Our ddk-rn is generated with a newer ubrn and pins uniffi-bindgen-react-native "0.31.0-3". Since an app can only resolve one version of the uniffi-bindgen-react-native pod, CocoaPods fails:

[!] CocoaPods could not find compatible versions for pod "uniffi-bindgen-react-native":
    - bdk-rn depends on uniffi-bindgen-react-native (= 0.30.0-1)
    - DdkRn depends on uniffi-bindgen-react-native (= 0.31.0-3)

This makes bdk-rn incompatible with any other ubrn-generated RN library that isn't on the exact same ubrn version. The generated podspec pins = (exact) rather than a compatible range, which guarantees a clash the moment two ubrn libraries pick different ubrn releases.

Requests (any one would help):

• Publish bdk-rn builds generated against current ubrn (0.31.x), or
• Relax the generated dependency from = 0.30.0-1 to a compatible range (e.g. ~> 0.31), or
• Document the intended way for multiple ubrn libraries to share one ubrn runtime pod version in a single app.

2. bdk-rn 1.0.0+ is not published to npm

npm view bdk-rn versions → ["0.1.0","0.1.1","0.29.0","0.30.0"] (dist-tag latest = 0.30.0). The 1.0.0 / 2.x / 3.0-rc releases exist only as GitHub release tarballs (bdk-rn-1.0.0.tgz), so consumers can't npm install bdk-rn@1 and are stuck on the old 0.30.0. Publishing 1.0.0 to npm would unblock everyone off the pre-new-arch build.

3. bdk-rn 0.30.0 (the npm latest) fails to build on RN 0.75 new architecture

Because 1.0+ isn't on npm, 0.30.0 is what most people get — and it doesn't compile under the New Architecture. BitcoinDevKit.swift does import bdkFFI, but with static pod linkage (the default when use_frameworks! is off) under new-arch the vendored dynamic bdkFFI.framework module isn't placed on the Swift import path, so the whole file fails:

BitcoinDevKit.swift:22:25: error: cannot find 'ffi_bdk_bc5f_rustbuffer_from_bytes' in scope
BitcoinDevKit.swift:431:5:  error: cannot find 'bdk_bc5f_Address_new' in scope
... (every bdk_bc5f_* / ffi_bdk_bc5f_* symbol)

(The bdkFFI.xcframework itself is complete — headers + module.modulemap are all present — it's purely a linkage/import-path issue under new-arch static linking.)

Environment

• bdk-rn 0.30.0 (npm), and 1.0.0 / 3.0.0-rc.3 (GitHub) inspected
• React Native 0.75.5, New Architecture enabled (RCT_NEW_ARCH_ENABLED=1)
• Xcode 26.x, CocoaPods, iOS simulator
• Coexisting ubrn library: ddk-rn (ubrn 0.31.0-3)

Happy to test any fix or provide a minimal repro. Thanks for the great work on bdk-rn 🙏

[thunderbiscuit]

I'm totally open to bumping + relaxing the ubrn version! A few months back when I was getting this library up and running we had issues with ubrn, I can't even remember exactly what (something related to our pinning of uniffi-rs maybe?). Anyway happy to fix this if we can make sure this works with the latest on bdk-ffi.

As for the old bdk-rn, it is at this point unmaintained and I don't know if it will see much action/bug fixes. The BDK 0.X series is really old at this point. I am actively working with the maintainer there to publish this 1.0 version on npm so users would get access directly, without changing their dependency.