Mactoy Release Notes

Mactoy 0.8.0 was released on 2026-10-30; this update adds checksum and read-back verification, and makes flashing cancellable.

• Flash Image can check the image against a SHA-256 you paste or load from a .sha256 or SHA256SUMS file before the drive is erased.
• With Check the drive after writing on (the default), Mactoy reads the drive back and compares it with the image; this takes extra time and can catch a failing drive or one smaller than it claims.
• .img.xz and .img.gz files are decompressed while writing, so a 1.5 GB image flashes with under 100 MB of memory.
• A file Mactoy cannot read is caught before anything is written, and an image too big for the drive is refused up front when its size is known (raw and .xz files).
• Install and Update can be cancelled until writing to the drive starts; after that Cancel is refused, because stopping between Ventoy's partition writes would leave a drive that neither starts nor mounts.
• Flash Image can be stopped at any point, with a confirmation first.

Source: https://github.com/cashcon57/mactoy/releases/tag/v0.8.0

Themes move to Documents

• My Themes now lives in a Mactoy Themes folder in your Documents folder instead of inside Mactoy's Application Support folder, which a full uninstall deletes.
• Themes from v0.7.0 move to the new folder the first time 0.7.1 starts. Only whole themes move; other files stay in the old folder, and the old folders are removed once they are empty.
• If a theme cannot be moved, for example because macOS does not let Mactoy use Documents, the theme picker says so and still shows the old folder.
• The folder is created the first time you save or import a theme, so a new user is not asked for Documents access at launch.
• The picker shows where the folder is, with a Show in Finder button.
• Removing a theme moves it to the Trash.
• Each theme is a folder named by its id, with a hidden description file. Renaming or moving that folder hides the theme from Mactoy.

Fixes

• Saving a drive's theme that came from My Themes no longer adds a second copy when the theme is unchanged and still in My Themes.
• Before replacing a drive's theme or erasing the drive, Mactoy compares My Themes on disk with the drive's copy, so a theme deleted in Finder in the meantime, or changed on the drive, is still offered a save.

The privileged helper did not change, so the update does not ask you to approve it again.

Official release notes

Mactoy v0.7.0: boot menu themes, and a new icon

Ventoy's boot menu is plain out of the box. Ventoy supports themes, but setting one up meant finding a theme, copying the right files onto the drive and editing ventoy.json by hand. Mactoy now does that for you.

What's new

Pick a theme, with previews

The theme picker shows 14 community themes. Each preview is a capture of that theme booted in Ventoy, so what you see is what you get.

• New drives get Catppuccin Mocha unless you choose otherwise. That's an opinionated default, so the Install tab says so, and picking Ventoy default keeps Ventoy's own look. Mactoy remembers your choice. Catppuccin Mocha is built into the app, so a fresh install doesn't need to download it.
• Existing drives: on Manage Disk, click Change Theme…. Mactoy changes only the theme setting in ventoy.json and keeps the rest of your setup. It saves your original ventoy.json once, as ventoy.json.mactoy-backup.

Bring your own theme

Add Theme from File… takes a theme's .zip, its folder or its theme.txt. It doesn't matter whether the theme is at the top of the download or a few folders down. If a download holds several themes, such as a repository with a few colour variants, Mactoy asks which one you want and lists the ones made for Ventoy first.

Themes you add are kept in My Themes, so you can use them on other drives.

Your current theme is safe

If a drive already has a theme that Mactoy doesn't know, Mactoy offers to save it to My Themes before replacing it, and before erasing the drive for a fresh install. Save to My Themes on Manage Disk makes a copy without changing anything.

When a theme's download disappears

Themes are downloaded from their authors' GitHub pages, which can move. If a download is gone or has changed, Mactoy says so plainly rather than showing a download error. It offers to report it, to open the theme's page, or to add the theme from a file you found yourself, and marks it Unavailable in the picker. A connection problem gets its own message.

Add your favourite theme

The list lives in this repository as themes/catalog.json. To add a theme, open a pull request with a screenshot. Here's how.

New icon

Mactoy has a new icon: a USB stick drawn like a blueprint, made from scratch as vector layers in Icon Composer. It replaces the old AI-generated one.

On macOS 26 it's a Liquid Glass icon that follows your icon style: default, dark, tinted or clear, shown above from left to right. On macOS 13 to 15 you get the default look as a standard icon.

Smaller fixes

• Several commands running at once could stall until their time limit. Each now reads its output on its own thread.

Safety

Theme files come from other people, so Mactoy is careful with them:

• Each theme in the list is pinned to one exact download by SHA-256. A download that doesn't match is refused.
• Only .txt, .png, .jpg, .jpeg, .tga and .pf2 files are copied. .cfg files never are, because Ventoy would run them as boot scripts.
• A .zip you add is checked before it's unpacked, then unpacked in a separate process.
• On the drive, Mactoy never follows links and only deletes theme folders it created.
• Mactoy fetches the theme list and previews from this repository on GitHub when it starts and when you open the picker. Nothing about you or your drives is sent.

Install

# Download Mactoy-0.7.0.dmg from the release assets.
open Mactoy-0.7.0.dmg
# Drag Mactoy.app into /Applications, replacing the old version.

Apple-notarized. The way the app talks to its background helper hasn't changed, so updating doesn't ask you to approve the helper again.

How this was tested

• 592 automated tests (205 app, 387 library), 86 of them for the theme installer.
• End to end on simulated drives, for all 14 themes:
  1. A 1 GB raw disk image is attached with hdiutil as a block device, the way a USB stick appears.
  2. Ventoy is installed on it with Mactoy's install driver (GPT).
  3. The theme is downloaded, checked against its pinned SHA-256 and written to the exFAT data partition by the same ThemeFetcher and ThemeInstaller code the app uses.
  4. The image is booted in QEMU with UEFI firmware, and Ventoy's menu is captured. Those captures are the previews in the picker.
• CI downloads every theme in the list and checks it against its SHA-256 pin, and checks the copy of Catppuccin Mocha built into the app byte for byte.
• Theme import was tried on real downloads, including a repository archive holding many themes.
• Independent code review of each part of the feature.

Not tested end to end:

• The app's own theme screens (theming right after an install, Change Theme…, save before replacing). Their logic is covered by the automated tests, which write to a temporary folder set up to look like a Ventoy drive, including the ._ files macOS leaves on exFAT.
• A physical USB stick booted on real hardware.

If anything looks wrong on your drive, please open an issue.

SHA256 of Mactoy-0.7.0.dmg is published below the release assets.

Mactoy v0.6.0: Time Machine drives are protected, and no more freezes

Both changes in this release started as pull requests from @gbentz2: #12 and #13. Thank you!

What's new

