Withdrawn candidate, retained for provenance. Use the replacement v0.4.1 release.
This earlier prerelease was originally tagged v0.4.1 and built from 19c0786. Subsequent notification-delivery failures prompted further investigation, finite cache leases and guest-demand-aware reclamation. Its original archive remains attached here unchanged.
Original archive SHA-256: 799e48bccc412e3f1a4e1f7701417d3e7abc69886783192f48d8db0ce347a9b1.
Original Apple Accepted submission: 31926a04-6ba2-4be8-8051-8dbd8ae2ffac.
The internal application version remains 0.4.1; the rc.1 tag identifies this withdrawn candidate and does not represent a rebuild.
Original notes, retained as historical claims for this candidate:
This build is temporarily marked as a prerelease while an additional M5 file-watch timeout is investigated. The original packaged commit passed both hardware qualifications, but a later check of the same production runtime did not observe a host reply in the guest within 30 seconds. The memory-accounting and constrained-build recovery checks passed.
0.4.1 corrects macOS memory accounting for guest RAM and hardens Docker builds, shared files and published connections.
- Guest RAM is charged once when host and guest access the same pages. Partial reclamation still returns physical pages, and reuse is charged again. A real application build at 24 GiB completed below the configured size; 12 and 8 GiB tests also stayed below their settings, then successfully ran a container and a fresh build after the oversized build exhausted guest memory, without restarting the VM. The setting limits guest RAM; host allocations add overhead.
- Shared files recover when macOS loses detailed filesystem events or the invalidation queue overflows. Cache resets cover names, attributes, open files and mappings, including same-size/same-mtime writes and truncation. Older guests retain conservative cache expiry. Loss recovery is tested explicitly on both Macs.
- Published connections recover from failed socket-map joins and handle short-connection bursts without exhausting the guest agent's descriptor budget or listen backlog. A guest receive-lock deadlock, borrowed-buffer cleanup and wakeup issues are fixed; regression gates check completed HTTP and resource drainage after bursts.
- Memory pressure and idle reclamation scale with VM size and resizing. Build workers no longer inherit the engine's OOM protection, so an oversized build can fail while Docker remains usable.
- Installation preserves an existing developer wrapper. Startup works without the Docker CLI, and cleanup handles inherited home locks.
Full share, guest-disk and amd64 benchmarks were run on M1 and M5 before packaging. In the controlled M1 comparison, npm and yarn installs improved by 8.9% and 16.8%, while Docker readiness cost an additional 191 ms and warmed HTTP an additional 5 µs. Other rows vary; M5 observations were taken under variable background load. The report retains raw samples, alternating old/new comparisons, the established workload-specific variation and host background conditions. The memory allocation correction adds cold-start work and kernel metadata; smaller Activity Monitor numbers do not imply equivalent physical RAM savings. See release measurements and the memory investigation.
Built from 19c0786eea1672f8617aeeaedcb470059cdcf3db, which passed 320 workspace tests, 15 signed hypervisor tests, formatting, clippy, CI regression checks and all twelve hardware gates on both M1 and M5. The actual release archive passed fresh-install doctor/start, arm64 and amd64 containers, published TCP/UDP, guest IPv6 routing and stop on both Macs. Signatures, the stapled ticket and Gatekeeper acceptance were verified on both. Apple notarization: Accepted, submission 31926a04-6ba2-4be8-8051-8dbd8ae2ffac. M1 optional PostgreSQL-client and external IPv6 probes were unavailable; corresponding M5 checks passed.
Archive SHA-256: 799e48bccc412e3f1a4e1f7701417d3e7abc69886783192f48d8db0ce347a9b1.
No full working-day sleep/wake and VPN-change soak was performed; the hardware wake simulation and overnight tests exercise different conditions.
Under heavy host filesystem load, a later diagnostic observed a correct file-change notification arrive after about 13.64 seconds. Event-loss recovery does not guarantee prompt delivery from a busy macOS event daemon; shared-file visibility can still be delayed under those conditions.