Native SDK

Product Introduction

1. Definition: Native SDK is a declarative, native desktop application development toolkit. It is a complete framework that includes a custom markup language, a message-passing state management architecture, a built-in widget library, and its own deterministic, native renderer.
2. Core Value Proposition: Native SDK exists to bridge the gap between developer experience and native performance. It provides the expressive, declarative authoring model popularized by web technologies while eliminating the overhead of embedded browsers or WebViews, resulting in fast, small, and truly native desktop applications.

Main Features

1. Declarative Native Markup: Developers write UI layouts in a custom .native markup syntax, which is structurally similar to HTML/JSX but compiles directly to optimized native code. This markup describes the widget hierarchy (columns, rows, buttons, text fields) and binds directly to application state, offering compile-time validation and a readable authoring experience.
2. Predictable Message-Based State Model: Application logic follows a strict unidirectional data flow. UI events generate typed messages (defined as a Zig union), which are dispatched to a single update function. This function contains all state mutation logic, making state changes explicit, traceable, and easy to reason about or generate automatically.
3. Own Native Renderer & Engine: The toolkit's core innovation is its proprietary, deterministic rendering engine. It draws every UI widget directly into the operating system's native window surfaces using platform graphics APIs (e.g., Metal on macOS). There is no browser engine, JavaScript interpreter, or HTML/CSS renderer included in the final binary.
4. First-Class AI & Automation Workflow: The SDK is designed for co-authorship with AI agents. Its declarative nature and single-update-function pattern are predictable for AI to generate. Furthermore, every application embeds an automation server, allowing external tools to query the live widget tree (native automate snapshot), simulate input, and take screenshots for testing or agent-driven interaction.
5. Single Static Binary Output: The build process compiles the application's Zig logic and .native markup into a single, small executable (typically 3-6 MB). This binary contains no runtime interpreters, parsers, or script engines—just the application code and the lean Native SDK engine, linked against system frameworks.

Problems Solved

1. Pain Point: The performance and resource bloat of Electron/WebView-based desktop apps. Native SDK solves the problem of large download sizes, high memory usage, and inconsistent native feel by removing the Chromium runtime entirely.
2. Pain Point: The complexity and boilerplate of traditional native UI toolkits (e.g., Qt, wxWidgets, raw Win32/Cocoa). It simplifies native development with a modern, declarative syntax and a reactive state model, lowering the barrier to entry.
3. Target Audience: Desktop application developers prioritizing performance and a native user experience; teams building developer tools, creative software, or internal enterprise apps; projects where small binary size is critical (e.g., utilities, installers).
4. Use Cases: Building a performant system monitoring dashboard; creating a native Markdown editor with a live preview pane; developing a lightweight audio soundboard or streaming tool; prototyping and building internal business tools that need to feel integrated with the OS.

Unique Advantages

1. Differentiation: Unlike cross-platform frameworks that render via a WebView (Electron, Tauri, Wails) or use platform-native widgets but with imperative APIs (Qt, Avalonia), Native SDK uses a declarative markup for a web-like DX while rendering with a custom, lightweight engine for native performance and binary size.
2. Key Innovation: The combination of a compile-time declarative markup language with a message-passing state architecture, specifically designed to be deterministic and easily analyzable by both humans and AI agents. This creates a highly predictable and automatable application surface.
3. Key Innovation: The "chrome pass" and design token system demonstrated in the examples (e.g., soundboard vs. deck), allowing the same underlying widget set and engine to produce radically different visual identities—from standard desktop windows to custom-skinned, hardware-style interfaces—without changing the core logic.

Frequently Asked Questions (FAQ)

1. What programming language is used with Native SDK? The primary logic and backend for Native SDK applications are written in Zig. The UI structure is defined in a separate declarative .native markup file, which is compiled and integrated during the Zig build process.
2. How does Native SDK achieve such small binary sizes compared to Electron? Native SDK applications are small because they do not bundle a full browser engine (Chromium). The final binary contains only your application's compiled Zig code, the compiled UI markup, and the lean Native SDK rendering engine, which links against existing OS system libraries.
3. Can I use Native SDK to build mobile apps for iOS and Android? Native SDK has experimental support for iOS and Android. The core engine can cross-compile to these platforms, but the APIs and tooling are less mature than the desktop targets (macOS, Linux, Windows). Desktop is the primary, production-ready focus.
4. Does Native SDK support embedding a web browser view within an app? Yes, Native SDK supports co-existing with WebViews. It can host system WebView panels (or bundled Chromium Embedded Framework on macOS) within the same native window canvas, allowing you to mix native UI and web content where necessary.
5. Is the UI customizable, or am I stuck with a default look? The UI is highly customizable. While it provides beautiful default styling, the toolkit uses a design token system and allows for a full "chrome pass" (controlling window decoration and widget rendering style), enabling apps to establish a completely unique visual identity beyond standard OS themes.