Expert iOS development skill covering SwiftUI, UIKit, Core Data, App Store guidelines, and performance optimization. Use this skill when building, reviewing, or debugging iOS apps - views, navigation, data persistence, animations, or submission preparation. Triggers on SwiftUI layout and state management, UIKit view controller lifecycle, Core Data model design and migrations, App Store Review Guidelines compliance, memory and rendering performance profiling, and Swift concurrency patterns for iOS.
Expert iOS development skill covering SwiftUI, UIKit, Core Data, App Store guidelines, and performance optimization. Use this skill when building, reviewing, or debugging iOS apps - views, navigation, data persistence, animations, or submission preparation. Triggers on SwiftUI layout and state management, UIKit view controller lifecycle, Core Data model design and migrations, App Store Review Guidelines compliance, memory and rendering performance profiling, and Swift concurrency patterns for iOS.
When this skill is activated, always start your first response with the 🧢 emoji.
iOS Swift Development
A senior iOS engineering skill that encodes deep expertise in building production-quality
iOS applications with Swift. It covers the full iOS development spectrum - from SwiftUI
declarative interfaces and UIKit imperative patterns to Core Data persistence, App Store
submission compliance, and runtime performance optimization. The skill prioritizes modern
Swift idioms (async/await, structured concurrency, property wrappers) while maintaining
practical UIKit knowledge for legacy and hybrid codebases. Apple's platform is the
foundation - lean on system frameworks before reaching for third-party dependencies.
When to use this skill
Trigger this skill when the user:
Asks to build, review, or debug SwiftUI views, modifiers, or navigation
Needs help with UIKit view controllers, Auto Layout, or table/collection views
Wants to design or query a Core Data model, handle migrations, or debug persistence
Asks about App Store Review Guidelines, metadata, or submission requirements
Needs to profile and fix memory leaks, rendering hitches, or energy usage
Is working with Swift concurrency (async/await, actors, TaskGroups) in an iOS context
Wants to implement animations, gestures, or custom drawing on iOS
Asks about integrating SwiftUI and UIKit in the same project
Do NOT trigger this skill for:
General Swift language questions with no iOS/Apple platform context
macOS-only, watchOS-only, or server-side Swift development
Key principles
Declarative first, imperative when necessary - Use SwiftUI for new screens and features. Fall back to UIKit only when SwiftUI lacks the capability (complex collection layouts, certain UIKit-only APIs) or when integrating into a legacy codebase. Mix via UIHostingController and UIViewRepresentable when needed.
The system is your design library - Use SF Symbols, system fonts (.body, .title), standard colors (.primary, .secondary), and built-in controls before custom implementations. System components get Dark Mode, Dynamic Type, and accessibility for free.
State drives the UI, not the other way around - In SwiftUI, the view is a function of state. Pick the right property wrapper (@State, @Binding, @StateObject, , ) based on ownership and scope. In UIKit, keep view controllers thin by moving state logic into separate models.
@EnvironmentObject
@Observable
Measure with Instruments, not intuition - Use Xcode Instruments (Time Profiler, Allocations, Core Animation, Energy Log) before optimizing. Profile on real devices - Simulator performance is not representative. An unmeasured optimization is just added complexity.
Design for App Review from day one - Follow Apple's Human Interface Guidelines and App Store Review Guidelines throughout development, not as a last-minute checklist. Rejections cost weeks. Privacy declarations (App Tracking Transparency, purpose strings), in-app purchase rules, and content policies should be architecture decisions, not afterthoughts.
Core concepts
iOS development centers on four pillars: UI frameworks (SwiftUI and UIKit), data persistence (Core Data, SwiftData, UserDefaults), system integration (notifications, background tasks, permissions), and distribution (App Store submission, TestFlight, signing).
SwiftUI is Apple's declarative UI framework. Views are value types (structs) that declare what the UI looks like for a given state. The framework diffs the view tree and applies minimal updates. State management flows through property wrappers: @State for local, @Binding for child references, @StateObject/@ObservedObject for reference-type models, and @Environment for system-provided values. With the Observation framework (@Observable), SwiftUI tracks property access at the view level for fine-grained updates.
UIKit is the imperative predecessor - view controllers manage view lifecycles (viewDidLoad, viewWillAppear, viewDidLayoutSubviews), and Auto Layout constrains positions. UIKit remains essential for UICollectionViewCompositionalLayout, advanced text editing, and existing large codebases.
Core Data is Apple's object graph and persistence framework. It manages an in-memory object graph backed by SQLite (or other stores). The stack consists of NSPersistentContainer -> NSManagedObjectContext -> NSManagedObject. Contexts are not thread-safe - use perform {} blocks and separate contexts for background work.
App Store distribution requires provisioning profiles, code signing, metadata (screenshots, descriptions, privacy labels), and compliance with App Store Review Guidelines. TestFlight enables beta testing with up to 10,000 external testers.
Common tasks
1. Build a SwiftUI list with navigation
Create a list that navigates to a detail view. Use NavigationStack (iOS 16+) for type-safe, value-based navigation.
Avoid the deprecated NavigationView and NavigationLink(destination:) patterns in new code. NavigationStack supports programmatic navigation and deep linking.
2. Set up a Core Data stack with background saving
Initialize NSPersistentContainer and perform writes on a background context to keep the main thread responsive.
Use .task {} in SwiftUI - it runs when the view appears, cancels when it disappears, and restarts if the view identity changes. Never use Task {} inside onAppear without manual cancellation.
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Force unwrapping optionals
Crashes at runtime with no recovery path
Use guard let, if let, or nil-coalescing ??
Writing to Core Data on the main context
Blocks the main thread during saves, causes UI hitches
Use newBackgroundContext() with perform {}
Massive view controllers
UIKit VCs with 1000+ lines become unmaintainable
Extract logic into view models, coordinators, or child VCs
Strong self in escaping closures
Creates retain cycles and memory leaks
Use [weak self] in escaping closures, [unowned self] only when lifetime is guaranteed
Ignoring the main actor
Updating UI from background threads causes undefined behavior
Use @MainActor annotation or MainActor.run {} for UI updates
Hardcoded strings and colors
Breaks localization and Dark Mode
Use LocalizedStringKey, asset catalog colors, and semantic system colors
Skipping LazyVStack for long lists
Eager VStack in ScrollView instantiates all views at once
Use LazyVStack or List for scrollable content with many items
Storing images in Core Data
Bloats the SQLite store, slows fetches
Store image data on disk, keep file paths in Core Data; use allowsExternalBinaryDataStorage for large blobs
Testing on Simulator only
Simulator does not reflect real device performance, memory, or thermal behavior
Always profile and test on physical devices before submission
Skipping privacy purpose strings
Automatic App Store rejection
Add NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, etc. for every permission
Gotchas
@StateObject vs @ObservedObject on the wrong owner causes views to reset - Using @ObservedObject to create a view model (instead of injecting one) means SwiftUI may recreate the object every time the parent view re-renders, destroying all state. Use @StateObject when the view owns the object's lifecycle; use @ObservedObject only when the object is injected from outside.
Core Data NSManagedObjectContext is not thread-safe and crashes are non-obvious - Accessing a managed object or its context from any thread other than the one it was created on causes data corruption or crashes that appear intermittent. Always use context.perform {} for background context work, and never pass NSManagedObject instances across threads - pass object IDs instead.
App Store rejection for missing purpose strings is instant and takes days to resolve - If your app accesses camera, photos, location, microphone, contacts, or any other private data without a corresponding NS*UsageDescription key in Info.plist, Apple rejects the binary automatically within hours of submission. Audit Info.plist against your permission calls before every submission, not just the first one.
NavigationView is deprecated but mixing it with NavigationStack breaks navigation state - In Xcode projects with mixed iOS version support, using NavigationView on older iOS alongside NavigationStack on iOS 16+ causes navigation state corruption. Pick one per navigation hierarchy - use NavigationStack with availability checks for older OS rather than mixing both.
Storing large blobs in Core Data's SQLite store bloats the database and slows all fetches - SQLite stores all column data in the same file. Even one row with a 5MB image makes every fetch of that entity slow because SQLite reads past the image data. Store binary assets on disk via FileManager, keep only the file path in Core Data, and use allowsExternalBinaryDataStorage for smaller blobs that Apple should manage externally.
References
For detailed guidance on specific iOS topics, load the relevant reference file:
references/swiftui-patterns.md - Navigation patterns, state management deep dive, custom modifiers, animations, and accessibility in SwiftUI
references/uikit-patterns.md - View controller lifecycle, Auto Layout best practices, collection view compositional layouts, and coordinator pattern
references/core-data-guide.md - Model design, relationships, fetch request optimization, migrations, and CloudKit sync
references/app-store-guidelines.md - Review Guidelines checklist, common rejection reasons, privacy requirements, and in-app purchase rules
references/performance-tuning.md - Instruments workflows, memory profiling, rendering optimization, energy efficiency, and launch time reduction
Only load a reference file when the current task requires that depth - they are detailed and will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
