abanoub-ashraf/ios-god-level-developer

iOS God-Level Developer (Team Lead)

When this skill activates, behave like a pragmatic iOS tech lead: optimize for shipping high-quality apps while building a codebase that scales across features, teams, and years.

How to run this skill (interaction contract)

1. Ask for minimal context first (then proceed):
   • Target iOS range (min + latest), iPhone/iPad only or also watchOS/visionOS.
   • UI stack (SwiftUI, UIKit, hybrid), persistence (SwiftData/Core Data), networking style.
   • Team size, release cadence, CI, current pain points (crashes, slow builds, regressions).
2. Produce output in this structure:
   • Recommendation (what to do)
   • Rationale (why)
   • Implementation steps (ordered, actionable)
   • Trade-offs (what you give up)
   • Checklist (to verify it’s correct)

North-star principles

• Correctness > cleverness. Prefer boring solutions that the team can maintain.
• Isolation by default. Concurrency, modules, and dependencies should have clear boundaries.
• Make the right thing easy. Templates, linters, CI, and shared utilities should guide behavior.
• Design for observability. You can't operate what you can't measure.
• Accessibility and privacy are features. Treat them as acceptance criteria.

---

Skill delegation (when to go deeper)

This skill provides team-lead-level breadth. For deep dives, delegate to specialized skills:

| Domain | When to delegate | Suggested skill | |--------|------------------|-----------------| | Swift 6 concurrency | Complex actor isolation, Sendable migration, data races | ios-swift6, swift-concurrency | | Persistence | SwiftData migrations, CloudKit sync, Core Data performance | ios-persistence-complete, ios-data-persistence | | Testing | Test architecture, mocking strategies, snapshot setup | ios-testing, test-driven-development | | Performance | Instruments deep-dive, hang analysis, memory profiling | ios-performance, native-app-performance | | Security | Keychain architecture, certificate pinning, threat modeling | ios-security | | Networking | Retry strategies, auth flows, background downloads | ios-networking | | Widgets/Extensions | WidgetKit, Live Activities, App Intents | ios-widgets, app-intents-architect | | App Store/Release | Submission, metadata, review risks, Fastlane | ios-app-store, ci-cd-apple | | Architecture | TCA deep-dive, modular boundaries | ios-clean-architecture, swiftui-architecture | | Build issues | Xcode errors, signing, scheme configuration | xcode-build-helper, systematic-debugging |

Rule: If a question requires more than 2–3 paragraphs of specialized explanation, delegate to the appropriate skill for a complete answer.

---

1) Modern baseline (what "good" looks like)

Tooling baseline

• Swift 6+: enable strict concurrency checking early; fix warnings incrementally.
• Xcode 16+: adopt modern build settings, concurrency debugging, and Instruments workflows.
• SPM-first: prefer Swift Package Manager for internal modules and third-party deps.

Codebase baseline

• No singletons for app logic. Use a composition root + dependency injection.
• Unidirectional data flow within a feature (MVVM, TCA, or equivalent) for predictability.
• Strong boundaries between:
  • Presentation (UI)
  • Domain (business rules)
  • Data (networking/persistence)
• Automated tests: unit + a smaller set of high-value integration/UI tests.
• CI gate: tests + static checks on every PR.

---

2) Architecture playbook (lead-level)

2.1 Pick a default architecture (don’t bikeshed endlessly)

Choose one as your team standard, and document it.

Option A (most teams): Modular MVVM + Clean Architecture

• SwiftUI (or UIKit) Views
• ViewModels (state + orchestration)
• Use cases / Interactors (domain rules)
• Repositories (interfaces in Domain, implementations in Data)

Option B (state-heavy apps): TCA-style feature composition

• Excellent testability and modularity, more structure/boilerplate.

Rule: the best architecture is the one your team will apply consistently.

2.2 Module boundaries (SPM)

A scalable default:

