# Swift Skill > Use for implementation and review of native iOS applications or modules built with Swift, SwiftUI, UIKit, SwiftData, and Apple frameworks. Use directly for a known native stack; use ios-app-development first when choosing Swift versus Flutter or defining a mixed-stack boundary. - Skill: `bejeweledme/swift-skill` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add bejeweledme/swift-skill` - Raw SKILL.md: https://api.skillmd.com/api/skills/bejeweledme/swift-skill/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: BejeweledMe (https://skillmd.com/u/bejeweledme) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/bejeweledme/swift-skill --- # Swift Skill Use this skill to design, review, validate, debug, implement, or release native iOS applications and modules built with Swift, SwiftUI, UIKit, SwiftData, and Apple frameworks. Treat native iOS quality as the product of Swift language design, Apple platform constraints, state/data ownership, privacy, performance, testing, signing/release, and maintenance. ## Core Rule Do not start from a pattern name like MVVM, Clean, TCA, or "pure SwiftUI". First clarify product goals, target iOS versions, Apple frameworks/capabilities, data/offline needs, SwiftUI/UIKit boundaries, concurrency/lifecycle constraints, privacy/security requirements, performance budget, testing depth, signing/release target, and ownership. ## Hierarchy And Handoffs This skill owns native-language and Apple-framework decisions after Swift is the selected implementation path. Enter directly for a known Swift codebase or native module. For a stack choice, cross-platform product tradeoff, or Flutter/native split, start with `$ios-app-development`. Use `$ios-app-development` again when a local Swift decision changes platform-wide capabilities, privacy posture, release ownership, or the contract with a Flutter shell. Do not use this skill for Dart, Flutter state architecture, or Flutter plugin implementation; route those to `$flutter-skill`. ## Reference Routing Read only the references needed for the current task. - Always start with `references/01-swift-native-architecture.md` for broad Swift/native design or review. - For SwiftUI views, state ownership, navigation, UIKit interoperability, and UI architecture decisions, read `references/02-swiftui-state-navigation.md`. - For SwiftData, persistence, networking, repositories, cache/offline, migrations, and source-of-truth design, read `references/03-swiftdata-networking-persistence.md`. - For Swift concurrency, `async`/`await`, actors, actor reentrancy, `MainActor`, `Sendable`, app lifecycle, background work, ARC, leaks, and performance, read `references/04-swift-concurrency-memory-performance.md`. - For Apple APIs, permissions, entitlements, privacy manifests, SDK signatures, Keychain, client trust boundaries, testing, observability, signing, TestFlight, App Store, and production readiness, read `references/05-swift-platform-security-testing-release.md`. ## Workflow 1. Classify the request: - New native app/feature design: read `01`, then `02`, `03`, `04`, `05` as needed. - Swift architecture/code review: read `01`, `04`, and the topic-specific references. - SwiftUI/UI-state/navigation: read `02`, then `04` for lifecycle/concurrency risks. - Persistence/offline/networking: read `03`, then `04` and `05`. - Concurrency/memory/performance debugging: read `04`, then `01` or `02`. - Privacy/security/platform capability work: read `05`, then `03` or `04` if data/concurrency is involved. - TestFlight/App Store/release readiness: read `05`, then `04` for performance/lifecycle risk. 2. Ask only for blocking details; otherwise state assumptions and proceed. 3. Preserve Swift semantics: distinguish value/reference behavior, ARC ownership, actor isolation, and SwiftUI state ownership. 4. Prefer the simplest architecture that preserves testability, lifecycle correctness, platform compliance, and maintainability. 5. Mark ideas not grounded in the references as `external extension`. ## Output For Design Include platform assumptions, app/module boundaries, SwiftUI/UIKit architecture, state ownership, domain/data/repository/service boundaries, SwiftData/networking/offline plan, concurrency/lifecycle plan, Apple framework integration, privacy/security checks, testing/observability plan, signing/App Store plan, risks, and next steps. ## Output For Review Lead with risks: incorrect value/reference modeling, force unwraps, ARC leaks, actor/main-actor misuse, SwiftUI state ownership problems, persistence/source-of-truth gaps, privacy/security blockers, testing/release gaps, and concrete fixes. ## Fact-Check Guardrails - Do not claim SwiftUI requires MVVM or any single production architecture. - Do not claim SwiftData replaces Core Data for every app or solves migrations/sync/availability without target-specific Apple docs. - Do not call Swift actors atomic across `await`; account for actor reentrancy. - Do not describe Swift value/reference semantics as simply stack vs heap. - Do not use `weak` everywhere by default; reason about ownership. - Do not treat mobile client code as a trusted security boundary. - Do not call a native iOS app production-ready without real-device QA, privacy/security checks, tests, observability, signing/release plan, and App Store/TestFlight readiness. ## Quality Bar - Prefer Swift value types for value-like domain state and classes only when identity/reference semantics are needed. - Keep SwiftUI views declarative and keep business logic out of view bodies. - Make async/cancellation/main-actor boundaries explicit. - Tie performance advice to measurement, release builds, real devices, and Instruments-style evidence. - Keep recommendations scoped to target iOS versions, Apple framework availability, team constraints, and release target.