Implementing Ios Code

Data Models (if needed)

• Request/Response types in Core/<Domain>/Models/Request/ and Response/
• Enum types in Core/<Domain>/Models/Enum/

Persistence (if needed)

• Vault sync data → CoreData via DataStore (add entities to Bitwarden.xcdatamodeld)
• Non-sensitive settings → AppSettingsStore (backed by UserDefaults)
• Credentials/keys → KeychainRepository
• All three are exposed through StateService. Prefer adding a separate protocol over extending StateService, AppSettingsStore, or KeychainRepository directly, to maintain interface segregation.

Services / Repositories

• Define protocol with // sourcery: AutoMockable
• Implement Default<Name>Service / Default<Name>Repository
• Add Has<Name> protocol
• See templates.md for service skeleton

Step 3: UI Layer (File-Set Pattern)

For new screens, create all required files together (see templates.md):

1. Route — Add case to the parent Coordinator's route enum
2. Coordinator — Navigation logic, screen instantiation, Services typealias
3. State — Value type (struct) holding all view-observable data
4. Action — Enum of user interactions handled synchronously in receive(_:)
5. Effect — Enum of async work handled in perform(_:)
6. Processor — StateProcessor subclass, business logic only
7. View — SwiftUI view using store.binding, store.perform, @ObservedObject

Step 4: Wire Dependency Injection

After creating a new service/repository:

• Add Has<Name> conformance to ServiceContainer via extension
• Add Has<Name> to the Services typealias of any processor that needs it

Step 5: Security Check

Before finishing:

• Vault data? → Must use BitwardenSdk for all encryption/decryption
• Storing credentials? → Must use KeychainRepository, not AppSettingsStore
• User input? → Must validate via InputValidator
• Surfacing errors? → Sensitive errors must implement NonLoggableError
• Running in an extension? → Check Argon2id memory if KDF is involved

Step 6: Documentation

All new public types and methods require DocC (///) documentation. Exceptions: protocol property/function implementations (docs live in the protocol), mock classes. Use pragma marks to organize code. // MARK: - is used to denote different objects in the same file; // MARK: is used to denote different sections within an object.