← Back to Dex
AgentDex

Skill · Version 1.0.0

Discover desktop architecture

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

desktop-architecture-discovery

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