The Short Version
SwiftMac is a native speech server for Emacspeak on modern Macs. It turns Emacspeak's text protocol into responsive speech, tones, and audio icons through Apple's speech and audio APIs.
The important part is not just that it speaks text. SwiftMac is working accessibility infrastructure used in real development workflow. It handles voice changes, speech queues, audio icons, tones, volume control, and multi-device routing without pushing the complexity into a cloud service or a separate desktop application.
The Problem
Blind developers need low-latency, semantic audio feedback from the tools they live in all day.
Emacspeak turns Emacs into an audio desktop. A speech server is the bridge between Emacspeak's protocol and the operating system's speech stack. If that bridge is slow, brittle, or missing semantic audio detail, the whole development environment feels slow.
Technical work also needs more than plain speech. Code, comments, links, prompts, errors, and emphasis need different voices or audio cues. A useful server has to switch voices inside a line, stop immediately, queue and dispatch speech correctly, and keep tones and sound effects from fighting with spoken output.
| Workflow need | SwiftMac behavior |
|---|---|
| Fast command feedback | Async command handling over stdin |
| Semantic text output | Voice, pitch, rate, and punctuation controls |
| Non-speech cues | Audio icons, tones, and sound-effect volume controls |
| Complex audio setups | Separate routing for speech, notifications, tones, and effects |
| Daily reliability | Simple install path, compile-time dependencies, and direct Emacspeak integration |
What We Built
A small native system around speech primitives, not a giant accessibility platform.
SwiftMac keeps the server deliberately narrow. Emacspeak and Emacs Lisp keep the higher-level decisions. SwiftMac provides the primitives: queue speech, dispatch, stop, speak a letter, play audio icons, generate tones, change voice, change rate, change punctuation behavior, and route output.
That split matters. It keeps the system debuggable and lets the user configure meaning close to the editor, while the native Swift process focuses on fast audio behavior.
Native Speech
Uses macOS speech synthesis directly for responsive local output on Apple Silicon Macs.
Audio Routing
Routes speech, notifications, tones, and sound effects to different devices or channels.
Voice Semantics
Exposes voice, pitch, rate, and volume controls so code and rich text can sound different.
Why It Matters
This is the same engineering posture we bring to client systems: build from real use, keep control local, and make the boundary explicit.
SwiftMac is a Labs project, but it is not a toy. It is a working piece of developer infrastructure shaped by daily use. That is why it is useful proof for Intelligrit: the requirements were not invented in a planning meeting. They came from the lived experience of using the system all day.
The design also shows a pattern that applies outside accessibility. When a workflow depends on a fragile interface, build a focused adapter. Keep the protocol simple. Keep configuration close to the user. Avoid hidden runtime dependencies. Make the thing usable by default.