HPGCryptoKit

Purpose

Experimented with creating and publishing a CocoaPod for the Hot Potato Games iOS infrastructure. The kit was intended to handle crypto-related utilities (hashing, signing, or token management) for HPG apps. Only this one was ever published — CocoaPods' publishing workflow was more ceremony than reward for the scale of the project.

Stack

What I Learned

• CocoaPods is iOS's oldest third-party dependency manager — predating Swift Package Manager by years. Publishing requires: a .podspec file (name, version, source, platform, dependencies), pushing to the CocoaPods trunk registry (pod trunk push), and waiting for validation. The process works but feels heavy compared to SPM (which is just a Git tag) or pub.dev (which is a single command).
• CocoaPods is in decline as SPM matures. Apple ships SPM built into Xcode. New projects increasingly use SPM exclusively. CocoaPods will likely follow the same path as Carthage (another iOS dependency manager) — still functional, still used in legacy projects, but no longer the default choice for new work.
• Publishing even one package to a registry teaches the full lifecycle: naming, versioning, metadata, CI validation, and the reality that maintaining a published package means responding to issues, updating for new OS versions, and managing breaking changes. One published package is worth a hundred private utilities because it forces you to think about your code as a product others depend on.

Key Insights

• The Hot Potato Games infrastructure (HPGCryptoKit, the game engine, the website) is slowly building into a real platform. Each piece — a published package here, a game there, a website, a brand — adds to the foundation. The platform is not visible yet because the games have not launched at scale. But the infrastructure is accumulating. When the games ship, the platform will be ready.
• Only deploying one CocoaPod and then stopping is not failure — it is data. The feedback was clear: the publishing overhead was not worth it at the current scale. When HPG has multiple iOS apps sharing common code, a published package makes sense. For one app, a local Swift package or just shared source files is simpler. Match the tool to the scale.