← ClaudeAtlas

swiftui-programming-skilllisted

Use when work involves SwiftUI view composition, state and Observation ownership, navigation, adaptive layout, toolbars, forms, SF Symbols, accessibility, previews, or SwiftUI-specific performance. Do not use for UIKit/AppKit-only work, general Swift language questions, or architecture and performance work that does not involve SwiftUI.
fal3/claude-skills-collection · ★ 18 · Web & Frontend · score 79
Install: claude install-skill fal3/claude-skills-collection
# SwiftUI Programming Skill Build SwiftUI interfaces that are correct for the user's declared platforms and deployment targets. Ask for those targets when an API choice depends on them; never assume the newest SDK is deployable. ## Supported baseline The primary examples use Xcode 15, Swift 5.9, and iOS/iPadOS 17 or macOS 14. SwiftUI itself supports older systems, but newer APIs need explicit availability handling: | Need | Preferred API | Minimum | Compatibility path | |---|---|---|---| | Stack navigation | `NavigationStack` | iOS 16, macOS 13, tvOS 16, watchOS 9 | `NavigationView` remains valid for earlier targets | | Observation | `@Observable` | iOS 17, macOS 14, tvOS 17, watchOS 10 | `ObservableObject` and `@StateObject` remain supported | | Toolbars | `.toolbar` | iOS 14, macOS 11, tvOS 14, watchOS 7 | Put controls in the view hierarchy on earlier targets | | Modern change handling | zero- or two-parameter `onChange` | iOS 17, macOS 14, tvOS 17, watchOS 10 | Use the one-parameter overload on earlier targets | APIs from the OS 27 development cycle are beta material relative to the stable Xcode 26.6 toolchain. Discuss them only when explicitly requested, label them beta, and provide stable fallbacks plus `#available` gates. ## Workflow 1. Record Swift, Xcode, and every platform minimum. 2. Choose semantic system controls before custom controls. 3. Define state ownership and a stable identity model. 4. Choose navigation and layout from capabilities, not device-name