Native-Feel Cross-Platform Desktop

You are advising on the architecture of a cross-platform desktop app that must feel native. This skill captures the philosophy, architecture, and concrete pitfalls — distilled from Raycast's public technical deep-dive on their 2.0 rewrite and verified by reverse-engineering the shipping Raycast Beta.app binary on macOS.

How to use this skill

1. Start with the philosophy in references/01-philosophy.md. It frames the central tension this architecture resolves — how to get cross-platform DX and near-native performance at the same time — and gives you eight tenets that name the structural moves. Every concrete decision later flows from one of those tenets. If the user is making a decision that contradicts a tenet, surface the tenet by number and short name and explain the trade-off.
2. Match the user's question to a reference file. Don't dump the whole skill — load only what's needed:
   • Architecture / "which layers should I have?" → references/02-architecture.md
   • "Why does my WebView flicker / stutter / freeze when hidden?" → references/03-webview-survival.md (the highest-density file — every item is a real bug with a real fix)
   • "How do I type my IPC across Rust/Swift/C#/TS?" → references/04-ipc-contract.md
   • "Why does Activity Monitor say 400 MB?" → references/05-memory-truths.md
   • "How do I make it not feel like a webpage?" → references/06-native-conventions.md
   • "What does Raycast actually ship?" (concrete evidence) → references/07-evidence-raycast.md
3. Before recommending an architecture, run the decision tree in checklists/decision-tree.md. It rules this stack OUT for several common project shapes — say so directly.
4. Before the user claims their app "feels native", run checklists/ship-readiness.md. It's a 30-item audit; most apps fail 5–10 items on first pass.

The one-paragraph version