Skip to content

Releases: jjones9527/macwinlink-releases

Mac Winlink v1.0.0 Beta 26

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 21 Jul 10:52

Mac Winlink v1.0.0 Beta 26

Download: MacWinlink_2026-07-21_5be4672.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

Beta26 is the sixth patch cut in the current beta series. Four fixes surfaced by beta25 field reports, focused on Helper-side visibility and rig recognition:

  • Flex 8000-series (8400 / 8600 / 8800) is now properly recognized as a network radio. Two Flex operators on QRZ landed on the same wall in the same week: the "Direct CAT" flow offered a serial-port picker for their network-only radios, so they had to pick /dev/cu.Bluetooth-Incoming-Port in desperation, and CAT timed out (correctly — the radio doesn't listen there). MacWinlink now recognizes 8000-series models the same way it recognizes 6000-series: TCP on port 4992, SmartSDR CAT bridge. Distinct "8000-series" entry now appears in the model picker. Tracked as ARSFI/MacWinlink#283.

  • Helper Direwolf audio picker is now a proper CoreAudio device dropdown (releases#14ARSFI/MacWinlink#284). The old picker offered only "System Default" and "Custom + type a device name" — the free-text field led one beta tester to type a serial port path (Direwolf tried to open it as audio and died silently with no log). Fix mirrors the ARDOP-side pattern from beta24: enumerate CoreAudio input devices, tag by stable per-instance UID, disambiguate duplicate-named devices by manufacturer. One-shot migration handles pre-beta26 configs — if the stored name unambiguously matches an enumerated device, the UID is populated automatically.

  • Helper Direwolf detail view now shows the runtime process log (ARSFI/MacWinlink#285). Same beta tester (releases#14) surfaced the second gap: "I did look for your Helper files, but unlike the VARA ones, there is no log to copy." Accurate. The Helper captured Direwolf's stdout/stderr in memory (same buffer VARA HF, VARA FM, and rigctld already display) but the Direwolf detail view didn't surface it. When Direwolf refused to start (missing callsign, port conflict, unresolvable audio device, etc.), the specific error was invisible. Now displayed inline via the same LogViewer panel the other services use.

  • New troubleshooting documentation for the VARA FM Flex-audio crash (ARSFI/MacWinlink#64). Flex 8400 users have hit a VARA FM crash on start dating back to April; four of the underlying mitigations shipped earlier this cycle (DirectSound registry defaults, VARA launch device healing, audio debug mode toggle, Wine prefix CoreAudio config). The remaining piece is a documented workaround for the fundamental Wine/DAX limitation: route SmartSDR's DAX Audio channels through BlackHole 2ch so Wine sees the audio as a native CoreAudio device instead of a Windows-only virtual driver. New TROUBLESHOOTING entry with the full recipe ships bundled in the app under Help → Documentation → Troubleshooting. Two regression tests locking in the anti-crash invariants of the device-healing pass.

Diagnostic outcome — no new decoder bug

Beta25 tester K8MRD had been reporting "Expected SOH, got D6" errors on VARA HF sessions with a specific inbound message (MID SPYDWJPCJD3X). We initially framed this as a possible poison-message decoder bug and opened ARSFI/MacWinlink#282 to investigate. K8MRD ran a diagnostic Telnet A/B test in beta25: Telnet succeeded cleanly, and the "cursed" message eventually downloaded fine on a later VARA HF session. The pattern turned out to be VARA HF handing us framing-corrupt bytes under marginal RF conditions on whatever message was in the receive slot at the time — not a decoder bug, and not a specific-message problem. Issue reframed and closed; the underlying "make our decoder more forgiving of single-byte framing errors" work is now V1.1 roadmap.

What's unchanged

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

Test suite: 2,133 main-app + 253 Helper = 2,386 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 beta26 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: 033ae3fda9b6f93b718012046424cd526b220baba4782157f7bea9e33e79c8b2

You can verify with shasum -a 256 MacWinlink_2026-07-21_5be4672.dmg after downloading.

Mac Winlink v1.0.0 Beta 25

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 20 Jul 11: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.vbDate: 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.

Mac Winlink v1.0.0 Beta 24

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 16 Jul 21:57

Mac Winlink v1.0.0 Beta 24

Download: MacWinlink_2026-07-16_ff9a86f.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

Beta24 is the fourth safety-and-polish patch cut in the current cycle. Two focused fixes from beta-tester reports plus one troubleshooting-doc entry:

  • Gateway browser auto-tune sent plain USB / FM instead of DATA-USB / DATA-FM. When you clicked a gateway row in the browser, MacWinlink helpfully tuned your radio to the gateway's dial frequency — but for HF transports (VARA HF, ARDOP) it was asking the radio for plain USB instead of the digital data mode (DATA-USB / USB-D / DIGI depending on your radio's labels). For radios that honour CAT literally (QRP Labs QMX via Hamlib was the reported case), every gateway click kicked you out of DIGI and you had to switch it back by hand. For radios with sticky DATA-mode memory (Icom 7600, others) the bug was masked by radio-side behaviour, which is why it took a QMX tester's detailed report to surface. Fixed via a new TransportMode.digitalRadioMode single-source-of-truth, backed by six regression tests that iterate every transport and refuse to let a future change flip the behaviour back. See commit 6ff9c10 for detail. Reported by a QMX operator on QRZ.com.

  • ARDOP audio device picker showed two checkmarks for duplicate-named devices. If your Mac had two audio devices sharing the same friendly name — the common case being two Burr-Brown PCM2900-family USB radio interfaces both reporting as "USB Audio CODEC" — SwiftUI's picker flagged both entries as selected, showing two checkmarks in the dropdown. Worse, the stored selection was the name string, so ardopcf at session launch got an ambiguous identifier and picked whichever of the two devices CoreAudio returned first — with no way for the user to know it went wrong. Fixed by capturing kAudioDevicePropertyDeviceUID on enumeration (stable per-instance identifier), tagging picker items by UID, storing the UID rather than the name, and appending the manufacturer inline for disambiguation when needed ("USB Audio CODEC — Burr-Brown"). Includes a silent one-shot migration from legacy name-based storage. Nine new regression tests. Tracked as ARSFI/MacWinlink#275.

  • New TROUBLESHOOTING entry: "VARA Reacts to Room Sounds / Wrong Audio Device (macOS Tahoe)." Captures the recipe for a Wine-under-Tahoe CoreAudio state-drift issue that can make VARA appear to be listening to the wrong microphone even when its own SoundCard dialog shows the correct device selected. Not a MacWinlink bug — Wine's winecoreaudio.drv doesn't gracefully recover when CoreAudio state drifts, which Tahoe apparently does more aggressively than prior macOS versions. Recipe: sudo killall coreaudiod (possibly several times), force the device to 44.1 kHz in Audio MIDI Setup, reselect the device in VARA's SoundCard dialog. Guide entry is bundled and reachable from Help → Documentation… (⌘⇧?). Credit to @kg6nlw for the diagnostic work at releases#4.

V1.1 roadmap additions

Two beta-tester feature requests were reviewed and added to the V1.1 roadmap (not scheduled for the current beta cycle):

  • #8 — busy-channel detect for ARDOP. VARA already has this since beta19; ARDOP is the remaining gap.
  • #9 — sequential "best channel" auto-connect on manual Open Session. The engine (AutoConnectService) already ships and is used by scheduled auto-poll — this exposes it in the manual flow.

Detail in ROADMAP_V1.0_PLUS.md.

What's unchanged

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

Test suite: 2,110 main-app + 238 Helper = 2,348 total, 0 real failures. One integration test flaked once in the full-suite run (SIDHandlerResponderGreetingTests, mock-server timing) and passes cleanly in isolation — tracked separately.

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 beta24 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: a6d451f4c5a49a2114791448b668879f8d6233399d1051d90cc5a5d8eacc135a

You can verify with shasum -a 256 MacWinlink_2026-07-16_ff9a86f.dmg after downloading.

Mac Winlink v1.0.0 Beta 23

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 16 Jul 01:37

Mac Winlink v1.0.0 Beta 23

Download: MacWinlink_2026-07-15_f05591a.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.

What's in this build

Beta23 is the third safety-focused patch cut in a row. Two independent data-integrity fixes from beta-tester reports:

  • Silent inbound data loss on mid-batch VARA HF failure (reported at #5 by @K8MRD on an IC-7300MK2). When a VARA HF session accepted multiple inbound proposals and a later message hit a protocol violation (e.g. Expected SOH, got D6 on a degraded RF link), MacWinlink was discarding every message that had already downloaded successfully in the same batch. Session summaries read Messages Received: 0 even when the first messages had arrived intact. Fixed by restructuring the download loop to commit each decode incrementally, so any later throw leaves earlier successes intact for the existing partialSessionResult recovery path to surface. You'll now see partial-session summaries like "Received 2 (of 4 attempted)" instead of a phantom 0. If you use VARA HF over marginal RF paths, please upgrade. Tracked as ARSFI/MacWinlink#273.

  • Duplicate [Soundcard] sections in VARA.ini stealing audio device selection (reported at #4 by @kg6nlw on an iMac + FT-710). The Helper's VARAConfigManager was splitting on "\n" and trimming with .whitespaces (which does not include \r). On a CRLF-authored VARA.ini — the common case, because VARA itself writes CRLF under Wine — retained \r on each token made the section-header match fail and the upsert then appended a duplicate [Soundcard] block at end-of-file. VARA silently honours the duplicate with last-write-wins, so users saw their audio device selections "stuck" on stale values from earlier sessions (in the reported case, VARA was actually listening to the iMac's built-in mic even though the UI had a USB radio audio device selected). Fixed with CRLF-safe INI handling plus a one-shot dedupeSections repair pass that consolidates any pre-existing duplicate blocks on first launch — no manual VARA.ini editing needed. Tracked as ARSFI/MacWinlink#274.

What's unchanged

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

Test suite: 2,096 main-app tests, 238 Helper tests, 0 failures (+11 new tests covering the two fixes).

System requirements

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

Full changelog

The complete beta23 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: 94fd73551929bfeb6f6312e453a3d29a7b39866af456fdc28a671aaeccf09eb1

You can verify with shasum -a 256 MacWinlink_2026-07-15_f05591a.dmg after downloading.

Mac Winlink v1.0.0 Beta 22

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 15 Jul 11:42

Mac Winlink v1.0.0 Beta 22

Download: MacWinlink_2026-07-15_7c4fb52.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.

What's in this build

Beta22 is a safety-focused patch cut. Two headline changes:

  • Yaesu / Kenwood CAT safety fixes — SwiftRigControl bumped from 1.1.1 to 1.1.2, a seven-vendor Hamlib parity audit. Several safety-critical CAT protocol bugs closed, including a Kenwood one where setPTT(false) was actually keying the radio and a Yaesu FT-DX10 stop-bits mismatch that could occasionally read as a stray TX1; command and briefly key the radio. If you're on Yaesu HF (FT-DX10, FT-DX101, FT-991A, FT-891, FT-450D, FT-950, FT-2000, FT-DX3000/5000, and earlier models) or Kenwood desktop rigs (TS-590, TS-990S), please upgrade. Downstream: #3, upstream: SwiftRigControl v1.1.2.
  • Help menu is finally functional — the previous User Manual and Quick Start Guide items silently did nothing (markdown files were never bundled). Now every user-facing guide is bundled with the app and reachable via Help → Documentation… (⌘⇧?). Six guides included: Quick Start, User Manual, VARA Setup, Gateway Discovery, P2P Connections, Troubleshooting. All render offline — no network needed, which matters for EMCOMM use.

What's unchanged

Everything else in beta21 is unchanged. No functionality removed; no protocol changes; no UI restructuring. Test suite unchanged: 1,965 main-app tests, 227 Helper tests, 0 failures.

System requirements

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

Full changelog

The complete beta22 release notes are in ARSFI/MacWinlink CHANGELOG.md. No Helper-side code changes this cut — Helper version bumps to keep pairing parity.

Reporting problems

File a bug report or feature request.

Verification

SHA-256 of the DMG: 42077a86e4ff42fb3be0ee0f66d161a5c7a60932fbea56858ee77ba91c655cd2

You can verify with shasum -a 256 MacWinlink_2026-07-15_7c4fb52.dmg after downloading.

Mac Winlink v1.0.0 Beta 21

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 10 Jul 22:11

Mac Winlink v1.0.0 Beta 21

Download: MacWinlink_2026-07-10_080ade1.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.

⚠️ Safety-driven beta — Yaesu owners please read

Beta21 is a single-purpose safety cut driven by issue #3 (thank you, @deltabrav0): opening the CAT serial port to a Yaesu FT-DX10 keyed the radio into transmit and held it there until the USB cable was physically unplugged.

This affects any Yaesu HF radio whose CAT USB port uses RTS or DTR as the PTT signal — a very broad family including FT-DX10, FT-DX101, FT-991A, FT-891, FT-450D, FT-950, FT-2000, and FT-DX3000/5000, plus many earlier Yaesu HF radios. If you were previously using Direct CAT with a Yaesu radio and hit stuck-key behaviour, please upgrade.

What's fixed

  • Yaesu radios keyed into TX on Direct CAT port open — root cause was in the underlying SwiftRigControl library: IOKitSerialPort.open() never explicitly de-asserted the DTR / RTS modem control lines after opening the file descriptor. macOS leaves DTR asserted after open(2) by default; CP210x USB-UART drivers honor that; Yaesu radios interpret it as PTT.

    Fixed upstream in SwiftRigControl v1.1.1 by issuing ioctl(fd, TIOCMBIC, TIOCM_DTR | TIOCM_RTS) after tcsetattr succeeds — driving both lines low so the radio does not key on open. RTS is preserved when hardware flow control is enabled. Beta21 pins SwiftRigControl 1.1.1, no other MacWinlink source change was required.

Nothing else changed

Beta21 is a single-fix cut. No other features, no other fixes, no protocol changes. If you weren't affected by the Yaesu PTT bug, upgrading is optional but harmless — everything else in beta20 is unchanged.

System requirements

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

Full changelog

The complete beta21 release notes are in ARSFI/MacWinlink CHANGELOG.md. No Helper-side code changes — the Helper version bumps to keep pairing parity.

Reporting problems

File a bug report or feature request.

Verification

SHA-256 of the DMG: ca7746a502051d28641de76e3b9f1718ee56568bc4be614c2f5cd33eb0cd59e6

You can verify with shasum -a 256 MacWinlink_2026-07-10_080ade1.dmg after downloading.

Mac Winlink v1.0.0 Beta 20

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 09 Jul 11:22

Mac Winlink v1.0.0 Beta 20

Download: MacWinlink_2026-07-09_46a1d1d.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.

What's in this build

A short beta driven by the two public-beta reports on beta19. Both are fixed:

  • #1 — FlexRadio support in Radio Settings. FlexRadio is now a first-class manufacturer with three model choices: Flex 6000-series (6300/6400/6500/6600/6700), PowerSDR, and Thetis. When you pick the 6000-series, Radio Settings shows a Host / Port section (defaulting to localhost:4992 for SmartSDR) instead of a serial port. PowerSDR and Thetis stay on the virtual-serial path. All three use the Kenwood CAT dialect; the editor calls the Flex path out as beta / unverified because we haven't been able to validate against real hardware yet.
  • #2 — Template / Contact / Message import fixed. On the sandboxed release build, .fileImporter and the Open panel handed back "security-scoped" URLs that MacWinlink was reading without activating the scope, so macOS returned the "you don't have permission to view this file" error — even though the app's entitlements were correct. Fixed by wrapping every importer read through a single helper (URL.readSecurityScoped()) that opens the scope, reads, and closes it. Applied to Template import, Contact import, and both message/contact imports on the main menu.

Also improved

  • Load Default Templates button now tells you what happened — "Loaded N default template(s)" on a fresh install, or a clear "already present" message if templates exist. Previously it silently succeeded even when it did nothing.

System requirements

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

Full changelog

The complete beta20 release notes are in ARSFI/MacWinlink CHANGELOG.md. No Helper-side code changes this cut — the Helper version bumps to keep pairing parity.

Reporting problems

File a bug report or feature request.

Verification

SHA-256 of the DMG: 15ea58064aff383d428810b01209e11928812cab13f44397059aa63363ec700a

You can verify with shasum -a 256 MacWinlink_2026-07-09_46a1d1d.dmg after downloading.

Mac Winlink v1.0.0 Beta 19

Pre-release

Choose a tag to compare

@jjones9527 jjones9527 released this 07 Jul 11:10

Mac Winlink v1.0.0 Beta 19

Download: MacWinlink_2026-07-06_5ef2bab.dmg (17.9 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.

What's in this build

A week of OTA-driven fixes across radio configuration, error messaging, session UX, and serial-port lifecycle. Highlights:

  • Per-transport radio picker restored. Assign a specific radio to each transport (VARA HF, VARA FM, ARDOP, Packet) independently of your active default. With a caption warning when your selection overrides the default.
  • Rig Control status "sticks" to the real state. Test Connection success no longer leaves the Rig Control section showing red.
  • VARA error messages tell you what actually happened. "Channel busy" no longer misclassifies gateway-off-air failures; mid-session drops now say "Radio link lost mid-session — VARA disconnected before the exchange completed" instead of the generic "Link dropped while reading line."
  • Kenwood TNC packet — Stop button responds within 1 second instead of hanging for ~45 seconds after a mid-dial cancel. Faster TNC init before the first transmission.
  • Session window defaults to log view. See the full connection sequence (SID exchange, credentials, proposals, transfers) live during your session instead of the map with a hidden log.
  • VARA welcome banner (gateway-dependent) rendered with a distinctive tint when the gateway sends one.
  • VARA FM first-attempt "Connection refused" fixed. Helper now waits 750 ms after VARA reports ready so the main app doesn't race the modem's socket setup.

System requirements

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

Full changelog

The complete beta19 release notes with all 13 PRs are in ARSFI/MacWinlink CHANGELOG.md. Helper-side changes in CHANGELOG-Helper.md.

Reporting problems

File a bug report or feature request.

Verification

SHA-256 of the DMG: 471c63ff65ede8b8734f4d81b8b97203528a3a2c2ba01b8906fdebbc45f72a6b

You can verify with shasum -a 256 MacWinlink_2026-07-06_5ef2bab.dmg after downloading.