Mac Winlink v1.0.0 Beta 25

Mac Winlink v1.0.0 Beta 25

Download: MacWinlink_2026-07-20_298be40.dmg (17 MB) — see Assets below.

First-time install? Read the Gatekeeper bypass instructions — since macOS Sequoia, Control-click-to-open no longer works and you'll need to go through System Settings → Privacy & Security → Open Anyway. If ARDOP throws an "access denied" error on first session start, that's a separate quarantine flag on the bundled ardopcf binary — the fastest fix is to run xattr -dr com.apple.quarantine /Applications/MacWinlink.app in Terminal after installing.

What's in this build

Beta25 is the fifth safety-and-polish patch cut in the current beta cycle. Five substantive bug fixes covering position reporting, message list refresh, main-window behavior on Tahoe, session summary accuracy, and VARA FM install completeness — all from beta-tester reports over the last four days.

• Position reports were being silently rejected by CMS (releases#10). MacWinlink was emitting Speed: 1.0 km/h (CMS wants a bare number) and no Date: line in the body at all (CMS requires it independent of the message header). Fixed by cross-checking every field format against canonical Winlink Express PositionReport.vb and CMS InboundRecords.vb — Date: now emitted in UTC, Speed: bare, Course: bare int + T for True bearing, Altitude: dropped entirely for parity. Tracked as ARSFI/MacWinlink#277.

• Clicking a Smart Folder in the sidebar didn't refresh the message list (releases#11). The count badge was correct (filter math ran) but the visible list didn't recompute — a missing .onChange(of: smartFolder) handler in the filter pipeline. Two-line fix plus a Mirror-based regression test that pins the invariant so a future author adding a filter input without wiring .onChange fails the build. Tracked as ARSFI/MacWinlink#278.

• Two identical main windows opened on cold launch after red-X close-and-reopen on macOS Tahoe (releases#12). Root-caused via log stream capture to a race between SwiftUI's WindowGroup restoration (which Tahoe handles natively) and our own AppDelegate.applicationShouldHandleReopen also calling openWindow(id: "main"). Both fired 166 ms apart; SwiftUI didn't dedupe. Removed the explicit openWindow call; SwiftUI now owns the reopen path exclusively. Verified with a fresh log capture across three close-reopen cycles. Tracked as ARSFI/MacWinlink#279.

• Session summary reported "Messages Received: 0" even when messages had actually downloaded (releases#15, releases#17). The #273 partial-result fix from beta23 correctly saved messages that downloaded before a mid-batch protocol failure, but the trailing summary line still reported 0-received because SessionProgressTracker.totalReceived was only updated on the clean session-end path. Users saw "Messages Received: 0" and reasonably concluded nothing arrived — even when 5 messages had landed in their inbox. Fixed by routing authoritative counts from the session result or partial-result arrays through to the summary emission. Tracked as ARSFI/MacWinlink#281.

• VARA FM refused to start on fresh install because VARAFMNarrow.dat was missing (releases#13). Diagnosed via innoextract --list on the VARA FM installer: the file IS bundled and should be placed unconditionally, but our install-monitoring task killed wineserver 15 seconds after VARAFM.exe appeared — not enough time for the subsequent 5.5 MB of .dat writes on a slow disk / busy Wine. Killed mid-write, file was left partial or missing. Fix: the installer now polls for every expected data file (VARAFMNarrow.dat, VARAFMWide.dat for FM; Data.dat, VARAHF500.dat, VARAHF2300.dat, VARAHF2750.dat for HF) before killing wineserver. Same latent race is now closed on VARA HF too. Explicit post-install validation throws with a specific list of what's missing if anything doesn't land. Tracked as ARSFI/MacWinlink#280.

V1.1 roadmap tracking

Three open beta-tester items are tracked on the V1.1 roadmap rather than fixed in this beta:

• releases#8 — busy-channel detect for ARDOP (VARA already has it since beta19).
• releases#9 — sequential "best channel" auto-connect on manual Open Session.
• releases#16 — FT-891 slow rig-control response, awaiting more diagnostic data.

Beta-tester releases#17 also surfaced a protocol-decoder bug on a specific inbound message (MID SPYDWJPCJD3X) that kills sessions on multiple radios with Expected SOH, got D6. Diagnosis requires the raw bytes; tracked as ARSFI/MacWinlink#282 — not in this beta but next up.

What's unchanged

Everything else in beta24 is unchanged. No functionality removed; no protocol changes; no UI restructuring. SwiftRigControl 1.1.2 remains pinned.

Test suite: 2,127 main-app + 241 Helper = 2,368 total, 0 failures.

System requirements

• macOS 15.0 (Sequoia) or later
• Apple Silicon Mac (M1 / M2 / M3 / M4 / M5)
• Intel Macs are not supported

Full changelog

The complete beta25 release notes are in ARSFI/MacWinlink CHANGELOG.md and CHANGELOG-Helper.md.

Reporting problems

File a bug report or feature request.

Verification

SHA-256 of the DMG: c60d7eef1fa616323eadf8dc0e98917d1a1e9a9c71060571a1648ab339fa3bf2

You can verify with shasum -a 256 MacWinlink_2026-07-20_298be40.dmg after downloading.