view-refactor

Refactor macOS SwiftUI views and scenes into stable, focused structures.

Updated Jul 31, 2026
One-click install
npx skills add https://github.com/AarnavBaddam/skills --skill view-refactor-aarnavbaddam
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: view-refactor
Source: https://github.com/AarnavBaddam/skills/tree/main/view-refactor
Command: npx skills add https://github.com/AarnavBaddam/skills --skill view-refactor-aarnavbaddam

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? macOS SwiftUI codebases often grow into monolithic files where one root view owns window scaffolding, settings, toolbars, commands, and detail layout, making the app hard to maintain and extend. This Skill provides a structured refactoring methodology to split oversized views, stabilize scene and selection structure, and keep AppKit interop contained. ## Core Features & Use Cases - Scene and File Decomposition: Split apps into explicit scene roots and organized directories (App/, Views/, Models/, Stores/, Services/, Support/) with a predictable file ordering. - Subview Extraction: Replace large computed view fragments with dedicated subview types that receive explicit data, bindings, and actions. - State and Interop Discipline: Apply correct usage of @SceneStorage, @AppStorage, @Observable/@State, and isolate AppKit bridges behind narrow wrappers. - Use Case: Given a single 800-line Swift file containing the @main app, sidebar, detail view, models, and a URLSession client, refactor it into a minimal app entrypoint, focused feature views, extracted models and stores, and a Services/ networking client while preserving behavior. ## Quick Start Use the view-refactor skill to split my oversized macOS SwiftUI ContentView into focused subviews and move the networking code into a Services directory.

Frequently Asked Questions about view-refactor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a large SwiftUI view into smaller files?

Extract meaningful sections like sidebar rows, detail panels, and inspectors into dedicated subview types that receive explicit data, bindings, and actions. Keep the root view focused on layout and composition, and move models, stores, and service clients into separate Models/, Stores/, and Services/ files.

How should I structure a macOS SwiftUI app project?

Use App/<AppName>App.swift for the @main entrypoint and AppDelegate only, keep ContentView focused on root layout, and place feature views in Views/, value types in Models/, stores in Stores/, and networking or process clients in Services/. Single-file apps are acceptable only for tiny throwaway examples under roughly 50 lines.

When should I use @SceneStorage vs @AppStorage in SwiftUI?

Use @SceneStorage for per-window ephemeral state that helps restore an individual scene, such as selection or scroll position. Use @AppStorage only for durable user preferences, not transient UI toggles that matter in just one window.

Should I use @State or @StateObject with @Observable classes?

On modern macOS targets, store @Observable reference types as @State in the owning view and pass them explicitly to children. On older deployment targets, fall back to @StateObject and @ObservedObject where needed.

When is AppKit interop appropriate in a SwiftUI Mac app?

Use AppKit only at narrow edges where desktop behavior genuinely requires it, such as specific NSWindow behavior. Isolate any representable or window bridge behind a small wrapper, and re-evaluate the architecture if the bridge starts owning the feature.