…ures (#709)

* Adopt noir-rs v1.0.0-beta.19 (barretenberg-rs migration)

- Bump the CLI noir-rs pin to the immutable v1.0.0-beta.19 tag and drop
  the obsolete android-compat feature.
- Regenerate noir_multiplier2 fixtures (.json, .srs, .vk) under nargo
  1.0.0-beta.19 so a fresh `mopro init --adapter noir` build is green
  end-to-end.
- Add a Poseidon-flavored VK fixture (`noir_multiplier2_poseidon.vk`).
  Ultra-Honk verification keys encode the oracle hash since beta.19, so
  the same .vk file can no longer drive both Poseidon and Keccak prove
  paths; the two `_with_vk` Poseidon tests now read it.
- Capture the regeneration recipe as `scripts/regen-noir-fixtures.sh`
  with a small Rust helper, and check in the multiplier2 circuit source
  under `test-vectors/noir/multiplier2/`.
- Refresh adapter docs, rust-setup snippet, and the May 2025 noir blog
  post to match (drops x86_64-apple-ios from the noir support matrix
  and points users at crates.io/barretenberg-rs instead of the no-longer
  load-bearing aztec-packages releases).

Closes #704.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* ci: bump android emulator to api-level 30

The official barretenberg-rs prebuilt for x86_64-linux-android references
__libc_single_threaded, which bionic only exposes from API 30 onwards.
The previous custom bb binaries from zkmopro/aztec-packages didn't, so
the emulator could stay on API 29. Without this bump, cli_build_android
fails with `dlopen failed: cannot locate symbol "__libc_single_threaded"`
on the noir adapter, but cross-compilation succeeds, so the regression
slipped past the upstream noir-rs CI matrix (which never runs an emulator).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore(android): set minimum API level to 30 for build config

Added the -p argument with value 30 to the Android build configuration to enforce a minimum API level of 30, ensuring compatibility with the required symbols in the barretenberg-rs prebuilt for x86_64-linux-android.

* fix(android): use --platform (long form) for cargo-ndk

cargo-ndk 4.x parses -p as cargo's --package, so the previous attempt
panicked with `unknown package: 30`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* ci(android): bump cli_build_android timeout to 20 minutes

Noir's barretenberg compile hits ~14m on its own, leaving the emulator
instrumented test ~1m before the 15m timeout cancels it. Other adapters
finish in 8-9m so the bump is just slack for noir.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(android): shim __libc_single_threaded for noir adapter

The Aztec barretenberg prebuilt linked via barretenberg-rs references
__libc_single_threaded, a libc++ atomics hint symbol that bionic does
not export on any current Android API. dlopen of the generated .so
fails on every emulator and device. cargo-ndk --platform N cannot
remove the reference since it is baked into the upstream static
archive. Define the symbol locally in the noir template so the
dynamic linker resolves it inside our own .so; value 0 ("multi-
threaded") is the correct default since libc++ only reads it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(android): download correct barretenberg Android prebuilt via BB_LIB_DIR

Root cause of the noir Android dlopen failures: barretenberg-rs's build.rs
selects its prebuilt archive by substring-matching the target triple with
"linux" checked before "android". The triple x86_64-linux-android contains
"linux", so it downloads barretenberg-static-amd64-linux.tar.gz (a glibc /
libstdc++ build) instead of the x86_64-android (libc++) one. The resulting
.so references symbols Android has no provider for (__libc_single_threaded
from glibc, std::__cxx11::* from libstdc++), so dlopen fails at runtime.

The bug exists in every published barretenberg-rs (4.2.0-aztecnr-rc.2 pinned
by noir-rs, through 4.4.0-nightly); it is only fixed on aztec-packages
next/master, which are unpublished. A version bump cannot fix it.

barretenberg-rs honours BB_LIB_DIR ahead of its own download, so in the
Android build path we now detect a barretenberg-rs dependency (via the
project's resolved Cargo.lock), pre-fetch the correct
barretenberg-static-<arch>-android.tar.gz for the matching version, and point
BB_LIB_DIR at it before invoking cargo ndk. No-op for adapters that do not use
barretenberg-rs.

Verified: a noir example built for x86_64-linux-android now produces a .so
with zero undefined __libc_single_threaded / __cxx11 /
_ZTTNSt7__cxx1119basic_ostringstream symbols (only libc++ std::__1 refs, met
by the bundled libc++_shared.so).

Also reverts the __libc_single_threaded shim from 55ac32a, which treated a
symptom of the wrong-library download and is unnecessary with the correct lib.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* style(android): rustfmt build_for_arch call in android.rs

The BB_LIB_DIR commit hand-edited the build_for_arch(...) call and
left it unformatted, failing `cargo fmt --all -- --check` in the lint
gate. That blocked every downstream cli_build_* job from running.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(android): correct min-API comment for barretenberg prebuilt

The `--platform 30` floor was annotated `// API 30 minimum` and justified
in 69977f9/11cd70b by the __libc_single_threaded symbol — which the
root-cause fix (04a2f51) showed was an artifact of the wrong glibc archive,
not a real requirement.

Symbol inspection (llvm-nm/llvm-readelf) of the correct libc++ prebuilt
`libbb-external.a` shows the actual driver of the floor: GLOBAL undefined
imports `__tls_get_addr` (bionic libc.so, API 29 on x86_64) and
`getifaddrs`/`freeifaddrs` (API 24), absent from cargo-ndk's default API 21.
A floor is therefore genuinely required (true minimum 29 x86_64 / 24 arm64);
the value 30 is kept as a small margin. Also tightens the BB_LIB_DIR note.

Comment-only; no behavior change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(android): link noir adapter with Zig to resolve barretenberg libc++ ABI

The beta.19 barretenberg Android prebuilt is Zig-built against upstream libc++
(std::__1); the NDK's std::__ndk1 can't satisfy its symbols, so dlopen fails at
runtime (e.g. the basic_ostringstream VTT). Route the final link through a
`zig cc` wrapper so Zig's __1 libc++ is baked in, keeping the NDK's
libc++_shared.so for other C++. Adds a noir-only Zig setup step to CI.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* test(ios): widen noir UI-test timeout for slower beta.19 proving

beta.19 barretenberg proving on loaded CI simulators exceeds the 5s the other
adapters use, making testNoirProveVerify flaky (passed at 55ac32a, failed at
0e559a1 with no functional change between). Raise prove to 120s, verify to 60s;
the proof itself is valid (native Rust tests pass).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(android): generate noir bindings from an NDK-linked lib

The shipped noir lib is Zig-linked (to resolve barretenberg's std::__1 libc++),
but zig cc drops the static .symtab that uniffi-bindgen reads, so binding
generation produced nothing and reformat_kotlin_package panicked.

Build a separate NDK-linked debug lib for metadata only (identical metadata,
keeps .symtab; it can't run, but bindgen never runs it) and generate bindings
from it, while still shipping the Zig-linked .so. Bump the noir Android CI
timeout to cover the extra build.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* ci(ios): retry flaky noir simulator UI test

testNoirProveVerify is flaky: barretenberg beta.19 proving of multiplier2 is
milliseconds natively (19 tests in 1.41s) but bimodal on the CI simulator —
usually <5s, occasionally stalling past the 120s timeout. The stall is a
~100,000x outlier (an upstream barretenberg-on-simulator issue, not a bad
proof): same code+timeout passed at 8dd403c, and the only change since is
Android-only.

Retry noir up to 3x via -retry-tests-on-failure so one stalled roll doesn't
fail the build; other adapters stay strict to keep real regressions visible.
Bump noir's step timeout to 25m for retry headroom.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(android): trim duplicated noir bindgen comments

The bindgen call-site repeated the .symtab/Zig rationale already documented
on build_bindgen_lib; drop one test comment that restated its test name.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(android): fail loudly on unresolved barretenberg version; cache prebuilt per version

Two robustness fixes to the noir Android build path from pre-landing review:

- barretenberg_rs_version now bails on a failed generate-lockfile and
  propagates Cargo.lock read errors instead of returning Ok(None). A real
  failure no longer silently relinks barretenberg-rs's wrong glibc prebuilt
  and ships a lib that fails dlopen at runtime; Ok(None) means only "crate
  absent".
- The BB prebuilt cache key now includes the version (bb-android-prebuilt/
  <arch>-<version>). build/ survives cleanup_tmp_local, so an arch-only key
  would relink a stale .a after a noir-rs bump.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(test-vectors): clear machine-specific file_map for reproducible noir fixtures

nargo bakes the absolute source path into the circuit JSON's file_map, so the
committed fixture leaked a local home-dir path to every mopro init user and
regenerating on another machine produced a spurious diff. Clear file_map in the
committed JSON (proving only reads bytecode) and add a normalize step to
regen-noir-fixtures.sh so the recipe is host-independent.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(android): move noir/barretenberg build setup out of mopro-ffi

Keep mopro-ffi's Android builder adapter-free (per review). AndroidBindingsParams
is now a generic struct (arch_overrides / min_sdk_version /
relink_with_ndk_for_bindgen) and android.rs carries no barretenberg/noir/Aztec
knowledge. All noir-specific logic (prebuilt download, Cargo.lock version parse,
Zig linker wrapper, NDK discovery) moves to cli/src/build/android_noir.rs, driven
from cli/src/build.rs only when Noir is selected, mirroring IosBindingsParams.

`mopro build` drives the build in-process via the CLI, so no mopro-ffi release is
needed; generated projects still build against the published =0.3.6. Restores
cargo-ndk's default min API for non-noir Android builds (--platform 30 is now
noir-only), and adds cargo-ndk exit-status checks plus a relative-build_dir join
fix in the generic builder.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(noir): address review nits in docs and fixture tooling

- blog: mark x86_64-apple-ios unsupported (dropped in noir-rs beta.19)
- noir.rs template: fix "fotr" -> "for" typo
- regen-noir-fixtures.sh: enforce nargo v1.0.0-beta.19 instead of only printing it
- regen-noir-fixtures: pin noir-rs by immutable rev for reproducible fixtures

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(noir): drop regen-noir-fixtures tooling and tautological parser tests

Per review, remove the manual fixture-regeneration apparatus
(scripts/regen-noir-fixtures.sh, its helper crate, and the now-orphaned
test-vectors/noir/multiplier2 circuit source) to revisit after the circuit
compile/reuse refactor. The committed .json/.srs/.vk fixtures the tests consume
are untouched.

Also trim the barretenberg-rs version parser tests to the one meaningful case
(distinguishing a dependency mention from the package entry); the other two just
re-derived their mocked input.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* style(android): satisfy cargo fmt in the refactored builder

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore: remove unnecessary patch

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Remove circom-prover module and associated files

This commit deletes the entire circom-prover module, including its source code, configuration files, and documentation. The removal is part of a broader refactor to streamline the project and eliminate unused components. No functional changes are introduced as a result of this commit.

* Remove circom-prover references from Cargo files and documentation

This commit eliminates all traces of the circom-prover module from the project, including its dependencies in Cargo.lock and its documentation in README.md. The workspace configuration in Cargo.toml has also been updated to reflect this removal. This change is part of an ongoing effort to streamline the project by removing unused components.

* Remove circom-prover configuration and CI references

This commit deletes the circom-prover configuration from the Cargo files and removes related environment variables from the CI workflow. These changes are part of the ongoing effort to streamline the project by eliminating unused components and references.

#717)

* Update Rust toolchain to nightly-2025-11-15 and enhance WASM build configuration

- Changed Rust toolchain version in CI workflow and configuration files to nightly-2025-11-15.
- Updated WASM build flags in `.cargo/config.toml` to include shared memory and various export options, while adjusting the maximum memory limit.
- Removed obsolete package version patching from `web.rs` to streamline the build process.

These changes ensure compatibility with the latest Rust features and improve the WASM build process.

* Update WASM build configuration and add nightly toolchain constant

- Added `+mutable-globals` to the WASM build flags in `.cargo/config.toml` for enhanced functionality.
- Introduced a new constant `WASM_NIGHTLY_TOOLCHAIN` in `constants.rs` to centralize the toolchain versioning.
- Updated `web.rs` to utilize the new constant for improved maintainability and clarity in the build command.

These changes streamline the configuration and ensure consistency across the project.

* Update dependencies and versioning in Cargo files

- Bump versions of several dependencies in `Cargo.lock`, including `askama`, `askama_derive`, `bytes`, `camino`, `cargo-platform`, `cargo_metadata`, `fs-err`, `serde`, and `serde_json` to their latest releases for improved functionality and security.
- Introduce `askama_macros` and `serde_core` as new dependencies to enhance the project structure.
- Update `uniffi` version in `Cargo.toml` to `0.32.0` to align with the latest changes in the dependency tree.
- Rearrange constants in `web.rs` for better readability and maintainability.

These updates ensure compatibility with the latest features and improvements across the project.

* Update mopro-cli and mopro-ffi to version 0.3.7-alpha.0

- Bump the version of `mopro-cli` and `mopro-ffi` to `0.3.7-alpha.0` in their respective `Cargo.toml` files.
- Update dependency versions in `Cargo.lock` to reflect the new version for `mopro-ffi`.
- Ensure compatibility across the project with the updated versioning.

These changes prepare the project for the next development phase and maintain consistency in dependency management.

* Enhance CI workflow by installing Kotlin 1.9.24

- Added a step to the GitHub Actions workflow to install Kotlin version 1.9.24, ensuring the environment is set up with the required Kotlin compiler for the project.
- This update improves the build process by providing the necessary tools for Kotlin-based tasks.

These changes support the ongoing development and testing efforts within the project.

* Add module shim for Xcode 26 compatibility

- Introduced a `module/` directory alongside the xcframework to include a copy of the FFI header and a `module.modulemap`, addressing Xcode 26's change in module map registration for static-library XCFrameworks.
- Updated the `project.pbxproj` file to include the `OTHER_SWIFT_FLAGS` for module map file location, ensuring proper integration with the new structure.

These changes enhance compatibility with Xcode 26 and streamline the build process for iOS projects.

* Refactor module map handling for Xcode 26 compatibility

- Removed the embedded module map from the FFI header artifacts, as the new `module/` shim directory is now the sole definition for all Xcode versions.
- Updated comments to clarify the changes in module map registration for static-library XCFrameworks, ensuring compatibility with Xcode 26 and avoiding duplicate-module errors.

These modifications streamline the build process and enhance compatibility with the latest Xcode versions.

* Refactor file removal logic in iOS app configuration

- Simplified the file removal logic for the module map source in the `regroup_header_artifacts` function, ensuring clearer context handling during the removal process.
- This change enhances code readability and maintains the existing functionality without introducing any new behavior.

These modifications contribute to a cleaner and more maintainable codebase.

Section 2-1 of the Flutter setup guide told users to add a
`mopro_flutter_plugin` dependency at `path: ./mopro_flutter_plugin`, but
the folder copied in step 1 (and used everywhere else in the page, in the
imports, and by the Mopro CLI scaffolding) is `mopro_flutter_bindings`.
This leftover from the old plugin-based flow would fail to resolve. Update
the snippet to `mopro_flutter_bindings` / `path: ./mopro_flutter_bindings`.


Claude-Session: https://claude.ai/code/session_01Smkp7CuhA7VjLwriicL12a

Co-authored-by: Claude <noreply@anthropic.com>

Drop the redundant `&` on format arguments in mopro-ffi's Android
app_config and the CLI's print module, fixing the useless_borrows_in_formatting
lint failure under -Dwarnings.

#721)

* Implement React Native Noir bindings and enhance Android build process

- Introduced a new module for React Native Noir bindings, integrating it into the build process for the React Native platform.
- Enhanced the Android build logic to conditionally apply architecture-specific parameters based on the presence of iOS architectures and the Noir adapter.
- Updated the `android_noir` module to utilize a custom Zig linker for resolving ABI compatibility issues with the barretenberg prebuilt.
- Refactored the React Native project creation logic to ensure proper handling of architecture-specific Gradle properties and cleanup of stale files.
- Improved the `package.json` template for React Native to include necessary configurations and dependencies for the new setup.

These changes streamline the integration of Noir with React Native and improve the overall build process for Android.

* Refactor build process for React Native and improve print output

- Enhanced the build logic in `build.rs` to better handle architecture-specific parameters for iOS and Android, ensuring proper integration of Noir bindings.
- Simplified the initialization message in `print.rs` for improved readability by using direct string interpolation.
- Updated Android build configurations to streamline the generation of bindings and ensure compatibility with the latest architecture requirements.

These changes improve the overall build process and user experience when initializing projects.

* Update build configuration for React Native Noir bindings

- Modified `.gitignore` to exclude the `cli/src/build/` directory from being ignored, allowing for better management of build artifacts.
- Introduced a new file `react_native_noir.rs` in `cli/src/build/`, implementing a specialized build process for React Native Noir, which includes architecture-specific handling and binding generation from NDK-linked libraries.

These changes enhance the build process for React Native projects utilizing Noir, ensuring proper integration and compatibility with architecture-specific requirements.

* Fix CI workflow conditions and add Zig setup for Noir adapter

- Corrected the conditional checks in the GitHub Actions workflow to ensure proper execution during pull requests.
- Introduced a new step to set up Zig for the Noir adapter, addressing ABI compatibility issues with the barretenberg prebuilt.

These changes enhance the reliability of the CI process and improve the build environment for the Noir adapter.

* Enhance error handling in React Native project setup

- Updated the error handling in `react_native.rs` to provide more context when reading configuration files fails, specifically for missing files.
- Refactored the logic for reading the Gradle properties in `react_native.rs` and `react_native.rs` to use a match statement, improving clarity and robustness.
- Improved error reporting in `patch_android_cmake_lists_uniffi_bindgen_resolve` and `patch_gradle_properties_architectures` functions to handle file read errors gracefully.

These changes improve the reliability of the project setup process and enhance the user experience by providing clearer error messages.

* v0.3.7