Discover desktop architecture
Maps desktop runtimes, native tools and storage boundaries before choosing an implementation approach.
desktop-architecture-discovery
See how it helpsWhen 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.
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:
- Embedded Runtimes & Native Binaries:
- Which shared libraries,
.nodeaddons, SQLite extensions, or helper binaries must ship inside the app bundle? - Which files must be unpacked outside read-only archives (
asarUnpackin Electron orresources/externalBinin Tauri) so the OS kernel candlopenorexecvethem?
- Which shared libraries,
- 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.
- 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.
- Explicitly list supported targets (
- Filesystem Separation:
- Separate read-only Application Bundle paths (
process.resourcesPath), mutable User Data (AppData/Roaming/~/Library/Application Support), Cache, and Logs from day one.
- Separate read-only Application Bundle paths (
Included files 1
SKILL.md