Time Machine drives are locked (#13)

To macOS, a USB Time Machine drive is just another external disk, so Mactoy used to list it as something it could erase. Picking the wrong row could wipe your backups.

Now Mactoy recognises Time Machine drives:

• They're still listed, marked Time Machine backup · locked, and Mactoy won't pick one when it chooses a drive for you.
• Install, Update and Flash are blocked on them, and the Install and Flash tabs explain why.
• If you really do want to reuse an old backup drive, Unlock This Drive… lets you, after a warning that its backups will be lost. The unlock covers that one drive until you lock it again, unplug it or quit Mactoy. The erase confirmation also reminds you that the backups will be erased.
• Mactoy checks again right before writing, so a backup drive can't slip through between refreshes.

Older Time Machine drives formatted as Mac OS Extended (HFS+) aren't detected.

No more beachballs (#12)

Mactoy refreshed its disk list on the main thread every two seconds. With a busy drive attached, such as a Time Machine destination, the app could freeze for 15 to 20 seconds at a time, and clicking Install could hang it. That work now happens in the background.

The erase confirmation opens straight away and fills in how much data is on the drive a moment later. That figure is now correct for APFS-formatted drives too; before, Mactoy couldn't measure them at all.

Smaller fixes

• If refreshing the disk list keeps failing, the sidebar says the list may be out of date, instead of silently showing an old one.
• Commands that print a lot of output no longer hang. On a Mac with a very large number of volumes, this could have left the disk list empty.

Install

# Download Mactoy-0.6.0.dmg from the release assets.
open Mactoy-0.6.0.dmg
# Drag Mactoy.app into /Applications, replacing the old version.

Apple-notarized. The way the app talks to its background helper hasn't changed, so updating doesn't ask you to approve the helper again.

How this was tested

• 167 automated tests, 23 of them new. The Time Machine lock and the output fix were each checked by putting the old behaviour back and confirming a test fails.
• The used-space figure was checked against df on APFS and exFAT disk images.
• Independent code review of both pull requests and of the follow-up work.

Not tested on a real Time Machine drive. The detection follows what diskutil reports and its documentation, but I don't have a backup drive to try it on. If yours isn't marked, please open an issue with the output of diskutil apfs list.

SHA256 of Mactoy-0.6.0.dmg is published below the release assets.

Mactoy v0.5.1 — the "remove the helper" checkbox works

A small fix release.

What's fixed

"Remove the helper when done" now does what it says

The approval sheet Mactoy shows before its first install has a checkbox to remove its background helper afterwards, ticked by default. It never worked: once you approved the helper, Mactoy quietly unticked it, so the helper always stayed registered. Now your choice holds. With the box ticked, the helper is removed when the install, update or flash finishes, and you approve it again next time. Untick it to keep the helper and skip the approval on later runs.

The checkbox is now labelled Remove the helper when done, and the sheet's wording no longer promises a one-time approval when the default removes the helper.

Update Ventoy no longer gets stuck without the helper

Update Ventoy reads the stick through the helper to see which Ventoy version is on it. With the helper removed, that check failed, and the Update button stayed disabled. The hint even suggested a fresh install, which would erase the stick.

The hint now has a Set Up Helper… button. It shows the usual approval sheet; once you approve, Mactoy checks the stick again and you can update. Setting up the helper this way never starts an install, update or flash on its own. That includes a failed one waiting for you to press Retry, and it holds even if you cancel partway through.

Install

# Download Mactoy-0.5.1.dmg from the release assets.
open Mactoy-0.5.1.dmg
# Drag Mactoy.app into /Applications, replacing the old version.

Apple-notarized. The helper itself is unchanged from v0.5.0, so updating doesn't make you approve it again.

How this was tested

• 144 automated tests, 16 of them new. Each fix was checked by re-introducing the bug and confirming a test fails.
• Several rounds of independent code review. Two of them caught ways the first version of the Set Up Helper button could restart a failed install after you approved the helper. Both are fixed and covered by tests.

SHA256 of Mactoy-0.5.1.dmg is published below the release assets.

Mactoy v0.5.0 — MBR installs and image folders in Manage Disk

Thanks to @FrancYescO for #11, and to @swagdotsh for #10 — Mactoy's first pull request from outside.

Heads-up: new installs default to MBR

Install Ventoy used to always write a GPT partition table. It now defaults to MBR, the same as Ventoy2Disk, because MBR sticks boot on older BIOS PCs as well as modern UEFI machines. If you want the old layout, pick GPT on the Install tab before installing. Existing sticks aren't affected; Update Ventoy keeps whatever layout a stick already has.

What's new

MBR or GPT (#11)

Install Ventoy has a new Partition style switch:

• MBR (default) boots on both legacy BIOS and UEFI. Choose it if you're not sure.
• GPT is the modern partition table. Choose it if a machine you'll use needs GPT.
• Drives larger than 2 TiB (about 2.2 TB) always use GPT, because MBR can't address them.

The confirmation sheet says which style will be written, and that choice is locked in when you confirm — Retry uses it too.

The MBR layout is the one Ventoy2Disk writes. After an MBR install, Mactoy reads the drive's first sector back and checks it against what was written, so a stick that wouldn't boot on older PCs can't report success.

Image folders in Manage Disk (#10)

Manage Disk used to list only images at the top of the drive. It now lists the same images Ventoy's boot menu will show:

• images in subfolders;
• only the folder set by VTOY_DEFAULT_SEARCH_ROOT in /ventoy/ventoy.json, if you've set one — and Add ISO… copies there;
• skipping folders that contain a .ventoyignore file, trash folders, anything deeper than VTOY_MAX_SEARCH_LEVEL, and the image types you've filtered out with VTOY_FILE_FLT_*.

Each row shows the image's path on the drive, since two folders can hold files with the same name.

Smaller things

• Update Ventoy on MBR sticks moves the "active" flag back to the Ventoy partition if another tool moved it, as Ventoy's own updater does.
• Running a second copy of Mactoy no longer gets stuck. If the background helper belongs to another Mactoy version — say you opened this one from the DMG while another one is in Applications — Mactoy now switches the helper over to its own and tries again, instead of failing every time. If macOS asks you to approve the helper again, approve it and the install carries on.

Install

# Download Mactoy-0.5.0.dmg from the release assets.
open Mactoy-0.5.0.dmg
# Drag Mactoy.app into /Applications, replacing the old version.

Apple-notarized. If macOS asks you to approve Mactoy's background helper again after updating, turn Mactoy on in System Settings → General → Login Items (called "Login Items & Extensions" on newer macOS).

How this was tested

I can't test on physical USB sticks and old PCs, so this release was tested by running Mactoy's real install and update code against disk images, then booting those images in QEMU:

• MBR (Secure Boot support on and off) and GPT sticks boot to the Ventoy menu under both UEFI and legacy BIOS.
• Updating an MBR stick, including switching Secure Boot support and repairing a moved active flag, keeps it booting under both.
• GPT installs write the same bytes as v0.4.0: checked by installing with the released v0.4.0 and with this version and comparing the results.
• Manage Disk's list matches Ventoy's actual boot menu on the same stick, with and without a search root.
• 128 automated tests, and several rounds of independent code review.

Known limitations

• Tested in an emulator, not on physical machines. QEMU's firmware follows the specs closely; some real machines don't. If an MBR stick from Mactoy won't boot where one from Ventoy2Disk does, please open an issue.
• The active-flag repair couldn't be shown to fix a real machine, because the emulated BIOS boots either way. It matches what Ventoy's own updater does.
• Manage Disk can show a few images the menu won't: .efi files (the menu shows them only when booted in UEFI mode), and anything hidden with the image_list / image_blacklist plugins, which Manage Disk doesn't read. When it can't tell what the menu will show — for example, per-boot-mode settings in ventoy.json — it lists the whole drive.
• Manage Disk doesn't list files whose names start with ., which Ventoy's menu does show. On a drive used from a Mac these are ._ metadata files, not images.

SHA256 of Mactoy-0.5.0.dmg is published below the release assets.

Mactoy v0.4.0 — Secure Boot toggle, MBR update repair, tarball cache, sidebar selection

Three issues from the tracker, plus a bootloader-corruption bug in Update Ventoy that turned up while investigating one of them. Thanks to @Bomret for #9, @poshpaws for #8 and @d6v5nhcvzs-afk for #7.

Do this if you've used Update Ventoy before

If you updated a Ventoy stick with Mactoy v0.3.0, v0.3.1 or v0.3.2, and that stick was originally created by Ventoy2Disk with its default MBR partition style, run Update Ventoy on it again with v0.4.0. The earlier versions damaged its legacy-BIOS bootloader (details below). Your ISOs are not affected, and the stick still boots on UEFI machines, so you may not have noticed.

Sticks that Mactoy itself installed are GPT and were never affected.

What's new

Secure Boot support toggle (#9)

Ventoy's EFI partition ships with BOOTX64.EFI being the UEFI shim, which then finds its way to the real GRUB (grubx64_real.efi). That's what lets a Ventoy stick boot on a PC with Secure Boot on. It's also one more thing that has to work on the firmware you're booting: the report in #9 is a 2011 iMac that freezes in the shim with nothing on screen, while the same stick boots fine if GRUB is started directly.

Ventoy2Disk has an option for this (-S, or Secure Boot Support unticked in the GUI) that rewrites the EFI partition so BOOTX64.EFI is GRUB and the shim, MokManager and enrolment certificate are gone. Mactoy had no equivalent. Now it does:

• Install Ventoy has a Secure Boot support switch. On by default, same as Ventoy2Disk. Turn it off for sticks meant for Macs, or for PCs that hang on a blank screen when starting the drive. A stick with it off won't boot on a PC while that PC's Secure Boot is enabled.
• Update Ventoy has the same switch, starting at whatever the drive currently has. Leave it alone and the update keeps the drive's layout. Flip it and the update converts the drive — so a stick that freezes on your Mac can be fixed without erasing its ISOs.

Mactoy does the conversion on the 32 MiB image in memory before writing it, rather than editing the partition on the stick afterwards, so there's no moment where the drive holds a half-converted EFI partition. The result matches what vtoycli partresize -s produces, file for file. Checked against the real Ventoy 1.1.17 image: fsck_msdos reports it clean, and BOOTX64.EFI read back through macOS's FAT driver is byte-identical to the original grubx64_real.efi.

Update Ventoy no longer damages MBR-style sticks

v0.3.0 treated two bytes on the disk (offsets 92 and 17908) as a "secure boot on/off" flag and rewrote them at the end of every update. They aren't a flag. They're GRUB's pointers from boot.img to core.img and from core.img's first sector to the rest of it, and Ventoy only patches them on GPT disks, where core.img lives at LBA 34 instead of LBA 1.

On a GPT stick Mactoy's misreading happened to produce the correct values. On an MBR stick it wrote 0x20 into boot.img's pointer — sending the BIOS bootloader to LBA 32 instead of LBA 1 — and 0x21 over a byte in the middle of core.img. UEFI boot uses neither, so the stick keeps working on UEFI machines and fails only on legacy-BIOS ones.

v0.4.0 writes those bytes on GPT only. Re-running Update repairs an affected stick, because boot.img and core.img are rewritten in full each time.

The same misreading is why the Update tab said "Secure boot is enabled" for every GPT stick. Detection now looks for grubx64_real.efi on the EFI partition, the way Ventoy2Disk does.

Ventoy is downloaded once, not every run (#8)

The downloader has had a SHA-256-verified cache since early on, but the app gave the helper a new randomly-named work folder on every run, so the cache never hit. Those folders were never deleted either — about 43 MB each, owned by root, sitting in your temp folder until macOS purged them.

The helper now keeps the tarball in /Library/Application Support/Mactoy/Cache/ (current version only, ~20 MB, still checked against Ventoy's published sha256.txt every time it's used), extracts to a private per-run folder, and deletes that folder when the run ends.

Sidebar: any part of a drive card is clickable (#7)

With two drives plugged in, the second one often couldn't be selected. The drive cards are SwiftUI .plain buttons, which only respond to clicks on their label's opaque content. A click-grid test on macOS 26 showed exactly that: the icon and the lines of text responded, and the rest of the card — most of it — did nothing, while still looking like one big button. The whole card is now the click target.

Also fixed while in there: clicking a drive didn't re-run Ventoy detection, so the Update tab could keep describing the previously-selected drive. (The helper re-checks the drive before writing, so this was misleading rather than dangerous.)

Smaller things

• The confirmation sheet now says whether Secure Boot support will be on or off, and that choice is locked in when you confirm — Retry after a failure uses it too, whatever the toggle shows by then.
• Mactoy checks the helper's version before sending it work. If another copy of Mactoy on your Mac owns the helper registration, you get a message saying so instead of an install done by the old helper's rules.

Install

# Download Mactoy-0.4.0.dmg from the release assets.
open Mactoy-0.4.0.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. Drop-in over v0.3.2 — no re-approval of the helper needed.

Verification

• swift build clean on Mactoy and mactoyd.
• Test suite passes, with 28 new tests covering the EFI-partition conversion (against FAT16 fixtures built with newfs_msdos), long-file-name parsing, corrupt-FAT rejection, the exact bytes Update writes on MBR vs GPT, cache and run-folder handling, sidebar selection, and confirmation capture.
• Independent code review of the diff before tagging.
• End-to-end in QEMU, using the real install/update code against disk images (harness in scripts/e2e/): sticks written with Secure Boot support on and off boot to the Ventoy menu under UEFI (OVMF) and legacy BIOS (SeaBIOS); an on → off update keeps the ISOs and boots; and the MBR bug above was reproduced with the released v0.3.2 code (BIOS boot hangs at VT_) and repaired by a v0.4.0 update (first 1 MiB byte-identical to a pristine stick, boots again).

Known limitations

• Boot testing was done in an emulator, not on physical machines. QEMU's UEFI and BIOS are spec-compliant; a particular machine's firmware may not be. If a stick written with the switch off doesn't boot where an -S stick from Ventoy2Disk does, please open an issue.
• Whether it fixes the 2011 iMac in #9 depends on that firmware, not on Mactoy: the reporter confirmed GRUB boots there when started directly, which is what the switch arranges.
• The cached tarball outlives the helper. "Uninstall the helper after this install" removes the daemon registration, not /Library/Application Support/Mactoy/. Delete that folder by hand if you're removing Mactoy entirely.

SHA256 of Mactoy-0.4.0.dmg is published below the release assets.

Mactoy v0.3.2 — enclosure quirk warnings + post-install verification + retry

Small hardening release. Four issues from the tracker landed as fixes; thanks to @dewet22 for #4 (the RTL9210B XHCI-stall writeup is exceptional) and @dmurvihill for #1 followup, #5, and #6.

What's new

Pre-flight quirky-enclosure banner (#4)

Some USB bridges are known to stall under Mactoy's sustained raw write pattern — the Realtek RTL9210 / RTL9210B in particular, on Apple silicon Macs. The stall escalates into a full XHCI controller reset, tearing down every downstream USB device including internal hubs on Mac minis. The raw fd Mactoy holds dies with the bus (ENXIO), the write fails mid-flight, and the drive is left in an indeterminate state. Root cause is bridge firmware × Apple XHCI interaction — Mactoy can't fix it, but can warn about it and suggest the known workaround.

v0.3.2 adds a QuirkyEnclosureRegistry (in MactoyKit) that matches DiskTarget.mediaName against a curated list of known-quirky bridges. Match hit → pre-flight banner appears above the danger banner in both Install Ventoy and Update Ventoy panels. Non-blocking — user can proceed if they want to. Banner spells out the symptom + the workaround (usually: force USB 2.0 to fall back to Bulk-Only Transport, which avoids the stall) + a link to the source issue for context.

Seed entry: RTL9210 / RTL9210B. PRs adding entries welcome — the registry is a public constant with a comment block explaining the criteria (specific substring, symptom description, workaround, ideally a reference issue).

Better ENXIO error message (#4)

If the write DOES fail with ENXIO despite the banner (or on a bridge we haven't listed yet), DiskWriter now surfaces a targeted message instead of the generic disk-I/O error: explains what actually happened, suggests the USB 2.0 workaround, tells the user the disk is in an incomplete state and to re-run Install Ventoy. Actionable copy in the failure banner, not a raw errno string.

"Re-check disk" button always visible (#6)

Previously the "Try again" affordance in the Update Ventoy panel only appeared when the probe FAILED. Users diagnosing post-install oddities (see #5) had no way to force a re-probe on demand. v0.3.2 adds an always-visible Re-check disk button at the bottom of the Update Ventoy panel whenever a disk is selected — pass or fail state, doesn't matter.

Post-install verification (#5)

The reporter hit a case where Mactoy's install reported success but the disk was actually not bootable — the USB stick was hardware-faulty (Ventoy2Disk on Windows failed on the same drive with a "read-back doesn't match write" error). Mactoy trusted the driver's "done" signal without verifying the write actually produced a valid Ventoy layout.

v0.3.2 fixes this: after both executeFreshInstall and executeUpdate finish their final remount, run VentoyVersionProbe.probe(bsdName:) and throw DriverError.validation if isVentoyDisk == false. The failure message names the specific layout issues and explains that this usually means a hardware fault on the USB stick, with a suggestion to try a different drive.

"Retry install" button on the failure banner (#5)

When run() ends in .failed, Mactoy now preserves the captured target/mode from the confirmation so the failure banner can offer a Retry button next to Done. Retry re-runs against the same disk without going through the confirmation sheet again. Layers 4/5/6 of the iron-clad targeting defense (v0.3.1) still verify the disk hasn't drifted at retry time, so the safety guarantee is unchanged — this is just spared clicks after a hardware-level failure.

README v0.3.0 → v0.3.1 (#1 comment)

Four references corrected: status header ("v0.3.1 alpha"), Update Ventoy feature line, install command reference DMG name, build-dmg command example.

Install

# Download Mactoy-0.3.2.dmg from the release assets.
open Mactoy-0.3.2.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. Drop-in over v0.3.1 — no re-approval of the helper needed.

Verification

• swift build -c release clean on Mactoy and mactoyd.
• 50/50 tests pass (6 new QuirkyEnclosureTests).
• Independent code review of the diff before tagging.

Known limitations

• Post-install verification is best-effort. If the probe itself flakes (transient disk unavailability right after remount), the install could be flagged as failed when the write actually succeeded. Rare; retry usually resolves it.
• Quirky-enclosure registry starts small. Only RTL9210 seeded. If your enclosure hangs the write on Apple silicon with a similar unified-log signature (see #4), please file an issue with a log show --predicate 'subsystem == "com.mactoy"' --last 1h capture and I'll add it.

SHA256 of Mactoy-0.3.2.dmg is published below the release assets.

Mactoy v0.3.1 — P0 safety release: wrong-disk wipe + Manage Disk crash

Critical safety release. A user reported in issue #1 that v0.3.0 wiped the wrong external disk: they had two USB drives plugged in, selected disk5, confirmed disk5, and Mactoy wrote disk6. Root cause analysis confirmed the bug exists in every shipped Mactoy version (v0.1.0 through v0.3.0) — those releases have all been retroactively marked as prereleases on GitHub. v0.3.1 is the first release that's safe to install.

This release also fixes a SwiftUI crash on macOS 26 (Sequoia / Tahoe) when clicking the Manage Disk tab — three users hit it on M4 Studio / MBP M4 / Air M4 hardware.

What was broken in v0.3.0 and earlier

When you clicked Install Ventoy, Mactoy showed a confirmation sheet with the disk's name and size. You clicked Confirm. Internally, Mactoy then re-read the selected disk at the moment of execution rather than using the disk you'd just confirmed.

If — between you clicking Install and clicking Confirm — the disk-enumeration poll ran (it runs every 2 seconds) AND your originally-selected disk momentarily dropped off the bus (USB-C hub re-enumerating, sleep/wake, even normal power-management churn), applyDiskList cleared the selection and snapped it to the next available disk. The install then ran on that disk, not the one you confirmed.

The reporter had a SATA SSD at disk5 (the one they wanted to flash) and a USB-C SSD at disk6 (one with personal data). Mactoy wiped disk6.

v0.3.1 — six-layer iron-clad targeting defense

Every layer must pass for any byte to hit /dev/rdisk*.

1. Confirmation captures full disk fingerprint. EraseConfirmation carries the complete DiskTarget — bsdName, sizeInBytes, mediaName, isExternal, isRemovable. Treated as authoritative from the moment you click Install onward.

2. Selection frozen during confirmation. applyDiskList refuses to mutate selectedDiskBSD while a confirmation sheet is open. The disk list still updates; the selection does not.

3. run() takes the captured target as an explicit parameter. No more re-reading selectedDisk from inside run(). confirmRun() threads the captured pair through; the helper-poll auto-resume path uses a stored pendingRunTarget to survive the helper-approval gap so the same disk is targeted on both first call and post-approval resume.

4. App-side re-verification. Right before handing the plan to the daemon, run() calls DiskInfo.probe(bsdName:) and asserts the live disk's fingerprint matches the captured one (via the new DiskTarget.fingerprintMismatch(against:) helper). Any mismatch — size, mediaName, external/removable flags, BSD name — aborts with a clear error sheet and no XPC call is made.

5. Daemon-side re-verification. VentoyDriver.executeFreshInstall, VentoyDriver.executeUpdate, and RawImageDriver.execute ALL re-probe the disk via DiskInfo.probe before opening /dev/rdisk*. The daemon is the last line of defense; it does not trust the app to have got the targeting right.

6. BSD-name guard at execution. Even if the rest of the fingerprint coincidentally matches a different physical drive that landed at the same disk<N> slot, the captured BSD name must still match the current selectedDiskBSD or run() refuses with a "selection drifted" error.

The new DiskTarget.fingerprintMismatch(against:) helper centralizes the comparison. It's covered by 8 unit tests in DiskTargetFingerprintTests.swift, including the exact "RTL9210B-CG → SSD 840 PRO Seri" scenario from the user's report.

Manage Disk crash fix

Three users in issue #1 reported crashes when clicking the Manage Disk tab — stack traces showed swift_release → swift_arrayDestroy → HVStack.updateCache SIGSEGV inside SwiftUI itself.

Root cause: ContentView wrapped every panel in a ScrollView. ManageDiskPanel contains a List. List inside ScrollView is a known SwiftUI footgun — both manage their own scroll geometry and fight each other; on macOS 26 the fight surfaces as a use-after-free in the layout cache.

v0.3.1 branches the wrapper in ContentView: Manage Disk renders without the outer ScrollView (the inner List manages its own vertical overflow). The other panels (Install Ventoy / Update Ventoy / Flash Image) keep their ScrollView wrappers — they don't contain a List.

Install

# Download Mactoy-0.3.1.dmg from the release assets.
open Mactoy-0.3.1.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. If you have any prior Mactoy version installed, please update to v0.3.1 immediately — every version before this one has the wrong-disk bug.

Verification

• swift build -c release clean for both Mactoy and mactoyd.
• Universal binary verified via lipo -info (x86_64 arm64 on both products).
• 38/38 tests pass (swift test) — 8 new fingerprint tests added.
• Independent code review of the diff before tagging.

Known limitations

• The original wrong-disk race is verified to be closed by static analysis and parser-level tests. Reproducing the exact disk-arbitration churn timing in an automated test would require a simulated DiskArbitration harness — that test rig is on the v0.4 roadmap. If you can reproduce a wrong-disk wipe on v0.3.1, please file a P0 issue immediately with log show --predicate 'subsystem == "com.mactoy"' --last 1h output.
• All releases v0.1.0 through v0.3.0 remain available as prereleases for forensics. Do not install them.

SHA256 of Mactoy-0.3.1.dmg is published below the release assets.

🚨 DO NOT INSTALL — DATA-LOSS BUG IN ALL SHIPPED VERSIONS 🚨

A user reported that v0.3.0 wiped the wrong external disk: they selected disk5, confirmed disk5, and Mactoy wrote disk6. Root cause: a TOCTOU race between the confirmation sheet capturing the target and the install actually executing — if the disk-enumeration poll runs during the confirmation window AND the originally-selected disk momentarily drops off the bus (USB-C hub hiccup, sleep/wake), selectedDiskBSD snaps to the next available disk and the install hits the wrong drive. Every version Mactoy has ever shipped has this bug.

A fix (v0.3.1) is in progress. All prior releases have been marked as prereleases. /releases/latest will return 404 until v0.3.1 ships; that's intentional — better than serving a buggy DMG.

Track progress: issue #1 and the v0.3.1 release notes.

---

(Original release notes follow.)

Mactoy v0.3.0 — Update Ventoy without losing your ISOs

The headline feature: a new Update Ventoy mode that updates an existing Ventoy install in-place to a newer Ventoy version, without erasing the user's ISOs or /ventoy/ configuration. Mactoy is the first non-official-Ventoy-team port of this in-place update flow — Ventoy2Disk.sh and Ventoy2Disk.exe have had it for years; macOS users have been stuck wiping and reinstalling.

What's new

Update Ventoy mode

Pick the Update Ventoy tab. Mactoy probes the selected disk's partition 2, parses out the currently-installed Ventoy version from /grub/grub.cfg, and adapts:

• Update available — your disk has Ventoy v1.0.99 and the latest is v1.1.05. One click to update; ISOs preserved.
• Already up to date — disk is already on the latest version. The Install Ventoy tab is still there if you want to wipe-and-reinstall.
• Damaged Ventoy install detected — partition layout looks like Ventoy but doesn't pass the full validation (e.g. interrupted earlier install). Repair via fresh install (which erases the drive).
• Not Ventoy — this disk doesn't have Ventoy on it. Use Install Ventoy.

The version dropdown carries over from Install Ventoy: you can pin a specific Ventoy version to update to, or default to "Latest" and resolve at update time. New Ventoy versions automatically work with Mactoy without an app update — the layout has been stable since Ventoy 1.0, and the parser tolerates 4-component / alphanumeric version strings (so 2.0.0-rc1 or 1.2.0.beta1 would Just Work).

How the update is safe

The on-disk update mirrors Ventoy2Disk.sh --update exactly:

1. Preserve the Ventoy disk UUID at LBA 0 byte 384 (16 bytes), the 8 reserved sectors at LBA 2040, and your secure-boot toggle (offsets 92 and 17908).
2. Rewrite MBR boot code (bytes 0–439), GRUB2 core image at LBA 34 for GPT or LBA 1 for MBR, and the entire 32 MiB VTOYEFI partition.
3. Restore the saved UUID, secure-boot bytes, and reserved sectors.

Partition 1 — where your ISOs and /ventoy/ config live — is never written. Not protected by transactional magic; protected by the fact that the update flow simply doesn't issue a write to that partition. If power dies mid-update (~5 seconds total), the bootloader is left half-written and you'll need to re-run the update — but your data is safe regardless.

Under the hood

• New VentoyVersionProbe + FAT16Reader in MactoyKit — a pure-Swift FAT16 read-only parser plus a Ventoy-specific layer that locates partition 2, validates the layout (P1 starts at sector 2048, P2 size 65536 sectors, FAT16 with VTOYEFI label), reads /grub/grub.cfg, and extracts set VENTOY_VERSION="X".
• New probeVentoy XPC method on the daemon — read-only, safe to call as the user changes their disk selection. App debounces probe RPCs at 300 ms.
• VentoyDriver.update(plan:progress:) — byte-level update flow, parallel to the existing fresh-install path. Reuses DiskWriter, VentoyDownloader, VentoyBootImages.
• VentoyOperation field on InstallPlan (.freshInstall | .updateInPlace) with backwards-compatible Codable so v0.2.x plans without the field decode as fresh installs.
• 14 new unit tests covering parseVentoyVersion, VentoyProbeResult round-trip, and InstallPlan v1→v2 migration. Build is 30/30 green.

Install

# Download Mactoy-0.3.0.dmg from the release assets.
open Mactoy-0.3.0.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. Drops in over v0.2.1 — no second Login Items / Full Disk Access round-trip needed.

Known limitations

• No transactional rollback during update. Power loss or USB unplug mid-update leaves the bootloader half-written. Recovery: re-run the update. ISOs and config are never at risk.
• No real-hardware update test. The fresh-install path has been validated end-to-end on real USB drives (since v0.1.3). The new update path has been validated by static analysis, parser unit tests, and the multi-factor disk-layout sniff that refuses to run on anything that doesn't look like a healthy Ventoy install. Real-world validation comes from user reports — please file an issue with a log show --predicate 'subsystem == "com.mactoy"' --last 1h capture if anything misbehaves.

Verification

• swift build -c release clean on Mactoy and mactoyd.
• Universal binary verified via lipo -info (x86_64 arm64 on both products).
• 30/30 tests pass (swift test).
• Independent code review of the v0.3.0 diff before tagging.

SHA256 of Mactoy-0.3.0.dmg is published below the release assets.

Mactoy v0.2.1 — hotfix for v0.2.0 memory regressions + unified logging

v0.2.0 shipped four memory and responsiveness regressions caused by the @Observable → ObservableObject migration in the macOS-13.5+/universal port. A user on a MacBook Air M4 reported runaway memory pressure during a flash that froze other apps, followed by repeated crashes after a system restart. v0.2.0 has been retroactively marked as a prerelease on GitHub while v0.2.1 ships as the new stable.

This release pins the verifiable causes of that pressure and adds os.Logger instrumentation across the launch path, helper lifecycle, install run, and daemon — so future incidents come with a usable diagnostic trail instead of "froze, then crashed."

What v0.2.0 got wrong (and v0.2.1 fixes)

1. Per-update Task { @MainActor in onUpdate } spawn during a flash

ProgressForwarder (the XPC-facing object that receives progress callbacks from mactoyd) used to spawn a fresh Task { @MainActor in onUpdate(update) } for every update. On a multi-GB image the daemon emits hundreds of updates per second; v0.2.0 created a Task per update, each one writing to two @Published properties (log.append + status = .running) and re-rendering every @EnvironmentObject subscriber.

v0.2.1 throttles to ~30 Hz: phase transitions and terminal .done / .failed updates are never dropped, only intra-phase progress ticks are coalesced. The most-recent throttled-out update is buffered and flushed when the next phase transition or terminal update arrives — so the progress bar always shows 100% before "Install complete" instead of jumping from 95% to done.

2. Unbounded AppState.log growth

v0.2.0 appended every ProgressUpdate to log: [ProgressUpdate] indefinitely with no consumer. A long install accumulated thousands of entries (each a phase + message + bytes-done + bytes-total + Date) and pinned them in memory.

v0.2.1 caps log at 500 entries via appendBoundedLog(_:). When the cap is hit we drop the oldest 25% in one shot rather than removeFirst() per append (amortizes O(n) shifts). The 500 most recent updates is plenty for triage; older entries are not load-bearing for any current view.

3. @Published thrash from poll loops

Combine's @Published fires objectWillChange on every assignment — even when the value didn't actually change. @Observable (the v0.1.x state layer) compared values automatically and skipped no-op writes; @Published does not. v0.2.0's disk-enumeration poll was reassigning identical disk lists every 2 seconds, and the helper-status poll was reassigning identical statuses every 1 second. Each assignment invalidated every view subscribed via @EnvironmentObject.

v0.2.1 equality-guards every poll-loop @Published write: applyDiskList, setLatestVentoyVersion, setAvailableVentoyVersions, refreshHelperStatus, and the helper-status loop in startHelperPoll. DiskTarget gained an Equatable conformance in MactoyKit to make the disk-list comparison cheap and exact.

Side effect of the refreshHelperStatus guard: the "Remove the helper after this install" checkbox no longer resets to its default on every status refresh. Users who manually toggle it now keep their choice across status changes — matches v0.1.x behaviour, which v0.2.0 had unintentionally regressed.

4. Force-unwraps in the file picker

pickFile() in Flash Image had four UTType(filenameExtension: "...")! force-unwraps. If CoreServices's type registry is in an unusual state on the user's machine (rare, but possible after a corrupted system update), one of these returns nil and the app traps mid-pick. v0.2.1 uses compactMap to silently drop nils and logs a warning if fewer than four lookups succeed.

Added — os.Logger instrumentation

Every Mactoy + daemon binary in v0.2.1 logs to os.Logger under subsystem com.mactoy. Categories:

• lifecycle — app launch banner, first-window setup
• appstate — helper status transitions, install run() begin / success / failure
• xpc.progress — malformed progress drops in the throttle path
• mactoyd — daemon startup, accept / reject of XPC clients, executePlan begin / success / failure, connection invalidation
• ui.picker — degraded CoreServices state on file pick

error.localizedDescription interpolations use privacy: .private so home-directory paths are redacted (<private>) when a user pastes log output into a public GitHub issue. Disk BSD names, modes, version strings, and helper-status names are .public — they're the values most useful for triage.

Capture and attach a log when reporting a bug:

log show --predicate 'subsystem == "com.mactoy"' --last 1h --info --debug > mactoy-log.txt

Documented in the README's new "Reporting bugs" section.

Install

# Download Mactoy-0.2.1.dmg from the release assets.
open Mactoy-0.2.1.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. If you already have v0.1.4 or v0.2.0 installed, v0.2.1 drops in without a second Login Items / Full Disk Access round-trip.

Verification

• swift build -c release clean on both Mactoy and mactoyd.
• lipo -info build/Mactoy.app/Contents/MacOS/{Mactoy,mactoyd} reports x86_64 arm64 on both products.
• swift test — 16/16 tests pass.
• Independent code review of the hotfix diff completed before tagging.
• Real-hardware Intel smoke test still pending — runtime validation continues via user reports.

SHA256 of Mactoy-0.2.1.dmg is published below the release assets.

⚠️ v0.2.0 has known stability issues — under investigation.

A user on M4 hardware reported runaway memory use that froze other apps, followed by repeated launch crashes after a system restart. Suspected causes are unbounded log array growth + per-update Task spawning during a flash + @Published thrash from poll loops.

A v0.2.1 hotfix is being prepared. While that ships, please use v0.1.4 (Apple Silicon + macOS 26 only).

---

(Original release notes follow.)

Mactoy v0.2.0 — Intel Macs + older macOS

v0.1.x was Tahoe-only: macOS 26.0 minimum, arm64 only. v0.2.0 is the port that makes Mactoy a real cross-Mac tool. The same Mactoy-0.2.0.dmg now runs on:

• Intel Macs — both slices in one universal binary (lipo -info reports x86_64 arm64)
• Apple Silicon — native arm64, no Rosetta
• macOS 13.5 Ventura, 14 Sonoma, 15 Sequoia, 26 Tahoe — one app, one download
• OCLP-patched hardware — nothing we do depends on T2 / Secure Enclave / Apple Intelligence

Liquid Glass stays on Tahoe. On 13.5 / 14 / 15 the glass surfaces fall back to a translucent regularMaterial card with optional tint overlay — the layout is identical, the material just isn't real glass.

Why 13.5 and not 13.0

Early Ventura (13.0 – 13.4) shipped multiple SMAppService bugs:

• register() returned success while launchd never loaded the daemon
• BTM / launchd desync survived reboots
• Operation not permitted loops on re-register after unregister

Apple fixed them by 13.5 / 14.2. We set LSMinimumSystemVersion 13.5 so Gatekeeper refuses to install on the broken versions rather than shipping and having the helper silently fail.

What changed

Architecture

• @Observable → ObservableObject + @Published. The Observation framework is macOS 14+. AppState is now a @MainActor final class AppState: ObservableObject so it works on 13.5. Every view swapped @Environment(AppState.self) + @Bindable var state = state for @EnvironmentObject var state: AppState. $state.foo bindings come for free via dynamic member lookup.
• .mactoyGlass(cornerRadius:tint:interactive:) view modifier + MactoyGlassContainer. Both live in Sources/Mactoy/Views/LiquidGlass.swift. On macOS 26 they call .glassEffect(...) / GlassEffectContainer directly; on 13.5 – 15 they render .regularMaterial inside a rounded shape (Capsule() when no radius is specified — not a 999-pt rounded rect, which doesn't actually collapse to a capsule silhouette) with an optional tint overlay and a 0.5-pt primary stroke. Twenty-one .glassEffect(...) call sites and two GlassEffectContainer { } wraps migrated.
• .onChange(of:) { _, new in } → { new in } in HelperAwaitingApprovalSheet. The two-arg form is macOS 14+; the single-arg form works since macOS 12.
• SystemSettingsStrings.loginItemsPane helper added. Returns "Login Items" on macOS 13/14, "Login Items & Extensions" on 15+. Four user-facing strings in HelperExplainerSheet, HelperAwaitingApprovalSheet, and two status = .failed(...) messages in AppState use it now — Ventura users no longer see instructions pointing at a pane name that won't exist on their system until Sequoia.

Build

• Universal binary opt-in. MACTOY_UNIVERSAL=1 ./scripts/build-app.sh release devid passes --arch arm64 --arch x86_64 through swift build to produce a fat binary in one pass. SwiftPM places the output under .build/apple/Products/Release/; --show-bin-path returns the right directory automatically. Default builds stay native-arch for local dev speed.
• Bash 3.2 safe array expansion. The array that carries --arch flags is expanded via ${ARCH_ARGS[@]+"${ARCH_ARGS[@]}"} so the script works on macOS-shipped /bin/bash 3.2 (which otherwise trips set -u on an empty "${arr[@]}").

Docs

• README badges updated: macOS badge is 13.5+ with a new "Universal (arm64 + x86_64)" badge alongside.
• Build-from-source section now correctly lists Xcode 16+ / Swift 6.0+ (Package manifest uses swift-tools-version: 6.0, which Swift 5 toolchains can't parse).
• Status section's Liquid Glass line explains the 13.5 – 15 fallback.

Install

# Download Mactoy-0.2.0.dmg from the release assets.
open Mactoy-0.2.0.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. If you already have v0.1.4 installed on Tahoe, v0.2.0 drops in without a second Login Items / Full Disk Access round-trip — the helper registration carries over.

Known limitations

• No Intel-hardware smoke test. This release's universal binary is verified static-only (file, lipo -info). Runtime behaviour on Intel Ventura / Sonoma / Sequoia is being validated via user reports from v0.2.0 onwards. If you hit an issue on Intel, please open a GitHub issue with your macOS version + Mac model.
• Fallback glass is not real glass. On 13.5 – 15 the cards use regularMaterial with a subtle tint overlay. When Reduce Transparency is on, materials fall back to flat opaque colors and the tint becomes faint — acceptable, but different from Tahoe.

Verification

SHA256 of Mactoy-0.2.0.dmg is published below the release assets.

Mactoy v0.1.4 — Flash Image + Manage Disk catch up

v0.1.3 fixed Install Ventoy to actually work end-to-end on real hardware. This release applies the same handful of disk-handling fixes to the other two tabs so Flash Image and Manage Disk don't inherit the bugs we just stamped out.

No changes to the Ventoy install path itself. If v0.1.3 worked for you, v0.1.4 will too.

What changed

Flash Image

• Raw-disk fd released before macOS re-probes. RawImageDriver now explicitly close()es the DiskWriter after fsync, then calls diskutil reloadDisk + mountDisk so the flashed image's filesystem shows up immediately instead of requiring an unplug/replug. Same fix applied to VentoyDriver in v0.1.3 — just now applied everywhere we write raw bytes.

Manage Disk

• Volume-to-disk binding. The tab no longer matches any volume named Ventoy anywhere on the system. It now confirms the /Volumes/Ventoy target's DeviceIdentifier actually sits on the currently-selected BSD disk via diskutil info. If you had two Ventoy sticks plugged in, you could previously have been editing the wrong one.
• ISO list refreshes on disk switch. .id(volumeURL) forces the list to rebuild when you pick a different disk from the sidebar, instead of showing stale items from the previous drive.
• Errors surface. Copy and delete actions used to swallow failures with try?. Both now raise an NSAlert with the underlying error text.
• Refresh button and an N ISOs on this drive header added for clarity.

Docs

• README status section is now v0.1.3 alpha with the "Verified on real hardware" line checked, and the outdated osascript references in the architecture + security sections are replaced with the XPC / SMAppService flow that actually ships.

Install

# Download Mactoy-0.1.4.dmg from the release assets.
open Mactoy-0.1.4.dmg
# Drag Mactoy.app into /Applications.

Apple-notarized. If you already have v0.1.3 installed, the helper is registered and approved — v0.1.4 drops in and runs without a second Login Items / Full Disk Access round-trip.

Verification

SHA256 of Mactoy-0.1.4.dmg is published below the release assets.

Mactoy v0.1.3 — The one that actually installs Ventoy

This is the first release that has been end-to-end verified on real hardware. Every previous release had a disk-writing bug hiding behind the macOS permission wall — once the permissions path was finally clean, the real bugs surfaced. This release fixes them.

A Ventoy install goes from click to bootable USB in about 45 seconds (30 s of that is the GitHub Releases download, which is out of our control).

What changed

Helper architecture

v0.1.2 used osascript to elevate the mactoyd binary to root, which required an admin password prompt per install and silently needed Full Disk Access granted by hand. v0.1.3 replaces that with a proper SMAppService LaunchDaemon + XPC flow:

• One-time approval via the native macOS "Background Items Added" notification. No password prompt on subsequent installs.
• The daemon auto-exits after the XPC connection closes, so every install spawns a fresh process — rebuilds and updates take effect immediately, no stale code lingering in memory.
• The daemon verifies the client's Developer ID + bundle identifier before accepting any install plan, closing security issue C2 from the internal audit.
• The app shows a pre-approval explainer sheet before triggering macOS's prompt so users know exactly what they're being asked to allow (and that the "background" label is macOS's UI choice, not a functional description — the helper only runs during installs).
• An "Uninstall helper after this run" toggle (default on) cleans the system back up after the install completes.

Full Disk Access flow

macOS TCC does not allow apps to programmatically request Full Disk Access — it has to be granted in Settings by the user. When the helper hits EPERM on /dev/rdisk*, v0.1.3 surfaces a numbered-step sheet with a one-click deep-link into the FDA pane and a "Reveal Mactoy in Finder" button so the user can drag the right bundle into the list. This happens once; after that TCC propagates the grant to mactoyd via AssociatedBundleIdentifiers.

Disk-writing path

The heart of the release.

• DiskWriter now releases its raw-disk fd after fsync, before we ask macOS to re-scan the partition table. Previously the class held /dev/rdisk* open for the remainder of VentoyDriver.execute() (via Swift's deferred deinit), and the kernel refuses to re-probe a disk that still has an open writer — so the wait loop was polling a disk its own process was blocking. This was the bug that made every previous release look like it worked but fail at the final format step.
• diskutil reloadDisk is the explicit trigger we now use to force macOS to re-read the GPT. The previous diskutil list approach only queried cached state.
• Polling tolerates up to 90 s of DiskArbitration lag before giving up, with reloadDisk retried every 10 s, and the .formatting phase emits a visible "waiting (Ns / 90s)…" update every 5 s instead of sitting silent.
• Boot-image layout accepts new-and-old Ventoy releases. Upstream moved ventoy.disk.img.xz from boot/ to ventoy/ in a recent release; the driver now checks both paths.

UI + UX

• Live download progress. The 20 MB Ventoy tarball download now ticks a real bytes-done / bytes-total bar instead of an indeterminate sweep.
• Status bubbles render as rounded rectangles, not capsules.
• No more simultaneous "Failed" + progress bar + "Working…" button. Terminal .failed / .done progress updates no longer clobber the real failure state set by the XPC reply.
• Auto-recovery for BTM/launchd desync: if the Login Items toggle is on but launchd lost its live registration (e.g. after a launchctl bootout), the app transparently re-registers and retries the install.

Security

• XPC peer-signature check in mactoyd closes C2 from the internal audit — any process without a valid Mactoy Developer ID signature is refused a connection, even if it runs as root.
• Ventoy version strings from the GitHub API are re-validated against the same regex applied to user input, so a malformed upstream tag cannot be interpolated into a download URL.

Verified on real hardware

This is the first release tested against an actual 128 GB USB drive on macOS 26.2. The resulting drive boots and runs Ventoy; the Ventoy exFAT partition accepts ISO drops; the VTOYEFI FAT32 partition contains the expected boot payload.

Install

# Download Mactoy-0.1.3.dmg from the release assets.
open Mactoy-0.1.3.dmg
# Drag Mactoy.app into /Applications.

First launch is prompt-free (Apple-notarized). On first Install click, follow the one-time helper approval flow, then the Full Disk Access flow. Neither sheet appears again on subsequent runs.

Verification

SHA256 of Mactoy-0.1.3.dmg is published below the release assets.

Mactoy v0.1.2 — Ko-fi + security hardening

What changed

Ko-fi support

• Ko-fi button in the app. Bottom-left corner of every tab's action bar, using Ko-fi's official dark-on-dark pill asset. Opens ko-fi.com/cash508287 in your default browser.
• GitHub "Sponsor" button enabled. .github/FUNDING.yml points at the same Ko-fi page.
• Ko-fi badge in the README next to the existing shields.

Security hardening

These close the highest-impact findings from an internal review of the v0.1.1 codebase.

• SHA-256 verification of the Ventoy tarball before the bytes are handed to the privileged helper. The expected hash is pulled from sha256.txt published alongside each Ventoy release, so corrupted downloads, middlebox rewrites, and cached-but-stale tarballs all abort the install cleanly. Same-origin assumption (Ventoy's own GitHub account) is documented as a known limitation in SECURITY.md.
• Whole-disk name regex. InstallPlan.validate now rejects anything that isn't ^disk[0-9]+$ — slice names (disk2s1), path-traversal (../disk2), and nonsense (diskfoo) can no longer reach /dev/rdisk*.
• Raw-image driver re-probes the disk in the helper. RawImageDriver no longer trusts the isExternal/isRemovable flags set in the plan; it re-runs diskutil info inside the privileged helper and refuses internal disks there, matching what the Ventoy driver already did.
• Version-string allowlist. Ventoy version strings are now matched against [0-9]+(\.[0-9]+){1,3} before they are interpolated into the GitHub download URL. ../ / newlines / && / query strings in a spoofed version are rejected before URL construction.
• Tar extraction uses --no-same-owner --no-same-permissions, and happens only after SHA-256 verification — combined defense against zip-slip and root-owned extracts.
• Pinned minimal environment (PATH, LC_ALL, LANG) when spawning diskutil / tar / newfs_exfat from the helper.
• Dropped the unused com.apple.security.automation.apple-events entitlement. The admin prompt uses /usr/bin/osascript as a local exec, which doesn't need it.
• 5 new tests covering the validation paths above; total swift test is 16/16.

Docs

• New SECURITY.md with Mactoy's threat model and what the alpha does not yet defend against — most notably the unauthenticated-root-helper issue, which is targeted for v0.2 (SMAppService migration).

Not changed

No disk-layout math changed. The existing 12 GPT/MBR/layout unit tests still pass bit-identical against the Python reference implementation.

Install

# Download Mactoy-0.1.2.dmg from the release assets.
open Mactoy-0.1.2.dmg
# Drag Mactoy.app into /Applications.

No Gatekeeper right-click workaround — the DMG is Apple-notarized.

Verification

SHA256 of Mactoy-0.1.2.dmg is published below the release assets. Compare against shasum -a 256 Mactoy-0.1.2.dmg locally before running.

Mactoy v0.1.1 — UI polish

Second alpha. No disk-writing logic changed — this release is cosmetic + information-architecture fixes on top of v0.1.0.

What changed

• App icon. Mactoy now ships with a real icon — USB stick on a silver-bezeled squircle — rendered in the Dock, Finder, and Get Info. Previous build shipped the default placeholder.
• Info panels no longer pill-stretched. The "What this does" blocks on every tab were rendering as capsules because .glassEffect(.regular) defaults to Capsule shape. Explicit in: .rect(cornerRadius: 16) everywhere now.
• Red warning on Flash Image. A red-tinted Liquid Glass banner now appears above the drop zone: "This creates bootable media from a single image. If you want to boot multiple ISOs from one drive, use the Install Ventoy tab, then drop your ISOs onto the Ventoy volume." Prevents the common mistake of dd-ing an ISO when the user actually wants a Ventoy multi-boot stick.
• Version picker is a real dropdown. Previously a free-form text field. Now a Picker that fetches the last 20 stable Ventoy releases from the GitHub API on launch and lists them under a Latest default. A Custom… option reveals a text field so users can still pin an exact tag if Mactoy ever stops updating.
• README rewritten. Now leads with a Why Mactoy exists section — Ventoy has no macOS installer, the official workarounds (LiveCD + second USB, Linux VM, dual-boot) all need another machine before the five-minute task starts, the native Python gist needs Homebrew xz + sudo + raw device paths, balenaEtcher only covers single-boot sticks, and the MAS sandbox rules out a polished App Store option. Explains why this gap exists and why the project fills it.

Not changed

• GPT layout, boot-image writing, exFAT formatting, raw dd flashing, .xz/.gz decompression, disk enumeration, privileged helper handoff. All byte-for-byte the same as v0.1.0 — the unit tests still pass bit-identical against the Python reference.

Known limitations (unchanged from v0.1.0)

• macOS 26 (Tahoe) or newer.
• Not yet verified on real hardware by the author. First-party hardware confirmation is the top priority for v0.1.2.
• No cancel button mid-operation.
• Raw-image flashing loads the whole image into memory.
• Privileged helper is invoked via osascript admin prompt; SMAppService daemon is planned for v0.2.

Install

# Download Mactoy-0.1.1.dmg from the release assets.
open Mactoy-0.1.1.dmg
# Drag Mactoy.app into /Applications.

No Gatekeeper right-click workaround — the DMG is Apple-notarized, so first launch opens normally.

Verification

SHA256 of Mactoy-0.1.1.dmg is published below the release assets. Compare against the hash shown by shasum -a 256 Mactoy-0.1.1.dmg locally before running.

Mactoy v0.1.0 — alpha

First public release. Mactoy is a native SwiftUI app for macOS 26+ that installs Ventoy onto a USB drive (or flashes any raw image) without needing a Linux VM or booting the Ventoy LiveCD.

What works

• Install Ventoy — downloads the latest (or pinned) Ventoy release from GitHub, wipes the selected external USB drive, writes a Ventoy-compatible GPT + protective MBR + boot images, formats the data partition as exFAT.
• Flash raw image — drag an .iso, .img, .img.xz, or .img.gz and write it to a USB drive with a progress bar.
• Manage existing Ventoy drive — list / add / remove ISO files on a mounted Ventoy volume.
• Liquid Glass UI — sidebar disk picker, mode tabs, action bar all use macOS 26's new glass material.

What's cross-validated

The GPT layout math is a direct port of the Python proof-of-concept that successfully flashed a Ventoy drive on this machine. Unit tests confirm that for the same disk size, Swift produces bit-identical partition boundaries, CRCs, GUIDs, and boot-sector patches as the Python reference:

✔ 124GB stick matches Python reference
✔ basic data GUID matches GPT wire format
✔ Ventoy partition entry is 128 bytes and starts with type GUID
✔ header is 512 bytes, starts with EFI PART, has valid CRC
✔ signature + protective partition type
✔ part2 starts on 8-sector boundary (across 4000 disk sizes)
✔ CRC32 known vectors

12/12 tests pass.

Signing status

• Signed: Developer ID Application "Clayton Conway (MUQ3H79Y4N)" with hardened runtime.
• Notarized: yes — submission 8fed8b49-fe5a-4138-b359-baf527fb520b, accepted by Apple's notary service. Ticket stapled to the DMG.
• Gatekeeper: spctl --assess reports accepted, source=Notarized Developer ID. No right-click workaround required — first launch opens normally.

What's NOT yet shipped (on the v0.2 roadmap)

• Apple notarization (see Signing status above).
• SMAppService privileged helper daemon. v0.1 uses osascript admin prompts — one auth per install. Functional, just not as slick as a persistent daemon.
• Homebrew cask. Coming with v0.2 once the build is signed + notarized.
• Real-hardware confirmation by maintainer. The code that does the writing is a line-by-line port of a Python script we tested on a 124 GB USB and successfully booted. The Swift port is verified by cross-validation tests. First-party hardware sign-off happens in v0.1.1.

Install

# Download Mactoy-0.1.0.dmg from the release assets.
# Open the DMG, drag Mactoy.app to Applications.
xattr -cr /Applications/Mactoy.app
open /Applications/Mactoy.app

Known limitations

• macOS 26+ only. Liquid Glass APIs require this. No fallback to older macOS in v0.1.
• NTFS format not implemented. Only exFAT for the Ventoy data partition.
• No cancel button. Progress bar updates mid-install, but there's no "abort" action yet.
• Raw-flash is not streaming. Entire image is loaded into memory before write starts; for very large images (say, macOS installer sizes), use dd directly in v0.1.

Credits

• VladimirMakaev's gist — the Python proof-of-concept this is built on.
• Ventoy — the bootloader that makes this useful.
• SWCompression — pure-Swift xz/gzip.

Contribute

PRs welcome. Open an issue first for anything substantial. MIT license.

---

SHA256 of Mactoy-0.1.0.dmg is published below the release assets.