HPGDesignKit

Purpose

Created a shared design kit via SPM for Hot Potato Games — reusable UI components, colors, typography, and styling constants. The theory: every HPG app shares the same visual language, so the design system should be a package. The practice: there is still only one HPG app, and the design system lives in that app just fine.

Stack

What I Learned

• Five HPG CocoaPods (Crypto, Models, Repositories, Moderation, Design) for a single app is the definitive case study in premature package extraction. Each package individually makes sense in isolation. Together, they create a dependency graph that a solo developer has to maintain, version, and update across five repos when a single feature changes.
• Design system packages make sense when: the system is stable (not changing weekly), multiple apps consume it (not one), and the team is large enough that consistency cannot be maintained through convention alone. HPGDesignKit met none of these criteria.
• The optimistic impulse — "I am going to use this all the time" — is the same impulse that drives over-engineering throughout this blog. The 22 microservices for idea capture. The 5 CocoaPods for one game. The Note Timer spec with 15 features. The pattern: imagining the future you instead of building for the current you.

Key Insights

• The entire HPG SDK family (5 packages) could be a single Swift Package with 5 modules. One repo, one version, one import. The modularity is preserved (import HPGKit.Models, import HPGKit.Design) without the multi-repo overhead. This is the architecture that should have been chosen from the start — and will likely be the architecture it migrates to.