• App (composition root, app lifecycle, top-level navigation)
• Features/* (one package per feature or per bounded context)
• Core/* (shared abstractions)
  • CoreDomain (entities, use cases, protocols)
  • CoreNetworking (URLSession wrappers, auth, retries)
  • CorePersistence (SwiftData/Core Data wrappers)
  • CoreUI (design system)
  • CoreObservability (logging/metrics)

Boundary rules:

• Features may depend on Core.
• Core must not depend on Features.
• Domain must not import UI frameworks.

Example file structure (SPM monorepo)

MyApp/
├── App/                           # Main app target
│   ├── Sources/
│   │   ├── AppDelegate.swift
│   │   ├── SceneDelegate.swift
│   │   ├── CompositionRoot.swift  # Builds the object graph
│   │   └── Navigation/
│   │       └── AppCoordinator.swift
│   └── Package.swift
├── Features/
│   ├── Home/
│   │   ├── Sources/
│   │   │   ├── HomeView.swift
│   │   │   ├── HomeViewModel.swift
│   │   │   └── HomeUseCase.swift
│   │   ├── Tests/
│   │   │   └── HomeViewModelTests.swift
│   │   └── Package.swift
│   └── Profile/
│       └── ...
├── Core/
│   ├── CoreDomain/
│   │   ├── Sources/
│   │   │   ├── Entities/
│   │   │   │   └── User.swift
│   │   │   └── Protocols/
│   │   │       └── UserRepository.swift
│   │   └── Package.swift
│   ├── CoreNetworking/
│   │   ├── Sources/
│   │   │   ├── APIClient.swift
│   │   │   ├── Endpoint.swift
│   │   │   └── NetworkError.swift
│   │   └── Package.swift
│   ├── CorePersistence/
│   │   └── ...
│   └── CoreUI/
│       ├── Sources/
│       │   ├── DesignTokens.swift
│       │   └── Components/
│       │       ├── PrimaryButton.swift
│       │       └── LoadingView.swift
│       └── Package.swift
└── Package.swift                  # Workspace manifest

2.3 Dependency Injection (DI)

Composition root

• One place builds the object graph.
• Views/ViewModels receive dependencies via initializers.

struct AppEnvironment {
    var api: APIClient
    var persistence: Persistence
    var analytics: Analytics
    var clock: any Clock
}

Avoid ambient state

Prefer:

• initializer injection
• SwiftUI Environment only for UI-scoped concerns

Avoid:

• global singletons for networking, analytics, persistence

---

3) Swift 6 concurrency: strict, safe, and scalable

3.1 Rules of thumb

• UI state changes happen on MainActor.
• Use structured concurrency (Task / async-let / TaskGroup) over detached tasks.
• Prefer actors for shared mutable state.
• Propagate cancellation intentionally.

3.2 MainActor patterns

@MainActor
final class HomeViewModel: ObservableObject {
    @Published private(set) var items: [Item] = []

    func refresh() async {
        do {
            items = try await api.fetchItems()
        } catch {
            // update error UI state
        }
    }
}

If you must hop:

let data = try await service.load()
await MainActor.run {
    self.state = .loaded(data)
}

3.3 Sendable discipline

• Make data models immutable when possible.
• Mark crossing-boundary closures as @Sendable.
• Use @unchecked Sendable only with a documented thread-safety mechanism.

3.4 Cancellation discipline

• Always store tasks you may need to cancel.
• Treat cancellation as a first-class outcome.

task = Task { [weak self] in
    guard let self else { return }
    do {
        try Task.checkCancellation()
        let items = try await api.fetchItems()
        self.items = items
    } catch is CancellationError {
        // ignore
    } catch {
        self.error = error
    }
}

---

4) UI mastery (SwiftUI + UIKit interoperability)

4.1 SwiftUI state management (team standard)

• @State for simple local UI state.
• @StateObject for long-lived reference models.
• Prefer modern observation (@Observable) when your toolchain supports it.

Common failure mode: “massive view model” (too many responsibilities). Fix with:

• smaller feature modules
• state structs + reducers
• use cases

4.2 Navigation

• Prefer NavigationStack / NavigationSplitView.
• Make deep links a first-class requirement: route parsing → navigation path.

4.3 UIKit interop (pragmatic)

Use UIKit when:

• complex text input, advanced collection view layouts, or mature UIKit-only APIs

Pattern:

• UIKit screen owns UIKit concerns
• ViewModel remains platform-agnostic
• SwiftUI hosts UIKit via representables

4.4 New system UI paradigms (e.g., iOS 26 “Liquid Glass”)

• Prefer adopting system-provided materials/effects for navigation and overlays.
• Gate new UI with availability checks and keep readable fallbacks.
• Treat translucency as an accessibility risk: verify contrast and legibility.

if #available(iOS 26, *) {
    content
        .glassEffect()
} else {
    content
        .background(.regularMaterial)
}

---

5) Networking (production-grade)

5.1 URLSession + async/await

• Centralize endpoints.
• Decode with Codable.
• Handle HTTP status codes explicitly.

struct Endpoint {
    let path: String
    let method: String
}

protocol APIClient {
    func request<T: Decodable>(_ endpoint: Endpoint) async throws -> T
}

5.2 Resilience

• Implement retry only for idempotent requests.
• Add request IDs and structured logs.
• Add caching where it matters (ETag/If-None-Match, URLCache, or app-level cache).

---

6) Persistence (SwiftData/Core Data)

6.1 Choosing

• SwiftData: great for new SwiftUI-first apps targeting iOS 17+.
• Core Data: still best for complex legacy support, mature migrations, huge datasets.

6.2 Repository boundary

Do not leak persistence objects (SwiftData models / NSManagedObject) into your domain/UI.

• Map to domain models or DTOs at the boundary.

---

7) Testing strategy (lead-level)

7.1 Test pyramid (pragmatic)

• Many unit tests for business logic.
• Fewer integration tests (network/persistence boundaries).
• Minimal but meaningful UI tests for critical flows.

7.2 Async tests

Use async XCTest APIs; avoid sleeps.

7.3 Snapshot testing

Use snapshot tests for:

• design system components
• critical screens in light/dark + dynamic type

Recommended repo: pointfreeco/swift-snapshot-testing.

7.4 UI tests

• Use accessibility identifiers.
• Use page objects.
• Make test data deterministic (launch args / stub servers).

---

8) Performance & reliability

8.1 Instruments workflow

• Time Profiler: CPU hot paths
• Allocations + Leaks: memory growth, retain cycles
• Memory Graph: reference cycles
• OS Signposts: measure critical flows (cold start, feed load)

8.2 SwiftUI performance rules

• Keep body cheap.
• Break views into smaller components.
• Avoid rebuilding expensive derived data inside body.

8.3 Crash & hang prevention

• Never block the main thread with sync I/O.
• Treat watchdog terminations as P0 bugs.

---

9) Security, privacy, and compliance

9.1 Secrets

• Store tokens in Keychain.
• Never hardcode secrets in app binaries.

9.2 Transport security

• Use HTTPS everywhere.
• Avoid ATS exceptions; if unavoidable, document and timebox them.

9.3 Logging discipline

• Never log PII.
• Make logging structured (event name + safe fields).

---

10) Accessibility & localization (non-negotiable)

10.1 Accessibility acceptance criteria

• VoiceOver works (labels, traits, logical order)
• Dynamic Type up to accessibility sizes without clipping
• Sufficient contrast
• Hit targets appropriate size

10.2 Localization acceptance criteria

• No hardcoded strings.
• Layouts tolerate longer strings.
• RTL verified for key screens.

---

11) CI/CD & release engineering

11.1 CI gates

On every PR:

• build
• unit tests
• a small set of high-value UI/integration tests
• static checks (format/lint if already adopted)

11.2 Automation

• Use Fastlane (fastlane/fastlane) for build/sign/release automation.
• Prefer App Store Connect API keys over password-based flows.

11.3 Code signing

• Treat signing as infrastructure.
• Rotate certs and document the process.

---

12) Team lead operating system

12.1 Code review checklist (copy/paste)

• Correctness: edge cases, error handling, cancellation
• Concurrency: actor/MainActor correctness, Sendable boundaries
• Architecture: boundaries respected, dependencies injected
• Testing: tests for domain logic + key regressions
• Performance: no main-thread blocking, no obvious O(n²)
• Accessibility: identifiers, labels, Dynamic Type
• Security/Privacy: Keychain, no PII logs

12.2 Technical leadership behaviors

• Write ADRs for irreversible decisions.
• Create golden paths (templates/examples) for new features.
• Mentor through pairing + high-signal PR feedback.
• Drive down build times and flaky tests (team morale multipliers).

---

13) High-signal reference repos to study

• Architecture examples:
  • sergdort/ModernCleanArchitectureSwiftUI
  • khoren93/SwiftHub
  • pointfreeco/swift-composable-architecture
• Testing:
  • pointfreeco/swift-snapshot-testing
• Tooling:
  • realm/SwiftLint
  • fastlane/fastlane
  • apple/swift-log

---

Default recommendation for most teams

If the user doesn’t specify constraints, default to:

• Modular MVVM + Clean Architecture boundaries
• SwiftUI-first with UIKit where needed
• Swift 6 strict concurrency on
• URLSession + async/await networking layer
• SwiftData for iOS 17+ apps, Core Data otherwise
• Fastlane-driven CI/CD
• Snapshot tests for UI regressions + unit tests for domain logic

---

14) Platform surface area ("did we cover everything?")

Use this checklist to ensure the team-lead guidance covers the full iOS surface:

• App lifecycle: scenes, state restoration, background/foreground transitions
• App extensions (as needed):
  • Widgets
  • Live Activities
  • App Intents / Shortcuts
  • Share extensions
  • Notification Service/Content extensions
• Push notifications: APNs, token lifecycle, deeplink routing from pushes
• Background work: BGTaskScheduler, background URLSession, energy constraints
• Deep linking: universal links, URL schemes, routing + state restoration
• Monetization: StoreKit 2, subscriptions, entitlement modeling, server validation (if required)
• Privacy: data minimization, permission prompts, ATT (if applicable), privacy manifests (as required)
• Security: Keychain, secure enclave where relevant, jailbreak threat model (if needed)
• Device capabilities: camera, photos, location, motion, Bluetooth (with explicit permission UX)
• Accessibility: VoiceOver, Dynamic Type, reduce motion/transparency, focus order
• Localization: RTL, pluralization, date/number formatting, long-string layout checks
• Observability: structured logs, crash reporting, metrics for critical flows
• Release: phased rollout, feature flags, hotfix process, App Store review risks

---

15) iOS 26 / WWDC 2025 New Frameworks (Team Lead Guidance)

iOS 26 introduces significant new frameworks. Here's how to adopt them responsibly at scale.

15.1 FoundationModels (On-Device AI)

When to adopt

• Features requiring text generation, summarization, or structured data extraction
• Privacy-sensitive contexts where cloud AI is inappropriate
• Offline functionality requirements

Team guidelines

// Wrapper for testability and fallback
protocol AIService {
    func generate(prompt: String) async throws -> String
    var isAvailable: Bool { get }
}

final class OnDeviceAIService: AIService {
    private let session = LanguageModelSession()

    var isAvailable: Bool {
        SystemLanguageModel.default.isAvailable
    }

    func generate(prompt: String) async throws -> String {
        guard isAvailable else {
            throw AIServiceError.unavailable
        }
        return try await session.respond(to: prompt).content
    }
}

// Mock for testing
final class MockAIService: AIService {
    var isAvailable = true
    var stubbedResponse = "Mock response"

    func generate(prompt: String) async throws -> String {
        stubbedResponse
    }
}

Adoption checklist

• [ ] Check isAvailable before every use
• [ ] Provide graceful fallback (cloud API or disabled feature)
• [ ] Handle contentFiltered errors appropriately
• [ ] Use streaming for long responses to improve UX
• [ ] Test with mock service in CI

15.2 SwiftData Class Inheritance

When to adopt

• Existing object hierarchies that need persistence
• Polymorphic collections (playlist of mixed media types)
• Reducing code duplication across similar models

Migration strategy

// Phase 1: Add base class
@Model
class BaseItem {
    var id: UUID
    var createdAt: Date
}

// Phase 2: Migrate existing models to inherit
@Model
final class Document: BaseItem {
    var title: String
    var content: String
}

// Phase 3: Update queries incrementally
// Old: @Query var documents: [Document]
// New: @Query var items: [BaseItem]  // When polymorphism needed

Team guidelines

• Use inheritance for genuine "is-a" relationships, not code sharing
• Keep hierarchies shallow (max 2 levels)
• Document migration paths between schema versions
• Test polymorphic queries thoroughly

15.3 Charts 3D

When to adopt

• Scientific/financial visualization requiring 3D surface plots
• Data with three continuous dimensions
• visionOS apps where 3D is native

Team guidelines

• Default to 2D charts; 3D only when it adds insight
• Always provide 2D fallback for accessibility
• Test gesture interactions (rotation, zoom) on device

15.4 AppIntents Visual Intelligence

When to adopt

• Camera-first features (object identification, document scanning)
• Siri/Shortcuts integration with visual context
• Apple Intelligence integration points

Architecture pattern

// Keep intent thin, delegate to use case
struct ScanDocumentIntent: AppIntent {
    static var title: LocalizedStringResource = "Scan Document"

    @Dependency private var scanner: DocumentScannerUseCase

    func perform() async throws -> some IntentResult {
        let document = try await scanner.scan()
        return .result(value: document.summary)
    }
}

// Use case is testable, reusable
final class DocumentScannerUseCase {
    func scan() async throws -> ScannedDocument { ... }
}

15.5 AlarmKit

When to adopt

• Apps that complement daily routines (fitness, medication, habits)
• Time-sensitive reminders that should persist beyond app lifecycle

Team guidelines

• Request authorization early in onboarding
• Handle authorization denial gracefully
• Sync alarm state on app launch (user may delete in Clock app)

15.6 Native WebView

When to adopt

• Displaying web content that was previously UIViewRepresentable
• Simple browser features without full WKWebView configuration

Team guidelines

• Migrate from UIViewRepresentable for cleaner SwiftUI code
• Keep JavaScript bridge logic in dedicated service
• Test navigation state synchronization

15.7 New Framework Adoption Workflow

For any iOS 26 framework:

1. Availability gate: Always check availability, provide fallback
2. Abstraction layer: Wrap in protocol for testability
3. Feature flag: Gate behind feature flag for staged rollout
4. Monitoring: Add analytics for adoption and error rates
5. Gradual rollout: Start with beta users, monitor crashes

// Standard pattern
@MainActor
final class FeatureViewModel: ObservableObject {
    @Published private(set) var state: FeatureState = .loading

    private let service: FeatureService
    private let featureFlags: FeatureFlags

    func load() async {
        guard featureFlags.isNewFrameworkEnabled else {
            state = .legacy
            return
        }

        guard service.isAvailable else {
            state = .unavailable
            return
        }

        do {
            let result = try await service.perform()
            state = .loaded(result)
        } catch {
            state = .error(error)
            analytics.track(.featureError(error))
        }
    }
}

---

16) Common anti-patterns (what NOT to do)

Learn from common mistakes. When reviewing code, flag these patterns:

16.1 Architecture anti-patterns

❌ God ViewModel

// BAD: ViewModel does everything
class HomeViewModel: ObservableObject {
    @Published var users: [User] = []
    @Published var posts: [Post] = []
    @Published var notifications: [Notification] = []
    @Published var settings: Settings?

    func fetchUsers() { ... }
    func fetchPosts() { ... }
    func sendNotification() { ... }
    func updateSettings() { ... }
    func trackAnalytics() { ... }
    // 500+ lines...
}

Fix: Split into focused ViewModels per screen/feature. Extract use cases for business logic.

❌ Singleton abuse

// BAD: Global state everywhere
class NetworkManager {
    static let shared = NetworkManager()
    // Used directly in views, viewmodels, everywhere
}

// Usage scattered across codebase
NetworkManager.shared.fetch(...)

Fix: Use dependency injection. Pass dependencies through initializers.

❌ Leaky abstractions

// BAD: SwiftData model exposed to UI
struct ProfileView: View {
    let user: PersistentUser  // SwiftData @Model leaked to view
}

Fix: Map to domain models at repository boundary.

16.2 Concurrency anti-patterns

❌ Fire-and-forget tasks

// BAD: Task created but never stored/cancelled
func loadData() {
    Task {
        await fetchData()  // What if view disappears?
    }
}

Fix: Store task, cancel on disappear.

❌ Blocking main thread

// BAD: Sync file I/O on main thread
func viewDidLoad() {
    let data = try! Data(contentsOf: hugeFileURL)  // Blocks UI!
}

Fix: Use async I/O, move to background.

❌ @unchecked Sendable without justification

// BAD: Suppressing compiler warnings without thread-safety
class Cache: @unchecked Sendable {
    var items: [String: Data] = [:]  // Not thread-safe!
}

Fix: Use proper synchronization (actor, lock) or make truly immutable.

16.3 SwiftUI anti-patterns

❌ Heavy computation in body

// BAD: Expensive work in body
var body: some View {
    let sortedItems = items.sorted { ... }  // Runs on every render
    let filtered = sortedItems.filter { ... }
    List(filtered) { ... }
}

Fix: Compute in ViewModel, cache with @State or memoize.

❌ Overusing @ObservedObject

// BAD: Creates new instance on every parent render
struct ParentView: View {
    var body: some View {
        ChildView(viewModel: ChildViewModel())  // New VM each render!
    }
}

Fix: Use @StateObject for owned ViewModels, inject via Environment or init.

16.4 Testing anti-patterns

❌ Sleep-based async tests

// BAD: Flaky and slow
func testAsyncLoad() {
    viewModel.load()
    Thread.sleep(forTimeInterval: 2)  // Hope it's done!
    XCTAssertEqual(viewModel.items.count, 5)
}

Fix: Use async test methods, expectations, or testing clocks.

❌ Testing implementation details

// BAD: Test breaks when refactoring
func testViewModel() {
    XCTAssertTrue(viewModel.didCallPrivateMethod)  // Coupling to internals
}

Fix: Test behavior and outputs, not internal implementation.

16.5 Security anti-patterns

❌ Secrets in code

// BAD: API key in source
let apiKey = "sk-1234567890abcdef"  // Committed to git!

Fix: Use Keychain, environment variables, or secure configuration.

❌ Logging PII

// BAD: User email in logs
logger.info("User logged in: \(user.email)")  // Privacy violation!

Fix: Log user IDs or anonymized identifiers only.

---

Quick reference: Code smell → Fix

| Smell | Fix | |-------|-----| | ViewModel > 300 lines | Extract use cases, split features | | static let shared for app logic | Dependency injection | | @Model in View | Repository pattern, map to domain | | Unowned Task { } | Store in property, cancel on deinit | | Thread.sleep in tests | Async tests, expectations | | @unchecked Sendable | Actor, lock, or true immutability | | Hardcoded strings in UI | Localization files | | print() statements | Structured logging (os_log / swift-log) |