HPGRepositoriesKit

Purpose

HPGRepositoriesKit handled the networking layer: API calls to the HPG backend, using the types from HPGModelsKit, with crypto operations from HPGCryptoKit. Three packages composing into a layered SDK. For a mature platform with multiple consumers, this is clean. For one app, it was three times the maintenance for the same output.

Stack

What I Learned

• The HPG SDK trilogy (CryptoKit → ModelsKit → RepositoriesKit) is a textbook clean architecture: crypto handles security primitives, models define the data contracts, repositories handle network calls using both. Each layer depends on the one below it. On paper, it is elegant. In practice, changing a single API field meant updating ModelsKit (the type), RepositoriesKit (the call), and the app (the UI) — three repos, three version bumps, three pod installs.
• The "ornery" feeling is the dependency cascade problem: when packages depend on each other, a change in any package ripples through the chain. In a team of 20, the cascade is managed by CI/CD and semantic versioning. For a solo developer, it is you rebuilding three packages because a backend field was renamed from "user_id" to "userId."
• The rule of thumb: extract a package when the extraction reduces complexity. If the code in the package would be simpler living in the app, the package is premature. HPGRepositoriesKit would have been simpler as a /Networking folder in the app. The extraction added structure but also added overhead that exceeded the structure's value at this scale.

Key Insights

• Three packages for one project is the SDK-architecture equivalent of 22 microservices for an idea capture app. The impulse is the same: impose elegant structure before the scale demands it. The lesson is the same: match the architecture to the current reality, not the aspirational future. When HPG has 5 iOS apps, the SDK trilogy will be justified. Until then, a single shared framework (or even just shared source files) is the right call.