macOS View Architect
SkillDev toolsmacOS SwiftUI view structure: refactor oversized scenes into subviews, explicit roots, scoped state, command/toolbar ownership, and narrow AppKit bridges.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the macOS View Architect skill
What this skill tells your AI
The instructions your AI receives, as published by xopoko/build-swift-apps in skills/macos-view-architect/SKILL.md and read by ahel’s review.
Refactor macOS SwiftUI toward explicit scene structure and focused files. Use macos-swiftui-architect for missing desktop patterns and macos-appkit-bridge for true AppKit boundaries.
Rules
- Model scenes explicitly: main window, settings, utility windows, inspectors, menu bar extras.
- Keep predictable order unless local style is stronger: environment, inputs, state, non-view computed vars, init, body, view helpers, actions.
- Split responsibilities:
App/<AppName>App.swift:@mainapp and minimal delegate only.Views/*: root composition and feature UI.Models/*: values, IDs, selection enums.Stores/*: state stores.Services/*: network, app-server, process clients.Support/*: small formatters/resolvers/extensions.
- Accept one-file apps only for tiny throwaway snippets: ~50 lines, one screen, no persistence/network/process client/reusable models.
- Prefer dedicated subview types over many computed
some Viewfragments; pass explicit data, bindings, and actions. - Keep root layout stable around selection/scenes/commands; avoid top-level branch swaps.
- Extract non-trivial actions, command routing, and toolbar behavior from
body. - Use
@SceneStoragefor per-window ephemeral state and@AppStoragefor durable preferences. - Keep AppKit bridges isolated behind small wrappers/helpers.
- For modern
@Observableowners, use@State; on older targets use@StateObject/@ObservedObject.
Workflow
- Identify scene boundary and whether the file owns too many responsibilities.
- Reorder top-to-bottom.
- Extract sidebar rows, detail panels, inspectors, toolbar content, and utility surfaces into subviews/files.
- Stabilize selection/layout.
- Move action/command/toolbar logic into named helpers or types.
- Narrow AppKit edges.
- Build after each major split and keep behavior intact unless requested.
Smells
- One root view owns window scaffolding, settings, toolbar, commands, service clients, and detail layout.
- iOS push navigation forced into a Mac sidebar-detail problem.
- Several booleans for mutually exclusive inspectors/sheets/windows.
- AppKit objects passed through unrelated SwiftUI layers.
- Large computed view fragments replacing real subviews.
Signals
- GitHub stars
- 45
- Forks
- 4
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
macos-view-architect- Source
- github.com/xopoko/build-swift-apps