ios-std

Purpose

Ensure consistent, testable, app store-ready iOS code. Complements stack, security, and NFR skills.

Project structure

Features/<FeatureName>/
  View.swift
  ViewModel.swift
  (feature-specific helpers)
UIComponents/              # Shared UI primitives
Services/
  Persistence/             # SwiftData/CoreData boundary
  Notifications/           # Push notification handling
  Logging/                 # os.Logger wrapper
  Config/                  # Environment/config
Infrastructure/            # Routing, composition root, cross-cutting utilities

Key conventions

SwiftUI

• •Views are small and composable; extract subviews when files grow
• •State ownership: @StateObject for owned, @ObservedObject for injected
• •No side effects in body; use task, onAppear, or explicit actions

MVVM

• •View models: @MainActor, expose state via @Published, intents as methods (load(), didTapSave())
• •Services injected via initializers
• •View models never touch SwiftData/CoreData directly—use persistence boundary

Persistence (offline-first)

• •Single boundary: PersistenceStore protocol with SwiftDataStore implementation
• •Schema changes require migration note
• •User-generated content needs retention/cleanup strategy

Notifications

• •Isolated handling: permission flow, token registration, payload routing
• •Treat all payload values as untrusted input

Concurrency

• •Mark view models @MainActor when they own UI state
• •Handle cancellation explicitly in long-running operations

Logging

• •Use os.Logger
• •Log events, not payloads; never log PII or tokens

Naming

• •Types/files: PascalCase
• •Functions/vars: camelCase
• •One primary type per file
• •Feature folders: PascalCase

Testing requirements

Framework: Swift Testing (import Testing, @Test, #expect). Do not use XCTest for unit tests.

TDD is mandatory — see /shared-tdd for the red-green-refactor workflow and evidence requirements.

Test command: xcodebuild test or run via Xcode.

What to test

• •Unit tests: view model logic, persistence store (in-memory double), notification routing
• •UI tests: primary happy path, notification-to-screen flow when relevant
• •Use @Test(arguments:) for parameterized tests instead of loops

Test file conventions

Test pattern: @Test func methodName_condition_expected() (no test_ prefix)

Output

For significant code changes, briefly note:

• •Any deviation from these standards and why

Reference

For detailed patterns and examples, see reference/ios-std-reference.md