Spec — iOS SwiftUI bindings catalog

Facet Develop of Koder Design. Material parity: https://m3.material.io/develop/ios.

Surface: native iOS SwiftUI. Catalog page: https://kds.koder.dev/{locale}/develop/ios-swiftui/.

Why a native SwiftUI surface

For apps targeting iOS only (or iOS + macOS) where a Flutter dependency is undesired — smaller binary, faster cold start, full access to Apple-specific APIs (SwiftData, App Intents, etc.).

Koder Design SwiftUI is feature-parity with the canonical specs. Switching the preset to ios_cupertino makes the SwiftUI surface look native-iOS — but the API is the SAME regardless of preset, only the rendering changes.

Package distribution

Distributed via Swift Package Manager only (no CocoaPods support for v1).

R1 — Catalog page contents

Per component: View signature, Theme tokens consumed, Variant matrix, Code sample, Per-state Previews, Accessibility modifiers, Cross-link to canonical spec. Same shape as android-compose.kmd § R1.

R2 — KoderDesignTheme environment

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .koderDesignTheme(
                    preset: .material3,
                    colorScheme: .system,
                    seedColor: nil,
                    density: .default
                )
        }
    }
}

Internally:

• Injects @Environment(\.koderColorScheme), @Environment(\.koderTypography), etc.
• Provides preset switching at runtime (re-renders dependent views)
• Bridges to ColorScheme for .preferredColorScheme compatibility

R3 — View naming

Pattern: Koder<View> for views; .koder<Modifier> for view modifiers (e.g., .koderSnackbar, .koderDialog).

R4 — Density

KoderDensity.compact / .default / .comfortable propagates via environment. Each view reads it and adjusts.

R5 — Per-preset adaptation

Same view renders differently per preset:

• material3 → Material 3 visual
• ios_cupertino → Native iOS-style
• material2, gnome, etc. → respective preset visuals

For iOS-only apps, default preset is ios_cupertino; for cross-platform apps targeting unified Koder visual, default is material3. Owner sets via koderDesignTheme(preset:).

R6 — Accessibility

• Views integrate with VoiceOver (accessibilityLabel, role mapping)
• Internal semantics conform to canonical specs (e.g., KoderCheckbox uses .accessibilityAddTraits(.isButton) + .isToggled state)
• Dynamic Type respected through token-based font sizes (scales with user preference)
• Reduce Motion preference honored

R7 — Versioning

Same as Compose surface — Koder Design semver via SPM tags: engines/sdk/koder-design-swift/v*.

R8 — Out of scope

• ❌ UIKit bindings (SwiftUI-only)
• ❌ ObjC API exposure (Swift-only)
• ❌ tvOS / watchOS variants in v1 (open ticket if demand)
• ❌ macOS-specific views (SwiftUI views inherit macOS support via multi-target SPM module; no separate AppKit bindings)

R9 — Forbidden patterns

• ❌ View that bypasses KoderDesignTheme environment
• ❌ Hardcoded Color(red:green:blue:) in views (use tokens)
• ❌ View that ships strings (use LocalizedStringKey per i18n/contract.kmd)
• ❌ View that doesn't compose properly inside ScrollView / List (must be primitives, not container-only)

Cross-link

• themes/*.kmd — token sources
• components/*.kmd — per-component anatomy
• i18n/contract.kmd — LocalizedStringKey usage
• tools/design-kit-export.kmd — Swift tokens exported here

Implementation tracking

• engines/sdk/koder-design-swift/ — SPM repo
• Multi-day impl tracked via separate tickets