Davit gives Apple's container platform a native macOS UI that talks XPC instead of shelling out

What it sits on top of

Apple ships a container stack for Apple silicon that runs Linux containers as lightweight virtual machines, one VM per container. It comes with a command line tool and an API server, and no graphical interface. Davit is that interface: a native macOS application written entirely in SwiftUI, with no Electron and no web views.

The name is explained in the README. A davit is the shipboard crane that hoists cargo and small craft over the side, which the author offers as more or less what the app does with your containers.

The scope to understand before you install anything is that this is a UI for one platform, not a general container manager. It does not talk to Docker Engine. If your mental model is Docker Desktop managing a single Linux VM, the per-container VM design underneath changes several things, and the rest of this review is mostly about where those differences surface.

XPC rather than shelling out to the CLI

The architectural decision worth knowing is how Davit talks to the platform. It links Apple's own ContainerAPIClient library and communicates with the API server directly over XPC, which is the same wire path the container command line tool uses. The CLI binary is never invoked.

Everything follows from that: listing, lifecycle operations, live statistics, log streaming, image pulls, volume and network management, the in-terminal shell, and even bootstrap of the launchd services all go through the API.

Why it matters in practice is latency and fidelity. A wrapper that shells out to a CLI and parses text inherits the CLI's output format, its start-up cost per call, and its failure modes. An XPC client gets structured responses and can stream. It also ties the app tightly to Apple's client library, so a change there is a change here, which is a real cost of the approach.

The project ships a self-test that exercises the XPC service layer against the live daemon, which is the right thing to have when your transport is a private one.

Containers, images and the file browser

The container list shows live CPU, memory and IP address per row, with start, stop, kill, restart, delete, prune and search. Two operations are less common and more interesting. Export Filesystem saves a container's root filesystem as a tar archive. Edit and Recreate exists because containers are immutable on this platform, so editing opens the run sheet prefilled with the container's ports, environment, mounts, resources and network, with the image's own entrypoint, command and environment subtracted so that only your customisations are visible, and replaces the container on confirm.

The detail view has five tabs. Overview covers image, command, platform, resources, network addressing and published ports with an open in browser action, plus mounts, environment and labels. Logs streams in follow mode with a boot log toggle, a tail selector and copy. Stats charts CPU, memory and disk I/O using Swift Charts, with tiles for network and process count. Inspect is pretty-printed raw JSON. Terminal opens an interactive shell in Terminal or iTerm, and Files browses the container filesystem with navigate, download, upload and delete.

Images pull with streaming progress, and a Pull Latest action refreshes a tag to the newest digest. Each image shows platform variants, size, digest, which containers use it, and a Layers tab giving per-layer size and the command that built that layer.

Machines, volumes, networks and local DNS

Machines are Apple's lightweight general purpose VMs, with your home directory mounted and a stable machine DNS name. Davit can create one from any image with CPU and memory sizing, boot and stop it, set the default, delete it, and show configuration, streamed logs, live statistics and inspect JSON, with a one-click terminal into the machine's login shell. CPU count, memory and home mount can be edited, applying on the next boot.

Volumes can be created with a size, deleted, pruned, revealed in Finder, and browsed, which the app does by mounting the volume into a throwaway helper container and reusing the same file browser. Networks can be created with a subnet or as internal, deleted and pruned, with attached container counts.

Local DNS is the feature that changes day-to-day ergonomics. Under Settings, Platform, Registry and DNS, Davit creates host DNS domains through the platform's own DNS command, which needs one admin prompt. Set one as default and containers resolve at name dot domain from your Mac, with each container's overview showing its address.

Two smaller touches are worth knowing: command K opens a palette that jumps to any container, image, volume, network or machine, and opt-in notifications fire when a container stops unexpectedly while stops you trigger stay quiet.

Compose import, and the caveats attached to it

Compose import parses a compose file and shows a preview of exactly what will be created: services in dependency order, named volumes, networks, the equivalent run command per service, and warnings for anything unsupported. It then creates and starts the stack, honouring health checks, profiles, dependency conditions including service healthy and service completed successfully, env file and entrypoint, and variable interpolation from a sibling env file merged under the process environment.

The interpolation rules are documented to a level most tools skip. Values inside the env file are themselves interpolated at load time, a double-quoted or bare value expands against the process environment and earlier entries, and a single-quoted value stays literal. Inline comments are stripped the way Docker strips them. Two deliberate deviations from compose-go are listed: backslash escapes are not processed, so you use a doubled dollar sign instead, and a nested default keeps the default literal.

