IconquerGameKit: Laying the Foundation for a Cross-Platform Game Logic Library

A freshly minted Swift 6.2 package that establishes the scaffolding for shared game logic across Apple’s entire platform ecosystem.

Problem

Building a game that runs well on iPhone, Apple TV, Mac, Apple Watch, and Vision Pro is not a matter of writing one codebase and hoping for the best. Platform-specific quirks, input models, and performance characteristics demand that shared logic be isolated deliberately — cleanly separated from any one host environment. The challenge IconquerGameKit sets out to address is providing a reliable, testable game logic layer that any surface in the Iconquer family can depend on without coupling itself to a specific platform’s frameworks or assumptions.

Approach

James initialized IconquerGameKit as a modern Swift package targeting Swift 6.2, the toolchain’s latest structured-concurrency-era release. Rather than scoping the library narrowly, he declared support for all five of Apple’s current platforms — macOS, iOS, tvOS, watchOS, and visionOS — from the outset. That upfront declaration is itself an architectural commitment: every API surface added to the library will need to justify its presence across the full matrix, discouraging the kind of platform-creep that tends to make shared libraries quietly un-shareable.

The package ships with two targets baked in from the first commit: IconquerGameKit (the production library) and IconquerGameKitTests (its test suite). Standing up the test target at project creation, before any feature code exists, signals an intention to treat testability as a property of the architecture rather than something retrofitted later.

The two-commit history — both landing within 18 seconds of each other on April 10, 2026 — reads as a deliberate initialization sequence: repository scaffolding followed immediately by package configuration, with no loose exploration commits muddying the record.

Results

• v0.1.0 shipped — a versioned, tagged release exists, meaning the package is already suitable for consumption as a dependency by other packages in the Iconquer ecosystem.
• Full platform matrix declared: macOS, iOS, tvOS, watchOS, visionOS — the broadest possible Apple coverage, locked in at day one.
• Swift 6.2 tools version — the project enters the world at the current language standard, avoiding the technical debt of inheriting older concurrency models.
• Test target present from the initial commit, establishing a test-first contract before any domain logic is authored.

Judgment Calls

Versioning immediately. Tagging v0.1.0 on a two-commit repository might look premature, but it reflects sound dependency management thinking. Downstream packages in a multi-repo game project need a stable ref to pin against. A named release — even a nascent one — is more trustworthy than a floating branch tip. James made the call that a stable identity matters more than waiting for the library to feel “complete.”

All five platforms, day one. It would have been simpler to start with iOS and macOS and add watchOS and tvOS later. The risk of that approach is that late-added platforms surface architectural assumptions baked in during the iOS-first phase — assumptions about screen size, input, or lifecycle that quietly break smaller targets. By declaring the full platform surface at initialization, every subsequent design decision is made with the constraint already present.

Swift 6.2 without hesitation. Adopting the latest tools version means opting into Swift 6’s strict concurrency checking. For a game logic library that will eventually model state, timers, and potentially networked play, building on structured concurrency from the ground up is the right foundation — even if it asks more of contributors early.

The project is young, but its shape is intentional. IconquerGameKit starts narrow on code and wide on commitment, which is exactly the right posture for a shared library that other work will depend on.