HPGModelsKit

Purpose

Created a shared data models package for the Hot Potato Games iOS apps — typed Swift structs and Codable conformances for every backend API response. The idea: any HPG app imports HPGModelsKit and gets type-safe access to user profiles, game sessions, leaderboards, and whatever else the backend serves.

Stack

What I Learned

• Shared model packages make sense when: multiple apps consume the same backend, the API surface is stable, and type mismatches between apps would cause real bugs. They are premature when: you have one app, the API is still changing weekly, and the "shared" package is shared with nobody.
• Swift's Codable protocol makes JSON ↔ struct serialization trivial: define a struct with the right property names and types, conform to Codable, and JSONDecoder handles the rest. A models package is essentially a collection of these structs with any custom decoding logic (date formats, nested objects, enum mapping). The package is simple. The value is consistency.
• HPGModelsKit + HPGCryptoKit together represent the beginning of a layered SDK: models for data, crypto for security, and presumably networking, storage, and UI layers would follow. This is how companies like Stripe and Firebase structure their client SDKs — small, composable packages that apps import as needed. For HPG at current scale, it was premature. For HPG at target scale, it is correct.

Key Insights

• Building SDK infrastructure before you have multiple consumers is a form of optimistic architecture — betting that the future will need what you are building today. Sometimes the bet pays off (the SDK is ready when the second app ships). Sometimes it does not (the API changes so much that the models package is rewritten before anyone uses it). The meta-skill is knowing which bets to make.