Voqora: A Native Mac App for Turning Reading Into Listening
Most information work still assumes that your eyes should do all the work.
That is fine until it is not. You have a long article open between meetings. A dense paper needs one more pass. You are rewriting something important and want to hear whether it actually sounds clear. A PDF needs to come with you when you leave the desk. The text is already there, but the useful moment to read it is not always the moment you can stare at a screen.
Voqora is a native macOS app that turns the text you are already reading into speech. Select text, press a shortcut, and listen. For longer material, add a document and turn it into a resumable audiobook.
It is not a web demo, a browser extension, or an account funnel pretending to be a utility. It is a Mac app built around one practical transition: from reading to listening, without losing your place or your momentum.
Visit Voqora on GitHub View Voqora releases
Voqora in one minute
There are two core ways to use it.
| If you need to… | Voqora lets you… |
|---|---|
| Get through a paragraph, article, email, brief, or draft | Select it in the app you are already using and have it read aloud. |
| Keep moving through a long document | Add it as an audiobook, listen in pieces, and resume later. |
| Review your own writing | Hear the exact words back before sending them. |
| Keep a useful clip | Export the latest spoken selection as a WAV file. |
The normal selected-text flow is deliberately short:
No copying text into another tab. No opening a dashboard. No account required to make the app speak.
Architecture: one Mac, one local speech path
The product has a deliberately small shape. Voqora is a native SwiftUI macOS app. A bundled local speech server does the neural synthesis. Native audio playback receives a WAV stream as it is generated. The app owns the state that matters to a reading workflow: the current playback session, local history, audiobook progress, preferences, and the narrow first-use permission path.
| Layer | Choice | Why it exists |
|---|---|---|
| Desktop UI | SwiftUI with targeted AppKit integration | Native windows, Preferences, menu bar controls, and the macOS Accessibility APIs. |
| Speech engine | Bundled local process on 127.0.0.1 | Selected text can be spoken without sending it to a hosted text-to-speech API. |
| Audio | Streaming WAV into native playback | Start listening before an entire passage is rendered. |
| Persistence | Local app-support files and preferences | History, voice settings, audiobook state, and progress survive a restart. |
| Optional external work | Gemini cleanup only when a user supplies a key and chooses it | Keeps the ordinary reading path local and makes the boundary explicit. |
| Product measurement | Small anonymous event outbox plus optional email identity | Understand real use without collecting selected text, document content, audio, filenames, or API keys. |
The diagram is intentionally boring. A reading utility should not have a surprising control plane. When the shortcut is pressed, there should be one clear route from the selected words to sound, and a clear explanation when macOS has not yet given the app the permission it needs.
Design decisions and tradeoffs
Local speech is the default, not an upsell
A remote text-to-speech API is easy to call. It also turns every highlighted paragraph into a network request, adds account and billing questions to a simple action, and makes reliability depend on a service outside the Mac.
Voqora instead carries a local speech engine in the application bundle. First launch extracts that engine once into Voqora's own application-support folder. Later launches use a version marker to avoid repeating the same expensive setup. The tradeoff is honest: the initial download is large and Apple-silicon is the focused launch platform. In return, the normal reading action does not need a login, a character quota, or an internet connection after installation.
A responsive shortcut matters more than a long configuration ceremony
The default experience has one voice, Bella; one shortcut, Command + Shift + .; and one obvious job. Voice, speed, volume, theme, and shortcuts remain
available for people who want them, but they do not get in the way of the first
spoken sentence.
That is a product constraint, not minimalism for its own sake. A utility has a small attention budget. If it asks a new person to configure pronunciation, cloud accounts, and a dozen sliders before it speaks a paragraph, it has already lost the moment it was built for.
Accessibility is necessary, so its failure state has to be first-class
Reading selected text from another application needs macOS Accessibility access. There is no honest way around that. The right product response is not to hide it in a footnote or leave a disabled play button with no explanation.
Voqora leads with the permission in onboarding, opens the relevant System Settings pane on request, polls the result when the user returns, and keeps an in-context recovery banner available afterwards. Notification permission and optional identity are not treated as requirements. The core action should have one necessary setup step, clearly explained, rather than several unrelated permissions bundled into a vague “Continue” button.
Metrics should describe product reality, not flatter it
There are four very different quantities a new desktop product can observe: download clicks, reported anonymous installations, activity events, and voluntarily provided email contacts. They are not interchangeable.
Voqora keeps them separate. A durable anonymous identifier lets the product count an installation without requiring an account. Event IDs make retrying a failed network delivery safe. An optional email can help recognise a returning person across installs, but it is not required and it can be removed from both the Mac and the product backend. That means a dashboard can say “four reported installations” without pretending it has learned the identities of four different humans.
The everyday product, not a novelty demo
Text-to-speech can sound like a niche accessibility feature until you use it as a working habit. Then it becomes a different way to move through information.
Here are the moments Voqora is built for:
- Before a meeting: listen to a briefing document while you get ready instead of trying to skim every line at your desk.
- During research: use your eyes for figures, equations, and citations; use your ears for the surrounding explanation.
- While writing: hear a draft out loud. Repetition, missing words, and clumsy sentences become obvious much faster.
- When your eyes are tired: keep going through an article or note without forcing another hour of screen time.
- When a document is too long for one sitting: make it an audiobook, stop whenever you need to, and continue from the same place later.
The point is not to replace reading. Some material needs visual attention. The point is to give you a clean second mode when listening is the better tool.
A shortcut that stays out of your way
Voqora lives alongside the apps you already use: your browser, Notes, a PDF reader, a writing app, an IDE, or a document editor.
Select text and use the default shortcut:
| Action | Default shortcut |
|---|---|
| Speak selected text | Command + Shift + . |
| Play / pause | Command + Shift + / |
| Stop | Command + Shift + , |
| Export the latest clip | Command + Shift + M |
All of these can be remapped in Preferences. The initial voice is Bella, so the app starts with a sensible, consistent default instead of asking you to make a dozen decisions before hearing anything. The public release includes eight English voices: four American and four British. You can adjust voice, speed, and volume once, then let the app stay predictable.
That sounds small, but it matters. A utility only earns a place in a daily workflow when its first action is obvious and its tenth action is not annoying.
Long documents should not become abandoned tabs
The selected-text shortcut is for the next paragraph. Audiobooks are for the things that keep getting postponed: a research paper, course pack, report, proposal, handbook, or long-form essay.
In Voqora, a PDF, TXT, DOCX, or Markdown file becomes something you can listen to in manageable pieces. The app keeps the audiobook state locally, including your progress, so closing the app does not turn the next session into a search for the last paragraph you heard.
The workflow is simple:
- Add a PDF, TXT, DOCX, or Markdown file to the audiobook library.
- Let Voqora extract the text and prepare narration.
- Listen when it makes sense for you.
- Return later and continue from your saved position.
Most text-based documents can be handled locally. Some scanned PDFs or poorly extracted files need cleanup before they become pleasant to hear. For that case, Voqora offers an optional Gemini-based cleanup path. You provide your own API key and choose that operation. The relevant document material is sent to Gemini only for that requested cleanup. It is not part of normal selected-text speech, and it is not required to use Voqora.
That distinction is intentional. The default should be clear. Optional help should remain optional.
Local speech is a product choice
The core speech path runs through a bundled local engine on Apple-silicon Macs. When you select text and ask Voqora to speak it, the app does not need to send that text to a cloud text-to-speech service.
That has three practical benefits:
| What stays simple | Why it matters |
|---|---|
| No account needed for the core feature | You can start using the product without creating another identity. |
| No per-character speech bill | Reading a long document does not turn into a metered cloud request. |
| Your selected text stays on the Mac for normal speech | A quick reading action does not require uploading the content. |
The product boundary is plain:
Local-first is not a marketing slogan here. It is the default flow people use hundreds of times: select text, press a shortcut, listen.
What fast means in a reading tool
For this kind of product, “fast” is not a leaderboard number. It means that pressing the shortcut feels like a direct action, not a request you have to wait around for.
Voqora streams generated audio into native playback so you can begin listening before a full passage has become a finished audio file. The app is designed to keep the gap between intent and first useful audio small, then keep playback moving while it prepares what comes next.
The engineering underneath that is there to serve an ordinary feeling: select something, press a shortcut, and hear it soon enough that your attention has not moved on.
The path from a shortcut to sound
The product looks simple because the visible action should be simple. Under the hood, Voqora has to make several parts of macOS and the local speech engine behave like one interaction.
When the shortcut is used, Voqora first asks macOS for the text currently selected in the foreground app. That is why Accessibility access is part of first-use setup: it lets the app work with a selection in a browser, document editor, PDF reader, notes app, or IDE without asking you to paste the text into another interface. If a particular app does not expose a selection through the standard Accessibility path, Voqora says so plainly instead of pretending every Mac app behaves the same way or quietly taking over the clipboard.
The text then moves through a small local pipeline:
The important choice is that audio is streamed into playback as it is made. Voqora does not wait for an entire long paragraph to become a finished file before it lets you start listening. A new selection interrupts the old one, because the next thing you chose to read should win. Playback controls, the menu bar, the main window, and the global shortcuts operate on the same audio state so they do not become four slightly different products.
There are mundane details in that sentence, but they are the difference between a demo and a tool: a pause should resume, stopping should not leave old audio queued, an error should explain the next action, and a restarted local engine should not strand the rest of the interface on a loading screen.
Building a local engine into an installable Mac app
The speech model is not a hosted API hidden behind a button. Voqora packages a local server with the macOS app, extracts it into its own application-support directory on first use, and keeps a small version marker so a normal reopen does not redo heavy setup. The server listens only on the Mac's loopback address. The app talks to it locally; other devices on the network cannot turn it into an open text-to-speech endpoint.
That packaging work is unglamorous, but it is part of making the product real. The first-use screen gives setup priority over engine loading, so a person sees what Voqora needs instead of a mysterious empty player. If the engine has not finished starting, the app says so and recovers rather than acting as if it received an empty request.
The same principle applies to releases. The installer contains the app, the local engine, fonts, licenses, and a single drag-to-Applications path. The updater is designed around a signed update feed. A future in-app update is only eligible once its signature and byte length have been checked against the exact DMG being published. That sounds like release plumbing, but it is really user experience: clicking “Check for Updates” should either produce a verifiable update or clearly say that there is none. It should never send someone into a cryptic installer failure loop.
The failure states are part of the feature
The less visible work in a desktop utility is deciding what happens when the happy path is not available yet. A shortcut may be pressed before a selection exists. macOS may not have granted Accessibility access. The local engine may still be waking up. A previous request may finish after a newer request has already taken priority. A PDF may be damaged, scanned, or simply not contain usable text.
None of those cases should quietly turn into a blank player, a frozen control, or an old error that overwrites a newer success. Voqora treats them as named states: the interface explains when it needs a selection, when it needs a permission, when the engine is starting, and when a document needs a different route. Playback work is tied to the request that created it, so a late result cannot casually take control back from the thing you most recently chose to hear.
That sounds less exciting than a new feature, but it is exactly what makes a small utility dependable. The user should not have to learn a private ritual for recovering from the app. They should see what is happening and what to do next, then return to their work.
Audiobooks are a different workflow, not a stretched shortcut
Speaking a paragraph and working through a ninety-page document have different failure modes. The audiobook flow therefore has its own library, progress, resume state, estimates, and recovery language rather than pretending that a PDF is just one very large text field.
Before a long document is processed, Voqora can show what it found and what will happen next. When a document is text-based, the normal local route is enough. When a PDF is scanned or any document is extracted badly, optional cleanup exists for that narrow case. It is intentionally not an invisible default. The user supplies their own Gemini key and chooses that operation, because sending document material to an external service should be a conscious product action, not background magic.
The result is deliberately modest: not “AI turns every file into a podcast,” but a reliable place to continue listening to material that otherwise lives as an abandoned tab.
The details that make it usable every day
Good speech is only the first layer. A product you return to needs to preserve context and make routine actions easy.
Voqora includes:
- Local history for passages you have spoken before.
- WAV export for the latest clip when you want to keep or share the audio.
- Play, pause, and stop controls that work without forcing you back into the main window.
- Voice, speed, and volume preferences so the product can sound like yours.
- A document-to-audiobook library with locally saved progress and resume support.
- Plain-language first-use guidance for the macOS permissions that enable global shortcuts and accessibility features.
This is not an attempt to turn every document into a polished podcast. It is a way to keep information moving when your attention is available but your eyes are not.
Why a native Mac app
A web page can turn text into audio. That was never the difficult part.
The harder part is fitting the action into a real Mac workflow: responding to a global shortcut, working with selected text from another app, keeping playback responsive, remembering local state, packaging the required speech engine, and giving the user a normal installer and update path.
Voqora is built as a native macOS application because the product needs to feel at home on the machine where the reading already happens. The experience is designed around native controls, native playback, local files, and a familiar install flow: drag the app into Applications, open it, and use it.
The current public release supports Apple-silicon Macs running macOS 14 or later. That is an intentional launch boundary, not a hidden limitation. It keeps the first public product focused on one platform and lets the work go into making that experience reliable.
A release is part of the product
For a Mac app, “it builds on my machine” is not a release standard.
The public product also needs a clear installer, first-launch instructions, readable release notes, and a way for people to receive later updates without manually learning the project structure. Those are release requirements, not last-minute extras.
If macOS puts an extra security warning in the way of a downloaded build, the release materials explain the normal right-click Open route and provide a narrowly scoped command for the installed app when needed. The goal is not to make users troubleshoot developer tooling. It is to give them a predictable path from download to first spoken sentence.
Published future releases can use the app’s built-in update mechanism once the whole signed-update path has been verified from an installed older version to a newer one. The public repository keeps the release notes, installer guidance, source, and license together so there is one clear home for the active product.
Behind the scenes, the macOS test host runs serially for full checks. That is deliberate: correctness checks should prove the app works, not open a pile of windows and turn a developer’s laptop into a space heater.
What Voqora is and is not
Voqora is for people who read a lot on a Mac and want listening to be a first-class option.
It is not trying to be every audio product at once. It is not a social reading network, an AI summary factory, or a browser tab with a play button. It is a focused desktop tool that helps you turn reading time into listening time without losing control of the text, files, or workflow around it.
The direction is straightforward: make the Apple-silicon Mac experience genuinely useful, learn from real use, and improve the product without making it noisier or more complicated than the problem requires.
Voqora links
Voqora is available now for Apple-silicon Macs running macOS 14 or later.
Visit Voqora on GitHub View Voqora releases
The GitHub project contains the source and documentation. The releases page contains the current DMG and install notes.
The source is available under the PolyForm Noncommercial license. You can study, modify, and share it for non-commercial purposes. Commercial use requires a separate agreement.
The most useful feedback is specific: what did you try to listen to, where did the workflow help, where did it break, and what would make you open Voqora again tomorrow?