Two caveats follow from the platform rather than from the app. Service discovery: the platform's DNS cannot resolve compose service names, so up, start and restart write managed hosts entries into every running container of the project, refreshed on each run. Containers recreated outside compose keep stale entries until the next up or start, and images without a shell cannot be patched at all, which produces a warning. Resource limits: a service with no memory or CPU limit gets the platform default, and because each service is its own lightweight VM that default is reserved per container rather than shared across the stack.

The app binary doubles as a headless tool

The application binary is also a command line tool, which makes the whole feature set scriptable. Build an image from a directory, manage machines, and run a single container with docker-style flags:

Davit build -t <tag> <context-dir>
Davit machine list|create|boot|stop|delete|exec|set
Davit run [flags] IMAGE [COMMAND…]

The run mode documents its flags in detail and takes a hard line on the ones it cannot honour: interactive flags and docker flags with no platform mapping, such as restart, privileged, add-host, hostname and gpus, are rejected outright rather than silently ignored. For a tool whose whole value is matching expectations, refusing is better than pretending.

Compose gets the same treatment with plan, up, down, ps, logs, stop, start, restart, pull and exec subcommands, each accepting a file, an env file, profiles, verbosity flags and service names. File discovery follows Docker, walking up parent directories for the usual compose file names, with the COMPOSE_FILE variable taking precedence. One flag deserves calling out: up accepts a down-on-failure option that tears down only the containers that invocation created, leaving services it reused untouched.

Deep links work from the shell too, so a script or another application can open Davit on a specific container:

open davit://container/my-app

Logging for both the app and the compose path goes to stderr, controlled by a log level environment variable that accepts trace through critical and defaults to info.

Requirements and the limits that follow from them

The requirements are narrow and stated up front: an Apple silicon Mac running macOS 15 or newer, with macOS 26 recommended as the match for container 1.1, and Apple's container platform installed. On first launch Davit offers to install the platform for you, and the release notes say no admin rights are needed for that.

Three limits follow from the platform. Architecture: images that only exist for amd64 are detected automatically, and if Rosetta is installed the app adds the arch flag for you with a performance note attached; without Rosetta the run is blocked and the exact install command is offered. Immutability: containers cannot be edited in place, so every change is a recreate. Version: the project is at 0.1.x, with releases 0.1.29 on 2026-09-04, 0.1.30 on 2026-09-10 and 0.1.31 on 2026-09-11, and a roadmap file in the repository, so expect movement.

The last push was on 2026-09-11, and the repository is not archived.

Against Docker Desktop and OrbStack

The comparison people will reach for is Docker Desktop or OrbStack, and the honest framing is that they are solving a different problem. Those run Docker Engine, typically inside one shared Linux virtual machine, and give you the Docker API and Docker semantics. Davit is a front end for Apple's stack, where each container is its own micro VM and the API is Apple's. So the differences that matter are underneath: how memory is accounted for per container, how networking and DNS behave, what a compose service name resolves to.

What Davit offers over those is native. It is SwiftUI rather than Electron, it uses Swift Charts rather than an embedded browser plotting library, it opens terminals in your actual terminal application, and it drives the platform through XPC rather than a socket to a daemon. If you have picked Apple's container platform, that is the comparison that matters and Davit is well ahead of doing it by hand.

The licence is MIT, the code is Swift with a SwiftPM package manifest, and the repository carries a site directory alongside the sources. Upkeep is straightforward for a user, since releases are signed and notarized and delivered as a disk image, with a zip build used by the in-app updater and by the Homebrew tap the author publishes.

Editorial conclusion

Take it if you run Apple's container platform on an Apple silicon Mac and want a real Mac interface over it, with logs, live stats, a terminal, a file browser and working compose import. Leave it if you are on Intel, on macOS 14 or older, or expecting Docker Engine semantics, since unmapped docker flags are rejected outright and each service gets its own lightweight VM with memory reserved per container rather than shared. Check two things first: that Apple's container platform is installed or that you are happy letting Davit install it, and that your compose file does not depend on the platform's DNS resolving service names, because Davit works around that with managed hosts entries that go stale for containers recreated outside compose.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wouterdebie/davit on GitHub