Orqestria Download
← Back to .NET desktop foundation team

Skill · Version 1.0.0

Discover desktop architecture

Maps desktop runtimes, native tools and storage boundaries before choosing an implementation approach.

desktop-architecture-discovery

Team members using this skill

See how it helps

When is it useful?

Use when an Electron or Tauri feature depends on OS tools or packaged binaries.

What does it help you do?

  • Distinguishes bundled runtimes from commands installed by the user.
  • Records target operating systems, architectures and native binary requirements.
  • Separates read-only application resources from writable user data.

Try asking this

Map our app's embedded server, Git dependency and local data paths for macOS and Windows. Trace startup on a machine without developer tools. List every required executable and show where its architecture-specific binary and writable data will live.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Desktop Architecture & Dependency Discovery

Wrapping a web UI in a desktop window does not automatically package its backend runtime, native database bindings, or external CLI dependencies. Before choosing or modifying a desktop shell, inventory every runtime dependency the application requires on a clean user machine where neither Node.js, Python, nor developer tools are pre-installed.

Framework Selection Matrix: Electron vs. Tauri

Base the framework choice on concrete runtime and dependency requirements—and validate with a minimal packaged prototype early:

Dimension Electron (Chromium + Node.js Main/Utility Process) Tauri v2 (OS WebView: WebKit / WebView2 + Rust Core)
Built-in Node.js Runtime Yes — runs an existing Node.js server, node:sqlite, or JS worker directly via Main or utilityProcess (ELECTRON_RUN_AS_NODE=1) No — Tauri does not include Node.js; running a Node backend requires bundling a standalone SEA/pkg sidecar binary (externalBin) per target triple or rewriting backend logic in Rust
Native Node Addons (.node / N-API) Supported via @electron/rebuild against Electron's ABI headers and asarUnpack Only usable inside a separately bundled Node sidecar
Rendering Consistency Identical bundled Chromium across macOS, Windows, and Linux Uses OS WebView (WKWebView on macOS, Chromium Edge WebView2 on Windows, webkit2gtk on Linux)—requires cross-engine CSS/font testing
Installer Size & RAM Overhead ~85–150 MB installer; Chromium + V8 baseline memory ~5–25 MB installer (excluding sidecars); lower idle memory when backend is Rust
Best Fit Apps with an existing Node.js server, SQLite/native JS ecosystem, or heavy child-process/CLI orchestration Apps with a lightweight web frontend + Rust core or self-contained native services

Dependency & Environment Inventory Checklist

Before building features, map four categories of dependencies:

  1. Embedded Runtimes & Native Binaries:
    • Which shared libraries, .node addons, SQLite extensions, or helper binaries must ship inside the app bundle?
    • Which files must be unpacked outside read-only archives (asarUnpack in Electron or resources / externalBin in Tauri) so the OS kernel can dlopen or execve them?
  2. External User-Installed CLIs (git, claude, codex, docker, language toolchains):
    • Never assume an external CLI is installed or authenticated. Build a startup preflight detector that checks binary availability, minimum version, and auth status, and surfaces a clear, actionable UI guide when a prerequisite is missing.
  3. Target Platforms & CPU Architectures:
    • Explicitly list supported targets (darwin-arm64, darwin-x64 / Universal, win32-x64, win32-arm64, linux-x64) and verify that every native dependency and sidecar binary is built for the target architecture.
  4. Filesystem Separation:
    • Separate read-only Application Bundle paths (process.resourcesPath), mutable User Data (AppData/Roaming / ~/Library/Application Support), Cache, and Logs from day one.

Included files 1

  • SKILL.md