What problem does it solve? Designing a native macOS app raises recurring structural questions—MV vs. MVVM, where state belongs, when to split into SwiftPM modules, how to handle Sparkle updates—that generic iOS-oriented guidance answers incorrectly or not at all. ## Core Features & Use Cases - Architecture decision layer: Twenty Quick Rules covering bounded-context stores, Environment-based dependency injection, Screen/View naming, enum-based events, and observation patterns, each backed by measured or verified evidence. - Anti-pattern catalog: Side-by-side wrong/right code for common mistakes such as one ViewModel per screen, sum-type view state, the AnyView shim across feature boundaries, and directory-watcher feedback loops. - Distribution and longevity guidance: Decisions that must be made before the first release, including sandbox impact on Sparkle entitlements, EdDSA key custody, and containing fragile third-party dependencies. - Use Case: When adding a settings screen with a Sparkle update check to a SwiftUI macOS app, consult the skill to learn why the updater must be owned by the App via @StateObject behind an UpdateChecking protocol rather than a global singleton. ## Quick Start Ask the AI to review your macOS app's structure against the macos-app-architecture skill's Quick Rules and anti-patterns before creating a new store, view, or module.
