Docker Desktop 4.14 selects Apple's Virtualization framework by default

A Docker image does not identify the software that runs the Linux VM on a Mac. Docker Desktop maintains that layer outside the image, and an update can change it while leaving the application's artifact unchanged. Desktop 4.14 selects Apple's Virtualization framework as its default hypervisor on macOS 12.5 and later. The November 10 release notes say existing installations on those systems migrate to the new default too.

That makes the release relevant to developers who have not selected an experimental backend themselves. The host version determines whether the migration applies. Describing a workstation only as a Mac running Desktop leaves out the condition that selects its virtualization implementation.

I value Docker's ability to package an application environment explicitly. This change concerns the machinery below that package. Keeping those two things distinct makes it easier to explain why an unchanged image can behave differently after a workstation update.

The Linux guest remains part of the architecture

Docker's earlier explanation of Desktop describes the Linux VM in which its Linux tools and containers run. It also describes host filesystem and network integration around that VM. Changing the hypervisor does not remove the guest or turn a Linux image into a native macOS process.

The Mac preferences guide available before this release already exposes a Virtualization framework option. The November change concerns default selection and migration. It is therefore a change in which existing implementation Desktop chooses for eligible hosts, not the first appearance of a virtual machine setting.

That distinction gives an investigation a useful starting point. Two users can have the same application image and Desktop release while different host versions place them on different virtualization paths. Recording the host version and selected backend describes the execution environment more accurately than comparing the image tag alone.

Virtualization, emulation and file sharing remain separate

The release notes separately revert QEMU to 6.2.0 to address errors while running emulated amd64 code. One named symptom is PR_SET_CHILD_SUBREAPER is unavailable. That correction concerns architecture emulation, which is a different part of the execution arrangement from choosing the host's VM framework.

This distinction matters for a developer trying to reproduce a failure. A native-architecture workload and an emulated workload can exercise different code even when they use the same Desktop installation. The QEMU change gives a specific explanation for a class of emulation errors. It should not be described as a general performance result for the new hypervisor default.

File sharing is another separate choice. The preferences guide describes gRPC-FUSE and the experimental VirtioFS option, along with directory sharing settings. The hypervisor default does not by itself establish which sharing path a particular container uses. An account of source access needs the sharing configuration as well as the VM configuration.

My preference is to keep those details explicit when they affect a development workflow. A statement that Docker uses Apple's framework is useful, but it cannot explain every filesystem or architecture-specific observation. The release itself names separate changes at those levels.

The conventional Docker socket returns

Desktop 4.14 restores /var/run/docker.sock on Mac by default. The notes name compatibility with tools such as Tilt and docker-py as the reason. They also describe fixing Dev Environment creation on new Mac installations when the conventional socket was unavailable.

This is another example of a dependency outside the application image. A tool can expect the daemon endpoint at a conventional path even when Docker's own CLI can locate the environment through a context. A successful command in one interface does not establish that every other client can find the same endpoint.

Restoring the socket addresses that compatibility expectation. It does not alter the application's build definition or the image it produces. Instead, it makes an existing discovery convention available again to clients that rely on it. That is a concrete operational change for workflows coordinating several Docker-aware tools.

The distinction also explains why a daemon connection error can be misleading when read as an engine health report. An engine can exist while a client cannot reach the endpoint it expects. The note about new Mac Dev Environments identifies exactly that class of failure.

Network defaults also change in this release

Desktop now requires an internal subnet of size /24. The notes say a previously configured /28 expands automatically. They identify a possible clash with existing infrastructure as relevant if networking stops working. That is an independent configuration change accompanying the virtualization migration.

When several defaults move in one update, attributing every difference to the most visible one can obscure the actual cause. A subnet expansion changes which addresses Desktop reserves internally. A hypervisor selection changes how its VM runs. Their consequences can appear during the same upgrade without coming from the same mechanism. A useful problem report therefore names the operation that fails and the configuration relevant to it. For a connection failure, the endpoint and network settings add information that the application image cannot supply, even when the image is fully identified.

Docker also increases the default DHCP lease time to prevent network interruptions occurring every two hours. The note supplies the observed symptom and the kind of setting changed. It does not establish that every network interruption on a Mac comes from lease renewal.

Resource visibility helps identify the workload

The release announcement describes the Resource Usage extension, which displays container usage and aggregates it by Compose project. That gives a workload-level view alongside the environment changes. A project aggregate and the VM's overall state describe different scopes of resource consumption.

For an engineer assessing this release, the useful result is a more explicit account of the local environment. Eligible Macs move to Apple's Virtualization framework, emulated amd64 execution receives a separate QEMU adjustment, and conventional socket compatibility returns. Those changes explain different parts of how the same image reaches a running development container.