native-os-integration

name	native-os-integration
description	Wire native OS integration the way each platform expects — tray/menu-bar, application menus, notifications, file associations, custom-scheme deep links routed through a single-instance lock, and secrets in the OS credential store.

Native OS Integration

Follow each OS's conventions

• Tray / menu bar. A macOS menu-bar item and a Windows system-tray icon behave differently — use the platform idiom, not one cross-OS approximation.
• Application menus. macOS expects a real app menu (with the standard App/Edit/Window items); Windows/Linux put menus on the window. Build per-OS menu templates.
• Notifications. Use the OS notification API; request/respect permission and the OS Do-Not-Disturb/focus state.

Single instance + deep links + file associations

Most desktop apps should be single-instance:

• Acquire a single-instance lock at startup; if a second launch happens, focus the running window and hand it the new argv (the file path or deep-link URL).
• Register a custom URL scheme (myapp://…) and/or file associations at install; route both through the single-instance handler so the app reacts whether it was already running or cold-started.
• Validate the deep-link/file payload before acting — it is untrusted input that can arrive from a browser or another app.

Secrets in the OS store

Tokens/secrets go in the OS credential store — Keychain (macOS), Credential Manager (Windows), libsecret (Linux) — via Electron safeStorage or Tauri Stronghold/keyring. Never plaintext config. When Linux has no secret service, name the fallback (e.g. an encrypted file with an explicit weaker-guarantee note) rather than silently writing plaintext.

Lifecycle

Persist and restore window state; handle minimize-to-tray vs quit per the app's intent; flush unsaved work on before-quit.