IconquerServer: Laying the Foundation for a Swift NIO Game Backend

A focused greenfield sprint that stood up a documented, tested Swift server target in under 25 minutes, establishing the architectural bones for a multiplayer game backend.

Problem

Multiplayer game servers have a well-known bootstrapping problem: the gap between “idea” and “something that actually compiles, accepts connections, and can be reasoned about” is wide enough to kill momentum before any real work begins. IconquerServer needed a clean starting point — a Swift Package Manager project that wired together the right primitives (non-blocking I/O, structured argument parsing, and structured logging) without accumulating early technical debt that would fight the team later.

Approach

The project was structured around Swift Package Manager with a Tools version of 6.0, targeting macOS. The dependency selection reflects deliberate choices about the server’s long-term shape:

• SwiftNIO anchors the I/O layer, providing the event-loop foundation that a game server’s real-time demands will eventually require — connection handling, framing, and back-pressure all live here rather than in hand-rolled socket code.
• swift-argument-parser was pulled in early, signaling an intent to run this server as a proper command-line process with inspectable, documented flags — not a hardcoded binary.
• swift-log establishes a logging abstraction from day one, meaning future backend implementations (os_log, file sinks, remote aggregation) can be swapped without touching call sites.
• swift-docc-plugin inclusion at the project’s inception is a quiet but meaningful statement: documentation is infrastructure, not an afterthought.

The package defines three targets — IconquerServer (the library core), iconquer-server (the executable entry point), and IconquerServerTests — a separation that keeps the testable logic decoupled from the binary surface.

Results

Within a 21-minute window (first commit at 01:37 UTC, second at 01:58 UTC on April 24, 2026), the project went from nothing to a structured, multi-target Swift package with a coherent dependency graph. Two commits represent the complete founding of the repository: an initial scaffold followed by a refinement pass. The test target was established as a first-class citizen alongside the library and executable, rather than bolted on later.

No fabricated metrics apply here — this is a project at its earliest breath. What shipped is architecture: a skeleton that makes the right things easy and the wrong things inconvenient.

Judgment Calls

Several decisions in this brief window reveal thinking beyond “get it running”:

Separating library from executable. Splitting IconquerServer and iconquer-server into distinct targets is easy to skip when moving fast. It wasn’t skipped. This means game logic and server primitives will remain testable without spinning up a process, and the executable stays thin.

SwiftNIO at the foundation, not added later. Retrofitting an event-loop model onto a server built around synchronous assumptions is painful work. Choosing NIO as the base layer before any feature code exists means the concurrency model is consistent from the first handler written.

swift-docc-plugin from commit one. Documentation tooling is frequently “we’ll add that when we’re further along.” Including it in the initial manifest removes that future negotiation entirely — the infrastructure to generate and publish docs exists the moment the project does.

No CLAUDE.md, no design proposals — and that’s appropriate. At two commits and 21 minutes old, this project doesn’t yet need formal process scaffolding. The judgment here is knowing what not to formalize yet, keeping the project light enough to move fast while the shape of the problem is still being discovered.