planning-ios-implementation

# Planning iOS Implementation Use this skill to design a complete implementation plan before writing code. Output is saved as a design document. ## Prerequisites - Requirements must be clear. If not, invoke `refining-ios-requirements` first. - Read `Docs/Architecture.md` before proceeding — it is the authoritative source for all patterns. ## Step 1: Classify the Change Determine the change type to guide scope and planning depth: | Type | Description | Typical Scope | |------|-------------|---------------| | **New Feature** | Entirely new functionality, screens, or flows | New files + modifications, multi-phase | | **Enhancement** | Extending existing feature with new capabilities | Mostly modifications, 1-2 phases | | **Bug Fix** | Correcting incorrect behavior | Targeted modifications, single phase | | **Refactoring** | Restructuring without behavior change | Modifications only, migration-aware | | **Infrastructure** | Build, CI, tooling, or dependency changes | Config files, minimal code changes | State the classification and rationale before proceeding. ## Step 2: Explore Existing Patterns Search the codebase for similar existing implementations to follow: - Find a similar existing feature in the same domain - Identify which services/repositories it uses - Note how its Coordinator, Processor, and View are structured - Check if `BitwardenKit/UI/` has reusable components for the new UI ## Step 3: List Files to Create/Modify For each file, specify path, action (create/modify), domain placement, and purpose. Group by layer: ``` ### New Files (Create) #### Core Layer - `BitwardenShared/Core/<Domain>/<Feature>/Services/<Feature>Service.swift` - Protocol + Default<Feature>Service + Has<Feature>Service #### UI Layer - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Coordinator.swift` - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Processor.swift` - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>State.swift` - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Action.swift` - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>Effect.swift` - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>View.swift` #### Tests (co-located with implementation) - `BitwardenShared/UI/<Domain>/<Feature>/<Feature>ProcessorTests.swift` - `BitwardenShared/Core/<Domain>/<Feature>/Services/<Feature>ServiceTests.swift` ### Modified Files - `BitwardenShared/Core/Platform/Services/ServiceContainer.swift` — Add new service - `<Existing>Coordinator.swift` — Add new route ``` ## Step 4: Dependency-Ordered Implementation Phases Order phases so each builds on the previous: ``` ### Phase 1: Data / Core Layer Models, CoreData entities (if needed), service protocols, repository protocols ### Phase 2: Service/Repository Implementations Default<Name>Service/Repository — business logic, SDK calls, network ### Phase 3: DI Wiring ServiceContainer extensions, Has* protocol additions ### Phase 4: Processor + State StateProcessor subclass, State struct, Action enum, Effect enum ### Phase 5: View + Coordinator SwiftUI View with store.binding, Coordinator with routes, navigation wiring ### Phase 6: Tests ProcessorTests (action/effect paths), ServiceTests (business logic), ViewTests (snapshots if UI) ``` ## Step 5: Risk Assessment Identify risks and mitigations: - **Security**: Does this touch vault data, auth tokens, or Keychain? → Security review required - **Extensions**: Does this affect AutoFill/Action/Share extensions? → Memory limit check needed - **Multi-account**: Does this need per-account isolation? → CoreData userId scoping - **SDK dependency**: Does this require BitwardenSdk changes? → Coordinate with SDK team ## Step 6: Save Design Document Save the plan to `.claude/outputs/plans/<ticket-id>.md`. ## Confirm Before Proceeding Present the plan to the user and ask: "Here is the implementation plan. Should I proceed with implementation?"