GO — Healthy across the board

• Last commit today
• 26+ active contributors
• Distributed ownership (top contributor 35% of recent commits)
• MPL-2.0 licensed
• Tests present
• ⚠ No CI workflows detected

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

UniFFI is a code-generation toolkit that compiles Rust business logic into shared libraries and auto-generates foreign-language bindings (Kotlin, Swift, Python, Ruby, C#, Go) from a single interface definition. It uses either WebIDL-like UDL files or Rust proc-macros to describe the object model, enabling write-once-call-everywhere functionality across mobile and desktop platforms. Monorepo organized as Cargo workspace with core generator in uniffi_bindgen and uniffi_pipeline, language backends in uniffi_core, macro support via uniffi_macros, and UDL parsing in uniffi_udl. Examples in examples/ directory demonstrate each language (arithmetic-procmacro, callbacks, custom-types, etc.). Test structure: bindgen-tests/ contains language-specific test suites (.kts for Kotlin, Swift bindings, Python/Ruby tests), while fixtures/ holds regression tests and benchmarks.

Rust library authors and platform teams at organizations like Mozilla who need to share core business logic across multiple native platforms (Android/Kotlin, iOS/Swift, web/Python) without maintaining separate implementations or hand-written FFI bindings for each language.

Production-ready and actively maintained. UniFFI is heavily used by Mozilla in Firefox mobile/desktop; the workspace contains 60+ crates, comprehensive test suites across bindgen-tests/ for each language, CI via .circleci/config.yml, and multiple fixture directories. However, the README explicitly states it's pre-1.0 with ongoing internal work, so breaking changes are possible across minor versions.

Low-to-moderate risk for stable consumers, higher for advanced use. The codebase is mature and Mozilla-backed, but the pre-1.0 status means API stability isn't guaranteed. Risk factors: complex cross-language code generation (subtle platform-specific bugs possible), Rust MSRV constraints affecting multiple targets, and reliance on external language toolchains (Kotlin/Swift/Python) that may have version incompatibilities. Single organizational maintainer (Mozilla) but active community contributions.

Active development visible in workspace members (recent addition of experimental-unsigned-types, keywords tests, mock-objects for Swift, dictionary-nesting features). The CHANGELOG.md and CI pipeline suggest regular releases. Third-party bindings expanding (JS/WASM via jhugman/uniffi-bindgen-react-native, Kotlin Multiplatform support emerging).

git clone https://github.com/mozilla/uniffi-rs.git
cd uniffi-rs
cargo build
cargo test
# Run a specific example:
cd examples/arithmetic
cargo build --release

Daily commands: Clone and build with cargo build. Examples can be run individually: cd examples/arithmetic && cargo build --release. Language-specific tests require relevant toolchains installed (Kotlin SDK, Swift compiler, Python 3, Ruby) and execute via CI in .circleci/config.yml. No dev server; this is a compile-time code generator.

• uniffi_bindgen/src/lib.rs — Main entry point for the code generation pipeline; all binding generation flows through this module
• uniffi_core/src/lib.rs — Core FFI traits and data serialization logic that all language bindings depend on
• uniffi_udl/src/lib.rs — UDL (interface definition language) parser that transforms interface specs into an AST used by code generators
• uniffi_macros/src/lib.rs — Proc-macro derive implementations for procedural API definition alternative to UDL files
• uniffi_pipeline/src/lib.rs — Orchestrates the entire build pipeline from UDL parsing through language-specific code generation
• Cargo.toml — Workspace manifest defining all component crates and their interdependencies
• README.md — High-level overview of UniFFI's purpose, supported languages, and philosophy for cross-platform Rust bindings

Add a new Rust type to generated bindings

1. Define the struct or enum in your library crate (e.g., examples/arithmetic/src/lib.rs) with #[derive(uniffi::Record)] for structs or #[derive(uniffi::Enum)] for enums (examples/arithmetic/src/lib.rs)
2. Implement or derive FfiConverter trait via uniffi macros to define serialization logic (uniffi_core/src/lib.rs)
3. Re-export the type in your public module and ensure it's included in the uniffi::include_scaffolding!() call (examples/arithmetic/src/lib.rs)
4. Run cargo build to trigger code generation; bindings appear in uniffi/<language>/generated (Cargo.toml)
5. Write a test in the appropriate language test suite (e.g., bindgen-tests/kotlin/tests/records.kts) to validate serialization (bindgen-tests/kotlin/tests/records.kts)

Add support for a new target language

1. Create a new language backend module in uniffi_bindgen/src/bindings/<lang>/mod.rs following the LanguageBinding trait (uniffi_bindgen/src/lib.rs)
2. Implement CodeGenerator trait with methods for generating function stubs, type mappings, and interface bindings (uniffi_bindgen/src/lib.rs)
3. Register the language in the code generation dispatcher by adding a match arm in uniffi_pipeline/src/lib.rs (uniffi_pipeline/src/lib.rs)
4. Create test fixtures in bindgen-tests/<lang>/tests/ with .udl definitions and language-specific test scripts (bindgen-tests/lib/src/lib.rs)
5. Update .circleci/config.yml to build and validate bindings for the new language in CI (.circleci/config.yml)

Add a new interface definition feature to UDL

1. Extend the UDL grammar and lexer in uniffi_udl/src/parser to recognize new syntax (uniffi_udl/src/lib.rs)
2. Add corresponding AST nodes in uniffi_meta/src/lib.rs to represent the new feature (uniffi_meta/src/lib.rs)
3. Update all language backends in uniffi_bindgen/src/bindings/ to handle code generation for the new AST node (uniffi_bindgen/src/lib.rs)
4. Add a test UDL file in bindgen-tests/lib/ and corresponding language test scripts to validate end-to-end behavior (bindgen-tests/lib/src/lib.rs)

Add a new serialization type to FfiConverter

1. Define the new type's serialization logic in uniffi_core/src/lib.rs by implementing FfiConverter trait (uniffi_core/src/lib.rs)
2. Update uniffi_meta/src/lib.rs type definitions to include the new type variant (uniffi_meta/src/lib.rs)
3. Update code generators in uniffi_bindgen for each language to emit correct marshalling code for the new type (uniffi_bindgen/src/lib.rs)
4. Add integration tests in bindgen-tests/lib/src/custom_types.rs and corresponding language test files (bindgen-tests/lib/src/custom_types.rs)

• Rust — Core business logic language; enables memory safety and performance, with FFI boundary guarantees
• Proc-macros (uniffi_macros) — Alternative to UDL files for interface definition; leverages Rust's declarative capabilities to reduce boilerplate
• Custom UDL language (weedle2 parser) — Platform-agnostic interface specification; decouples interface definition from Rust implementation, enabling language-agnostic contracts
• Code generation (uniffi_bindgen) — Automated binding generation eliminates manual FFI glue; reduces errors and keeps bindings in sync with Rust API changes
• RustBuffer serialization — Unified on-wire format across all language bindings; avoids language-specific marshalling complexity
• Cargo build integration — Seamless Rust ecosystem integration; binding generation happens during normal build pipeline

• Single-pass code generation from UDL/macros to target languages

  • Why: Simplifies pipeline and reduces intermediate representations; enables rapid iteration during development
  • Consequence: Code generators must be hardcoded per language; adding a new language requires implementing all backends simultaneously

• RustBuffer as universal serialization format rather than language-native marshalling

  • Why: Achieves cross-language compatibility; one serialization path for all bindings
  • Consequence: Slight performance overhead compared to native language serialization; all types must define RustBuffer layout

• Proc-macro and UDL both supported for interface definition

  • Why: Allows both 'zero config' (macros in Rust) and 'contract-first' (UDL) approaches; maximizes adoption
  • Consequence: Dual implementation overhead; interface definition validation logic duplicated across paths

• Bindings generated at build time into target/uniffi/<lang>/generated/

  • Why: Ensures bindings always match deployed binary; avoids version skew
  • Consequence: Generated code mixed with user code; larger build artifacts; requires all target languages available at build time

UDL namespace declarations affect generated code module paths across languages. Proc-macro requires exact attribute syntax (missing #[uniffi::export] silently skips functions). FFI handle counting for reference-counted objects is automatic but can cause unexpected cleanup if cycles exist. Swift tests require exact Xcode version matching CI (check .circleci/config.yml for version pins). Kotlin tests need kotlinc and Java toolchain in PATH. Unsigned integer types are experimental (see bindgen-tests/kotlin/experimental-unsigned-types/) and may have platform-specific behavior. Custom type UniffiCustomTypeConverter trait requires manual implementation per language.

• Foreign Function Interface (FFI) Handle Pattern — UniFFI's core abstraction—opaque integer handles reference Rust objects across language boundaries, enabling memory-safe object passing without exposing memory layout; critical to understanding bindgen-tests and uniffi_core/src/ffi.rs
• Intermediate Representation (IR) / Abstract Syntax Tree (AST) — UniFFI transforms UDL→IR→language-specific code, decoupling language definition from code generation; understanding uniffi_pipeline's IR structures is essential for adding language backends or modifying code generation logic
• RustBuffer: Serialization Container — UniFFI's standard mechanism for passing complex data types (strings, collections, structs) across FFI boundary; defined in uniffi_core/src/ffi.rs and critical for understanding why custom types need trait implementations
• WebIDL-based UDL (Unified Definition Language) — UniFFI's interface description syntax inspired by W3C WebIDL; used in .udl files and parsed by uniffi_udl crate; developers must understand UDL syntax to define stable cross-language APIs
• Procedural Macros (Attribute-based Definition) — Alternative to UDL files using Rust #[uniffi] attributes; eliminates separate .udl file maintenance but requires understanding macro expansion; uniffi_macros crate implements this strategy
• Reference Counting & Garbage Collection Bridge — UniFFI automatically manages object lifetime across Rust/foreign language boundary; handles are reference-counted to prevent use-after-free; essential when objects are shared between Rust and target languages
• Code Generation Backends as Template-driven Engines — Each language backend (Kotlin, Swift, Python, Ruby) uses template rendering to emit code from IR; understanding template structure in uniffi_bindgen/src/bindings/{language}/ enables extending UniFFI for new languages

• rust-diplomat/diplomat — Alternative FFI bindings generator focused on C/C++ interop; represents competing approach in same problem space with different language target priorities
• ralfbiedert/interoptopus — Similar multi-language FFI generator with focus on C# and Rust; explores different IR and code-gen strategy for comparison
• mozilla/application-services — Major production consumer of UniFFI (Firefox Sync, other shared components); demonstrates real-world usage patterns and integration strategies
• jhugman/uniffi-bindgen-react-native — Third-party React Native backend for UniFFI extending language support to JavaScript/TypeScript; shows how external teams extend UniFFI for new targets
• mozilla/fxa-rust-client — Early adopter demonstrating UniFFI's capability for cross-platform identity/auth libraries in production Firefox ecosystem

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for Swift keyword collision handling

The repo has bindgen-tests/swift/keywords directory structure in place but lacks visible test files similar to bindgen-tests/kotlin/keywords/tests/bindings/test_keywords.kts. Swift has different keyword semantics than Kotlin, and this test gap means Swift keyword escaping logic is likely under-tested. This is high-value because keyword handling is a critical correctness issue that affects library usability.

• [ ] Create bindgen-tests/swift/keywords/tests/bindings/test_keywords.swift with comprehensive Swift keyword test cases
• [ ] Add test coverage for Swift reserved keywords (e.g., class, struct, enum, protocol, extension, associatedtype)
• [ ] Add test_generated_bindings.rs in bindgen-tests/swift/keywords/tests/ to run the Swift tests during CI
• [ ] Reference bindgen-tests/kotlin/keywords/tests/test_generated_bindings.rs as a model for Rust test harness
• [ ] Verify generated bindings properly escape/rename conflicting keywords in Swift output

Add CI workflow for Python bindgen tests execution

The file structure shows bindgen-tests/python exists in the workspace members, but unlike Kotlin and Swift tests, there's no visible Python test runner in .circleci/config.yml (based on the provided snippet). This means Python binding generation is not validated in CI, creating risk of silent regressions. Adding this improves test coverage for one of the major target languages.

• [ ] Review .circleci/config.yml to confirm Python bindgen tests are missing from CI pipeline
• [ ] Create Python test files in bindgen-tests/python/tests/ (e.g., test_simple_fns.py, test_errors.py) mirroring Kotlin test structure
• [ ] Add .circleci/config.yml job to run Python tests (install Python, run pytest, validate generated bindings)
• [ ] Ensure Python test execution validates both binding generation and runtime correctness
• [ ] Add Python test execution to the main CI workflow (not just on-demand)

Create integration test suite for Ruby bindgen output validation

bindgen-tests/ruby exists in the workspace but has no visible test files like the Kotlin and Swift subdirectories do. Ruby is a major target language for UniFFI users, yet there's no evidence of automated validation of generated Ruby bindings. This is a significant gap that could allow Ruby-specific code generation bugs to slip through.

• [ ] Create bindgen-tests/ruby/tests/ directory structure with test files (e.g., test_simple_fns.rb, test_interfaces.rb, test_enums.rb)
• [ ] Mirror test coverage from bindgen-tests/kotlin/tests/ into Ruby equivalents
• [ ] Add a test_generated_bindings.rs file in bindgen-tests/ruby/tests/ to execute Ruby tests via the test harness
• [ ] Update bindgen-tests/ruby/Cargo.toml to reference test artifacts if needed
• [ ] Add Ruby test execution to .circleci/config.yml CI pipeline

• Add missing docstring generation for generated Python bindings (uniffi_bindgen/src/bindings/python/mod.rs currently lacks docstring extraction; examples/ have doc comments but docs aren't reflected in .py output)
• Extend error type tests in fixtures/error-types/ to cover all five supported languages (currently only Kotlin and Swift thoroughly tested; Python/Ruby/C# gaps visible in minimal fixture coverage)
• Document proc-macro limitations vs. UDL in RFC format (examples/arithmetic-procmacro works but design constraints around attribute parsing aren't formally captured; new contributors need explicit guidance on when to use which approach)

This is a Mozilla-maintained, well-structured Rust code generation project with no obvious critical security issues visible from static analysis. The project appears to follow Rust best practices and is part of Mozilla's ecosystem. However, being a code generation tool with cross-language bindings introduces inherent complexity. The main recommendations are: (1) ensure dependency auditing across all 40+ workspace members, (2) validate all UDL input thoroughly, (3) maintain comprehensive security testing for generated code, and (4) keep the circular CI/CD and dependency management practices strong. No exposed credentials, hardcoded secrets, or obvious injection vulnerabilities were detected in the file structure provided.

• Low · Workspace contains extensive test and example code — bindgen-tests/, examples/, fixtures/. The repository contains numerous test fixtures and examples across multiple languages (Kotlin, Python, Ruby, Swift). While test code is normal, this increases the attack surface and requires careful review of all test dependencies. Fix: Ensure test dependencies are properly audited and isolated from production builds. Use separate dependency specifications for test and production code.
• Low · Multiple crate members in workspace — Cargo.toml workspace members. The workspace contains 40+ member crates across different domains (bindgen, core, macros, testing, examples). This complexity increases the challenge of maintaining consistent security practices across the entire project. Fix: Implement automated security scanning across all workspace members. Use cargo-audit in CI/CD pipeline to detect vulnerable dependencies. Maintain clear security guidelines for all workspace members.
• Low · Code generation tool with broad scope — uniffi_bindgen, uniffi_pipeline, uniffi_udl. UniFFI is a code generation tool that produces bindings for multiple languages. Generated code could potentially have security implications if the generator has bugs. The tool processes UDL files which could be attack vectors if user input is involved. Fix: Implement input validation on all UDL file parsing. Add security tests for code generation edge cases. Document security best practices for generated code. Consider fuzzing the UDL parser.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mozilla/uniffi-rs shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mozilla/uniffi-rs repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mozilla/uniffi-rs.

What it runs against: a local clone of mozilla/uniffi-rs — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mozilla/uniffi-rs | Confirms the artifact applies here, not a fork | | 2 | License is still MPL-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mozilla/uniffi-rs. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mozilla/uniffi-rs.git
#   cd uniffi-rs
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mozilla/uniffi-rs and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mozilla/uniffi-rs(\\.git)?\\b" \\
  && ok "origin remote is mozilla/uniffi-rs" \\
  || miss "origin remote is not mozilla/uniffi-rs (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is MPL-2.0" \\
  || miss "license drift — was MPL-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "uniffi_bindgen/src/lib.rs" \\
  && ok "uniffi_bindgen/src/lib.rs" \\
  || miss "missing critical file: uniffi_bindgen/src/lib.rs"
test -f "uniffi_core/src/lib.rs" \\
  && ok "uniffi_core/src/lib.rs" \\
  || miss "missing critical file: uniffi_core/src/lib.rs"
test -f "uniffi_udl/src/lib.rs" \\
  && ok "uniffi_udl/src/lib.rs" \\
  || miss "missing critical file: uniffi_udl/src/lib.rs"
test -f "uniffi_macros/src/lib.rs" \\
  && ok "uniffi_macros/src/lib.rs" \\
  || miss "missing critical file: uniffi_macros/src/lib.rs"
test -f "uniffi_pipeline/src/lib.rs" \\
  && ok "uniffi_pipeline/src/lib.rs" \\
  || miss "missing critical file: uniffi_pipeline/src/lib.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mozilla/uniffi-rs"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.