Why Bellow isn't on the Mac App Store

8 August 2026 · 4 min read · Muteeb Mehraj

It is the second question people ask, right after "does it send my voice anywhere." The answer is a technical constraint, not a business preference, and it is worth explaining properly.

The short version

Bellow needs to notice when you press and hold a key, no matter which app you are in. On macOS that means a CGEventTap, a system-wide event monitor. Event taps require the Accessibility permission and are incompatible with the App Store sandbox. An app that cannot observe a global key press cannot be a push-to-talk app.

So the choice is not "App Store or not." It is "push-to-talk or not."

Why it has to be an event tap

There is a gentler-looking API, NSEvent.addGlobalMonitorForEvents, and it is the first thing anyone reaches for. It does not reliably observe the Fn key, which is the default trigger and the one most people want, because it sits in the same place as push-to-talk on every voice app they already use.

There is also the Carbon hotkey API, which Bellow does use, as a backup on Ctrl+Opt+Space. It registers a key combination and fires when that combination is pressed. What it cannot do is tell you the key is being held, then tell you when it was released. Push-to-talk is entirely about the hold. A press-and-release hotkey gives you a toggle, not a walkie-talkie.

That leaves the event tap. It is the only API on macOS that reports the raw modifier-flag transitions Bellow needs, in every app, without being the frontmost application.

What the sandbox is actually for

It is worth being fair to the sandbox here, because the reason we cannot use it is the reason it is good.

The App Store sandbox exists to stop an app doing exactly what Bellow does: watching your keystrokes globally. That is a genuine attack surface, and Apple is right to make it require explicit, revocable, per-app consent that lives outside the app's control.

So Bellow asks for Accessibility, macOS shows you the prompt, and you can revoke it at any time in System Settings without uninstalling anything. That is the mechanism working correctly. We are on the outside of the sandbox because of a capability we genuinely need, not because we wanted fewer rules.

What you lose, and what replaces it

App Store distribution gives users three real things. Here is what happens to each.

A vetted binary

Replaced by Apple notarization. Every Bellow build is signed with a Developer ID certificate and submitted to Apple's notary service, which scans it and issues a ticket that gets stapled to the disk image. Gatekeeper checks that ticket on first launch. You can check it yourself:

spctl --assess --type open --context context:primary-signature -v /Applications/Bellow.app

You want to see accepted and source=Notarized Developer ID.

Managed updates

This one we genuinely do not replace, and it is the honest cost. Bellow has no updater, because an updater is a process that phones home on a schedule, and the entire product claim is that nothing leaves your Mac. We were not willing to add a network call to the one app whose selling point is that it makes none.

So updates are manual: you download a new build when you want one. That is worse for you. We think it is the right trade for this specific app, but it is a real cost and we are not going to pretend otherwise.

A privacy label

Replaced by something stronger, which we would argue for even if the App Store were an option. Bellow ships a second entitlements configuration that is fully sandboxed, declares microphone and user-selected file access, and deliberately omits network client and network server entitlements. The app reads its own entitlements back at runtime, through the OS, and displays them in Settings.

That distinction matters. A privacy label is a claim the developer types into a form. An entitlement is enforced by the kernel. If the network entitlement is absent, the app cannot open a socket, regardless of what its code tries to do or what its marketing says.

Installing without the App Store

Download the disk image, drag Bellow to Applications, and launch it from there. On first launch macOS verifies the notarization ticket.

Then grant two permissions when asked:

• Microphone, so it can hear you.
• Accessibility, so it can see your trigger key and paste the result.

One caveat worth knowing, because it catches people: macOS ties Accessibility to a specific copy of an app. If you have Bellow in Applications and a copy still sitting in a mounted disk image, the permission can attach to the wrong one. The list shows Bellow as enabled while the running app stays denied. If the trigger key does nothing despite the checkbox being on, eject any mounted Bellow volume, remove the entry, and re-add the copy in Applications.

Would we ship there if we could?

A sandboxed companion build is possible in principle, but it could not do push-to-talk, which is the entire product. What is left after removing the global hotkey is a worse version of Apple's built-in dictation.

So: no, and not as a stance. Push-to-talk is the feature. The event tap is how push-to-talk works. The sandbox forbids the event tap. Everything else follows from that.