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
UIHostingControllerandUIViewRepresentablewhen 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,@EnvironmentObject,@Observable) based on ownership and scope. In UIKit, keep view controllers thin by moving state logic into separate models. -
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.
struct ItemListView: View {
@State private var items: [Item] = Item.samples
@State private var path = NavigationPath()
var body: some View {
NavigationStack(path: $path) {
List(items) { item in
NavigationLink(value: item) {
ItemRow(item: item)
}
}
.navigationTitle("Items")
.navigationDestination(for: Item.self) { item in
ItemDetailView(item: item)
}
}
}
}
Avoid the deprecated
NavigationViewandNavigationLink(destination:)patterns in new code.NavigationStacksupports 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.
class PersistenceController {
static let shared = PersistenceController()
let container: NSPersistentContainer
init() {
container = NSPersistentContainer(name: "Model")
container.loadPersistentStores { _, error in
if let error { fatalError("Core Data load failed: \(error)") }
}
container.viewContext.automaticallyMergesChangesFromParent = true
}
func save(block: @escaping (NSManagedObjectContext) -> Void) {
let context = container.newBackgroundContext()
context.perform {
block(context)
if context.hasChanges {
try? context.save()
}
}
}
}
Never perform writes on
viewContextfor large operations - it blocks the main thread. Always usenewBackgroundContext()orperformBackgroundTask.
3. Bridge SwiftUI and UIKit
Wrap a UIKit view for use in SwiftUI with UIViewRepresentable, or host SwiftUI inside UIKit with UIHostingController.
// UIKit view in SwiftUI
struct MapViewWrapper: UIViewRepresentable {
@Binding var region: MKCoordinateRegion
func makeUIView(context: Context) -> MKMapView {
let mapView = MKMapView()
mapView.delegate = context.coordinator
return mapView
}
func updateUIView(_ mapView: MKMapView, context: Context) {
mapView.setRegion(region, animated: true)
}
func makeCoordinator() -> Coordinator { Coordinator(self) }
class Coordinator: NSObject, MKMapViewDelegate {
var parent: MapViewWrapper
init(_ parent: MapViewWrapper) { self.parent = parent }
}
}
// SwiftUI view in UIKit
let hostingController = UIHostingController(rootView: MySwiftUIView())
navigationController?.pushViewController(hostingController, animated: true)
4. Profile and fix memory leaks
Use Instruments Allocations and Leaks to find retain cycles. The most common iOS memory leak is a strong reference cycle in closures.
Checklist:
- Run the Leaks instrument on a real device while exercising the suspecte