iOS Developer Partner

An agent for native iOS app development with Swift and SwiftUI, covering declarative UI design, Combine reactive framework, Core Data persistence, URLSession networking, and iOS Human Interface Guidelines compliance.

When to Use This Agent

Choose iOS Developer Partner when:

• Building native iOS apps with Swift 5.9+ and SwiftUI
• Implementing UIKit integrations within SwiftUI apps
• Setting up Core Data and CloudKit data synchronization
• Building networking layers with URLSession and async/await
• Ensuring compliance with iOS Human Interface Guidelines

Consider alternatives when:

• Building cross-platform apps (use Flutter, React Native, or .NET MAUI agents)
• Building Android-only apps (use an Android/Kotlin agent)
• Building backend services for iOS apps (use a backend development agent)

Quick Start

Copy
# .claude/agents/ios-developer-partner.yml
name: iOS Developer
model: claude-sonnet-4-20250514
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
prompt: |
  You are a senior iOS developer. Build native iOS apps with
  Swift and SwiftUI following Apple's Human Interface Guidelines.
  Use modern concurrency (async/await), SwiftUI lifecycle,
  and Combine for reactive data flow. Prioritize performance,
  accessibility, and platform conventions.

Example invocation:

Copy
claude --agent ios-developer-partner "Build a task management
  app with SwiftUI using MVVM architecture, Core Data persistence
  with CloudKit sync, and custom list animations."

Core Concepts

SwiftUI Application Architecture

App (Entry Point)
├── Scenes (WindowGroup, DocumentGroup)
│   ├── Navigation (NavigationStack, TabView)
│   │   ├── Views (composable SwiftUI views)
│   │   │   ├── View Models (@Observable classes)
│   │   │   │   ├── Services (networking, persistence)
│   │   │   │   └── Models (data types)
│   │   │   └── Subviews (reusable components)
│   │   └── Modifiers (custom view modifiers)
│   └── Environment (shared state, dependencies)
└── App Lifecycle (background tasks, deep links)

Modern Swift Patterns

Copy
// Observable macro (Swift 5.9+)
@Observable
class TaskViewModel {
    var tasks: [Task] = []
    var isLoading = false
    var errorMessage: String?

    func loadTasks() async {
        isLoading = true
        do {
            tasks = try await taskService.fetchTasks()
        } catch {
            errorMessage = error.localizedDescription
        }
        isLoading = false
    }
}

// SwiftUI View with proper state management
struct TaskListView: View {
    @State private var viewModel = TaskViewModel()

    var body: some View {
        List(viewModel.tasks) { task in
            TaskRow(task: task)
        }
        .overlay {
            if viewModel.isLoading { ProgressView() }
        }
        .task { await viewModel.loadTasks() }
    }
}

Data Flow Patterns

Pattern	Use Case	SwiftUI API
Local state	View-specific data	@State
Shared reference	Observable objects	@Observable + @State
Parent-to-child	Passing data down	Constructor injection
Environment	App-wide values	@Environment
Binding	Two-way data flow	@Binding
Preferences	Child-to-parent	.preference(key:value:)

Configuration

Parameter	Description	Default
min_ios_version	Minimum deployment target	iOS 17.0
swift_version	Swift language version	5.9+
architecture	App architecture pattern	MVVM
persistence	Data persistence framework	SwiftData
networking	Network layer approach	URLSession + async/await
ui_framework	Primary UI framework	SwiftUI
testing	Testing framework	XCTest + Swift Testing

Best Practices

1. Use the @Observable macro instead of ObservableObject for iOS 17+. The @Observable macro provides automatic observation of all stored properties without @Published wrappers. It's more efficient because SwiftUI only re-renders views that access the specific properties that changed, not all views that observe the object. This eliminates the over-rendering problem common with ObservableObject.

2. Structure navigation with NavigationStack and typed navigation paths. Use NavigationStack(path:) with a typed navigation path for programmatic navigation control. This approach supports deep linking, state restoration, and clear navigation hierarchy. Avoid nested NavigationStack instances which create confusing navigation behavior.

3. Handle all three states in async operations: loading, success, and error. Every view that triggers an async operation should show a loading indicator during the operation, display results on success, and present an actionable error on failure. Use SwiftUI's .task modifier for view lifecycle-bound async work and .overlay for loading states. Never leave users staring at a blank screen.

4. Use dependency injection for testability, not singletons. Pass services (networking, persistence, auth) through initializers or SwiftUI's environment. This makes view models testable with mock services. @Environment is excellent for injecting shared dependencies that many views need. Singletons make testing difficult and create hidden coupling between components.

5. Follow Apple's Human Interface Guidelines for platform-native feel. Use standard iOS controls (List, NavigationLink, sheets, alerts) rather than custom replicas. Support Dynamic Type for accessibility. Implement proper dark mode support. Use SF Symbols for consistent iconography. Apps that feel native earn higher App Store ratings and better user retention than apps that fight platform conventions.

Common Issues

SwiftUI views re-render too frequently, causing jank. Profile with Instruments' SwiftUI template to identify unnecessary re-renders. Common causes: using @ObservedObject when @StateObject or @State with @Observable is appropriate, computing expensive values in the view body instead of caching them, and passing entire objects as bindings when only one property is needed.

Core Data or SwiftData migrations crash on existing user data. Always test migrations with real user data structures, not just empty databases. Use lightweight migrations for simple changes (adding columns, renaming) and plan heavyweight migrations carefully for schema restructuring. Include migration in your test suite: create a database with the old schema, run the migration, verify the data.

Networking code becomes unmanageable with many API endpoints. Create a typed API client with generic request methods rather than writing separate functions for each endpoint. Define endpoints as enum cases with associated values for parameters. Use Swift's async/await instead of completion handlers for cleaner control flow. A well-structured API layer makes adding new endpoints trivial and testing straightforward.