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