Extract ContainerAPIClient into a light, dependency-minimal client SDK for app frontends

[dioKaratzas]

TL;DR: Could ContainerAPIClient be extracted/repackaged into a small, supported client SDK — its own Foundation Codable models plus the XPC client — that does not transitively pull the runtime (Containerization), gRPC, or NIO? A native app frontend that drives an installed container only needs XPC + Codable, but linking ContainerAPIClient today pulls ~34 packages (~28 MB stripped) and ties the client's source stability to a separately-versioned runtime.

Who's asking / what works today

I'm building a native macOS management GUI on top of container, shipped as a Developer-ID-signed, notarized, non-sandboxed app (DMG / Homebrew cask — not the App Store). Linking ContainerAPIClient and talking XPC to the per-user container-apiserver works today with zero entitlements — list() returns running containers (the other calls share the same XPC path). So this is not a "can I reach the API" request (that's the sandbox discussion, #323) — it's about the weight and shape of what an app frontend has to link.

The problem: a client carries the whole engine

Linking ContainerAPIClient resolves ~34 packages — gRPC (×3), SwiftNIO (×5), swift-protobuf, the entire containerization runtime, Yams, zstd, … — for a ~28 MB (stripped) / ~53 MB binary. A client that just does XPC + Codable shouldn't need the runtime or a gRPC/HTTP stack. The weight comes from two couplings:

• ContainerResource (the model types) imports the Containerization modules and exposes those types in public signatures — e.g. ContainerSnapshot.platform is ContainerizationOCI.Platform. Since containerization is pinned with exact: in Package.swift, an embedder's client is transitively bound to the runtime.
• The build path (ContainerBuild / BuildKit) brings gRPC and protobuf, which a non-building client never calls.

The ask: extract a light client SDK

A dedicated product — say ContainerClientKit — containing:

• client-owned, Foundation-only Codable DTOs for the resources (container, image, volume, network, registry, machine, system, stats, disk-usage), rather than re-exported Containerization types; and
• the XPC client. The transport itself is already light — ContainerXPC imports only Foundation (plus a small error module). Today's ContainerClient couples to Containerization only through the types in its method signatures, which is exactly what client-owned DTOs would replace.

…and that depends on none of Containerization, gRPC, NIO, or protobuf. That single change shrinks an embedding app dramatically and decouples the client from the runtime's dependency graph.

Is extracting a light client SDK product something the team would consider?

[saehejkang]

The team has been considering something similar to what you are asking for. You are correct, in that the ContainerClient is very messy and needs lots of modification. @jglogan would be a better person to speak more on this, as I know it has been something on his mind for a while. Here is a little snippet of his thoughts about this and what he wants to get done in the future.