Bug: UniFFI bindings generation broken since v0.17.5 due to `strip = true`

[undermark5]

Bug: UniFFI bindings generation broken since v0.17.5 due to strip = true

This was explored with AI, and the majority of this report was produced with AI, as I am not incredibly familiar with Rust or UniFFI, but I am quite familiar with Android and Kotlin. I believe this summary to be accurate as far as what the root cause appears to be and the possible fix. I do not however understand if there are any other concerns that may come with the proposed fix. I do not know if there is a way to strip some portions but keep the relevant UniFFI metadata (I know proguard/r8 in the Android world would allow for such rules, so I imagine that it could be possible in the Rust world, I just do not know).

Description

UniFFI bindings generation has been broken since v0.17.5. The uniffi-bindgen tool returns empty metadata ([]) when run against compiled libraries, preventing Kotlin/Swift bindings from being generated.

Root Cause

In commit cbe4f04 (v0.17.5), a [profile.release] section was added to Cargo.toml with strip = true to optimize binary size. This strips the UniFFI metadata from the compiled library, making bindings generation impossible.

Impact

• All releases from v0.17.5 to v0.17.11 cannot generate bindings locally
• Developers cannot build Kotlin bindings for custom builds
• The published Android packages from v0.17.5+ appear to have been built without proper bindings

Reproduction

# v0.17.4 (works)
git checkout v0.17.4
cargo build --release
cargo run --features="uniffi/cli" --bin uniffi-bindgen -- print-repr target/release/libcooklang_bindings.so
# Returns full metadata ✓

# v0.17.5+ (broken)
git checkout v0.17.5
cargo build --release
cargo run --features="uniffi/cli" --bin uniffi-bindgen -- print-repr target/release/libcooklang_bindings.so
# Returns [] ✗

Fix

Change Cargo.toml:

[profile.release]
codegen-units = 1
strip = false  # Must be false to preserve UniFFI metadata

Verification

After changing strip = false, the metadata is correctly preserved and bindings generation works as expected.

Related

Last working release: v0.17.4
First broken release: v0.17.5
Breaking commit: cbe4f04

Assumptions

I have assumed that one would be generating the bindings from a release version of the library (the documentation seems to suggest this is accurate), if that is incorrect, then the documentation should be changed.