Releases: henrywang/Berthly
Release list
Berthly 1.0.1
What's Changed
Fixes a packaging bug from v1.0 that could show "Berthly.app is damaged and can't be opened, move to Trash" for anyone who extracted the release with unzip from a shell instead of double-clicking in Finder. Every build file carries a kernel-set com.apple.provenance extended attribute; zip can't hold extended attributes natively, so ditto AppleDouble-encodes it into the archive. Finder/Archive Utility reconstitutes that correctly on extraction, but plain unzip doesn't, and materializes literal ._* files that corrupt Sparkle's nested Installer.xpc code signature.
Distribution now ships as a .dmg instead of a .zip, which sidesteps the whole failure class rather than working around it — a DMG is a real filesystem image, so extended attributes live on it natively with no encoding step to get wrong. Sparkle 2.x supports .dmg update packages directly, so this covers both the manual GitHub download and the in-app auto-update with one artifact.
Also adds scripts/smoke.sh, which checks an installed Berthly.app directly — code signing, Gatekeeper/notarization acceptance, Info.plist sanity, and the Sparkle appcast's reachability/shape. This closes a gap the existing UI/E2E test suites structurally can't reach: they exercise a re-signed, ad-hoc test build, never the real notarized artifact a user actually downloads — which is exactly how this bug shipped undetected in v1.0.
Testing
This release shipped only after its gate run passed on the release commit:
- 417 unit tests passed — 88% line coverage of the pure
logic layer (Berthly/Coremodels, mapping, and planning; 55%
including the daemon/terminal I/O plumbing, which the end-to-end suite
exercises against a real daemon instead). - 42 UI tests (deterministic mock-daemon XCUITest) and
13 real-daemon end-to-end journeys guard the UI wiring and the
daemon integration. SwiftUI view bodies are covered by these suites, not
unit tests, by design.
Full Changelog: v1.0...v1.0.1
Berthly 1.0
The first release of Berthly — a native macOS app for Apple's container: build images, run containers and machines, manage networks and volumes, and tail logs from a real GUI instead of the command line.
Highlights
- The full management surface — containers, machines, images, volumes, networks, registries, and the daemon itself, with subcommand-by-subcommand CLI parity documented in PARITY.md.
- Integrated terminal — real login shells in containers and machines, built on SwiftTerm, with color themes.
- Live monitoring — per-container CPU/memory/network charts, pinned favorites in the menu bar, and notifications when a pinned container or machine changes state.
- Builds that keep going — streaming build logs, background builds with a toolbar progress indicator, and every build's context remembered for one-click Rebuild.
- Keyboard-first — ⌘K command palette, ⌘1–6 section switching, ⌘⌥1–3 detail tabs, and menu shortcuts for every action.
- Zero to running — Berthly can install Apple's signed
containertoolchain and start and monitor the daemon for you.
Requirements
- Apple Silicon Mac, macOS 26 or later.
Install
Warning
Superseded by v1.0.1 — install that instead. This release's zip has a packaging flaw: extracting it with unzip in Terminal corrupts the app's code signature (macOS then reports "Berthly.app is damaged and can't be opened"). Only Finder's double-click extraction is safe. v1.0.1 ships as a DMG, which doesn't have this problem.
Download Berthly-1.0.zip below, double-click it in Finder to extract (do not use unzip in Terminal — see the warning above), and drag Berthly.app into Applications. The app is Developer ID–signed and notarized by Apple, so it opens without warnings. Future updates arrive in-app (Berthly → Check for Updates…).
Testing
This release shipped only after its gate run passed on the release commit:
- 417 unit tests passed — 88% line coverage of the pure logic layer (
Berthly/Coremodels, mapping, and planning; 55% including the daemon/terminal I/O plumbing, which the end-to-end suite exercises against a real daemon instead). - 42 UI tests (deterministic mock-daemon XCUITest) and 13 real-daemon end-to-end journeys guard the UI wiring and the daemon integration. SwiftUI view bodies are covered by these suites, not unit tests, by design.