Web UI.
Native code.
Attar exposes a C interface, with Rust ownership wrappers. A native program can own the application and link the UI engine into it. Compiled JavaScript reaches native operations through generated bindings.
One shared boundary.
Rust · C · C++
Your entry point, application logic and native libraries.
Typed calls
Matching headers, explicit ownership and native symbols.
Blink UI
The native interface, with an optional compiled JavaScript host.
The C ABI is the common calling convention. It avoids requiring another language to understand Rust’s internal data layout. A C++ library can expose a C-facing wrapper; other languages need compatible exports and their own bindings.
This is a build-time integration. Application dependencies must be known when the program is linked. Arbitrary Node addons and runtime executable loading are outside this model.
Keep your native entry point.
The client owns main. The Rust host adapter uses Cargo; the C adapter uses the system C compiler. Both link the application’s UI archive with a matching Attar client SDK.
The client SDK contains native machine code, public headers, resources and a manifest describing the link order and system libraries. It is a separate form from the compiler’s bitcode SDK.
Rust owns the handles
The Rust API wraps contexts, windows and views. It returns typed errors, releases handles through Drop and keeps UI operations on their owner thread. It uses the same C interface underneath.
The generated Rust host enters through the C API. Code that uses the native UI API directly can use the ownership wrappers.
Native embedding requires a compatible client-form SDK package. Rust and C host adapters exist, but the complete native-client workflow is not verified for this release. See release scope.
Call native operations
through generated bindings.
The JavaScript UI host has generated, typed declarations for native operations. The AOT compiler resolves those declarations to C symbols at link time. The UI can call into native code in the same program.
A binding defines the arguments, return values and ownership rules. Strings and byte buffers cross as explicit data; a native library still needs the correct declarations and lifetime handling.
This explains how Attar’s own UI bindings work. It is not an automatic import mechanism for any npm package or native library. The Electron capability providers are a separate planned product.
Languages and current tooling.
| Language | Integration route | Current tooling |
|---|---|---|
| Rust | C-compatible exports and Attar’s native UI API. | Host adapter and ownership wrappers exist. |
| C | Attar’s public C headers. | Reference host adapter exists. |
| C++ | A C-facing interface, with C++ details behind it. | Use the C ABI; no separate C++ host adapter. |
| Swift, Kotlin, Go, Zig | Language-specific exports or bridges into the C ABI. | Host adapters are planned. |
“Native code” does not imply that every language and target is ready. Each integration needs a matching toolchain, target and tested binding. Attar’s early C API is not frozen: compile against the headers shipped with the library you link.