swiftpm-modularizationlisted

# SwiftPM Modularization ## When to invoke - Starting a new Swift App project and deciding how to split modules. - Writing the first version of `Package.swift`. - Wanting to reserve the option of shipping core logic to Android / cross-platform later. - Introducing CloudKit / GameKit / StoreKit and deciding the import scope. - User asks "single Package or multiple", "should the App target be thin", "how do I wire DI". ## Default decisions ### Single Package + multiple targets - **Put all modules in one Swift Package**, splitting by target (named e.g. `<Project>Kit`). - Don't start with multiple Packages — they only add `Package.swift` maintenance cost and CI resolution time. ### Very thin App target - The App target only contains: - `@main`, the `App` struct - `Info.plist`, entitlements - Assets / Asset Catalog - A single DI composition root (wiring protocols to concrete implementations) - All views, logic, and Storage live in the Package. - The App target has no unit tests — keep it free of logic so nothing there needs one; end-to-end launch tests live in `host-driven-xcuitest-e2e`. All testable logic is in the Package. ### Dependencies flow upward, never downward ``` Engine (pure Swift core) ↑ GameState / Domain ↑ Service modules (CloudKit / GameKit / Storage / Telemetry) ↑ UI module (SwiftUI) ↑ App target ``` ### Restricted Apple framework imports - `CloudKit` is imported only in its designated service target. - Same for `GameKit` / `StoreKit`