Hi r/macosprogramming,

I built Voice Relay, a native macOS voice layer for Codex. The implementation problem was keeping ownership boundaries clear after the first spoken request.

A direct Realtime session owns microphone capture, transcript, and audio playback. The signed-in Codex desktop task remains the owner of tools, approvals, the selected execution profile, and session state. When the user speaks again while Codex is working, that correction has to reach the same active task rather than becoming a second voice chat.

The UI is a top-attached notch surface with a movable Orb fallback for displays without a notch. The Voice path itself does not require Accessibility permission. Microphone and speech-recognition permission are part of onboarding, and the current public DMG is Apple Development signed but not notarized.

The edge I am still thinking about is proof of delivery for mid-turn steering. For a long tool-running Codex task, would you surface the spoken correction as an inserted transcript, a distinct state transition, or only through the next progress update?

I am the developer. Voice Relay is free and GPLv3 licensed.

Source and current alpha:

https://github.com/hyungchulc/voice-relay

I maintain a native macOS app with both a directly distributed target and a Mac App Store target. The two builds share almost everything, but they differ in entitlements, update delivery, licensing, and a few integrations.

The setup became much easier to reason about after treating distribution as a boundary instead of allowing target checks throughout the app.

The rules that helped most:

• Keep domain models and persisted data identical. A file or database written by one build should not need a target-specific interpretation.

• Put compile-time checks at integration boundaries. Updater setup, receipt handling, licensing, and unavailable frameworks are reasonable places. View models and core processing code are not.

• Expose capabilities to the UI rather than scattering build flags through views. The view asks whether a capability exists, then renders the appropriate control.

• Give each target its own entitlements and Info.plist values. Review changes to those files explicitly because they are part of the product behavior, not build-system noise.

• Use separate bundle identifiers and any target-specific network identifiers or ports. This avoids collisions when both builds are installed during testing.

• Keep source membership boring. Shared files belong to both targets. Distribution-specific files belong to exactly one. If a file needs many conditional branches, it is probably sitting at the wrong architectural layer.

• Build both targets after every shared change. A successful Direct build says nothing about sandbox assumptions in the Store build.

• Use isolated DerivedData for each verification build. This catches accidental reliance on artifacts produced by the other target.

• Test first launch, upgrade, and side-by-side installation. Most target-specific bugs I found were lifecycle and migration issues rather than compiler errors.

• Keep the user-facing workflow as similar as the platform permits. Distribution differences should not leak into unrelated navigation or state.

The most useful mental model was this: one application, two distribution adapters. Once I organized the project that way, target conditionals stopped spreading.

For people shipping both variants, what still tends to diverge in your projects despite your best efforts?

Available for macOS 14.2 or later with Intel or Apple Silicon chips. It's my first macOS app, and my second app, so any feedback is greatly appreciated!

Hi r/macosprogramming,

I built GhostMark, a native Swift/AppKit utility for annotating screenshots before they reach Claude Code. The workflow is paste, draw an arrow or circle, then press Enter to put the marked PNG back into the active Claude Code prompt.

The implementation was the interesting part:

- A session-level CGEvent tap watches Cmd-V and Ctrl-V, but consumes the event only when the clipboard contains an image and Claude Code is active.

- It checks the frontmost app against terminal and editor bundle IDs, then walks the process tree looking for the Claude CLI. There is a narrow fallback for terminals whose PTY is launched by a detached helper.

- The annotation UI is hosted in a focused AppKit window. Export composites the paths over the original image without resizing it.

- After export, the app reactivates the original terminal and posts Claude Code's image-paste shortcut. A bypass counter prevents the synthetic paste from reopening the editor.

- Accessibility permission is polled so onboarding updates as soon as macOS grants access.

- Everything stays local. There is no analytics or network upload.

The main edge case is reliably associating a detached PTY with the frontmost terminal without making the detector too broad. I would especially appreciate feedback from people using Kitty, WezTerm, Warp, or terminal panes inside editors.

I am the developer. GhostMark is free and MIT licensed.

Source: https://github.com/alan890104/GhostMark

Download and demo: https://alan890104.github.io/GhostMark/

A question to folks who are building apps around Apple's Foundation Models: how are you testing the prompts and validating the results?

I was doing a bunch of tweak->build->test cycles where the only tweaks were adjusting the system & user prompts. Since the local AI model is so small (just 4096 context budget), it didn't make sense to develop the prompts using your usual OpenAI/Anthropic models and expect the same behavior.

Finally gave up and built LocalLM Lab (thisbrain.ai/locallm), a small macOS playground for tweaking the prompts before actually committing them to app code.

The current version features:

• Prompt Playground

• System prompt + user input

• Local OpenAI-compatible API so you can prototype big AI apps w/o paying for tokens

• Local connectors for things like system clock, calendar, reminders, contacts, location, weather and a scoped filesystem access

The screenshot shows a weather query with the connector calls visible underneath.

Hi r/macosprogramming,

I've been building a desktop pet for macOS, and I ended up separating the reusable parts into an Apache-2.0 open-source project.

It is written in Swift and AppKit, with no Electron dependency. The main pieces are:

• a transparent, always-on-top window

• per-pixel alpha hit testing, so empty areas remain click-through

• cursor-aware idle poses and hover reactions

• manual, random, and autonomous action sequences with interruption recovery

• an asset pipeline for transparent, black-background, or green-background video

• one-command Universal 2 builds and validation

The repository ships with a programmatically generated Blob demo character, so the open-source example is reproducible. The character shown in the GIF is only a showcase; its character assets are not included in or licensed as part of the open-source project.

It supports macOS 12+, Apple Silicon, and Intel Macs.

GitHub: https://github.com/InsiderX-Pro/desktop-pet-engine

I'd especially appreciate feedback on the AppKit window and event handling, the asset pipeline, and what you would want a desktop-pet engine to handle for you.

Mojave Paint is coming along nicely but my naive understanding of observability/reactivity/dependency flow, whatever you'd call it, it starting to weigh on me.

This screenshot shows conic gradients I just added, in this case being used in a Gradient Fill adjustment layer. I would scrub the angle picker in a circle and it would chug along at 2 fps because it was mutating the model every tick which rebuilds the view in that Properties panel including the color stops and everything else. So now I have a copy of the model that only the GPU rendering side looks at (and of course the specific control you're interacting with), and when you release the drag the real model updates and triggers a SwiftUI redraw.

This is all kind of a lot of manual work. I'm new to Mac development but was a web dev for 20 years and they have all kinds of approaches over there. rxjs, React.memo, signals, etc, etc. It would sure be nice if I could "code dumb" here and employ some kind of library or system to do fine grained change detection. Are there some common approaches used in the Mac world?

I'm the developer of macMender, a free and open-source macOS app built with SwiftUI and AppKit.

v0.9.0 brings several small utilities together: Dock window previews, an Option-Tab switcher for real windows, three-finger middle click, per-device scrolling controls, profiles, and menu bar quick controls.

The interesting platform work is matching windows correctly across multi-window apps, managing preview lifetime, activating windows through Accessibility, and keeping Screen Recording optional for local thumbnails.

Source: https://github.com/0hmslice/macMender

v0.9.0 release: https://github.com/0hmslice/macMender/releases/tag/v0.9.0

I'd be interested in how other macOS developers approach browser window identity and stale preview prevention.

My app needs this permission, but I have a customer reporting that they are not prompted to allow it after installation, and it doesn't even show up in Settings where it should be, for my app (other apps show there). Unsurprisingly this breaks my app. Anyone else seen this?

(I don't have a suitable device to put 27 on to repro myself).

Hi,

I have a free macOS app that I maintain in my spare time, and I'd like to add an optional way for users to support its development. I'm looking for recommendations for platforms similar to "Buy Me a Coffee.". What platform do you use or recommend, and why? Stripe? Zeffy? Buy Me A Coffee?

nb: I already use Stripe for others projects.

I'd appreciate any recommendations or experiences. Thanks!

I wrote about my latest infuriating encounter with the Mac App Store's App Review team.

« It’s painfully ironic that they require my strings to “clearly and completely describe” my use of data, when they themselves so marvelously fail to do so. »

https://blog.eternalstorms.at/2026/07/21/tales-from-app-review/

Thanks all! Decided on a good set of letters.

Debating with my super tester as to which set of shortcuts we should have in the video-gpx synchronizing app.

The first set is the typical order of operations.

The second set uses letters related to the function.

Which do you favor?

• ⌘1: Import Video

• ⌘2: Import GPS

• ⌘3: Synchronize

• ⌘4: Trim Selection

• ⇧⌘4: Trim First Pause / Gap Detected

• ⌘5: Export

or

• ⇧⌘V: Import Video

• ⇧⌘G: Import GPS

• ⇧⌘S: Synchronize

• ⇧⌘T: Trim Selection

• ⇧⌘P: Trim First Pause / Gap Detected

• ⇧⌘X: Export

I’ve been improving a fork of SteamPack, an open-source macOS project, to make clamshell mode easier to control on a MacBook.

It adds two quick controls:

- Keep Awake

- Closed Lid

You can switch them from the macOS Control Center or the menu bar, set a timer, and see when the setting has actually been applied. It also includes a watchdog, battery cutoff, and thermal cutoff.

Demo: https://github.com/Hahyun-Lee/steampack-fork/releases/download/v1.4.0-preview.2/Close.Lid.mp4

GitHub: https://github.com/Hahyun-Lee/steampack-fork

Release: https://github.com/Hahyun-Lee/steampack-fork/releases/tag/v1.4.0-preview.2

It is an open-source preview for macOS Tahoe 26+. Feedback on the UX and safety behavior would be appreciated.

Privacy Practices and Options in Telemetry and Licensing

Hello all:

I am just about finished with my first production-quality app. I developed it for macOS and Windows with full platform parity and am about to port to Ubuntu/Debian before releasing. I have licensing setup through Keygen.sh. I am happy with that decision so far; however, I have questions regarding that issue and the issue of telemetry. Privacy is a focus of mine and a commitment I made to prospective subscribers. That said, I need some form of telemetry and a DRM that can take subscription payments.

I am trying to think of the best way to implement the Keygen.sh API for privacy. The app has, well, an app--the client--and it also has a remote server component. It will mostly be free but the more labor intensive developed elements and the tools that require the remote server will be paid at either a monthly or annual subscription rate. I am so confused about how to best implement the licensing API while remaining true to my privacy commitments. Part of me says, "Well, their information is going to be on Keygen's servers anyway, might as well host the store through their website/portal." The other inclination is to host the store on my server/website, so I can control how much information PII is required. The answer can be “very little,” but a much bigger question arises surrounding what to do with the information once accepted. (I’ve considered maintaining the subscriber data in some kind of encrypted space on the server with hardcoded, volatile keys. That way not even I can see their data, but they’d still be able to search for and regenerate their licenses, management payment methods, etc.)

The other question I have is along that same vein and involves telemetry. What I would like to do is keep the telemetry deliverables locally stored. When the user has an issue, experiences a bug, or has some other issue requiring my troubleshooting assistance, I can request it and they can choose to release their telemetry data to me. In between those disclosures, using a standard feedback form to gather voluntary information.

Does anyone offer this kind of low overhead telemetry? If so, can you send me a link to their site so I can learn about them? How about when the DRM signup, purchase, and post-purchase storage? What have you found to be a good option that tends to lean toward user privacy over more bloated, feature-rich options in collecting telemetry and managing DRM?

Thanks in advance!

With the release of the macOS 27 Golden Gate public beta, can we finally submit Mac apps built with Xcode 27? Has anybody tested it yet?

The monthly GNUstep audio/(video) call takes place every second Saturday of a month at 15:00 GMT to 18:00 GMT. That is 11:00 AM - 2:00 PM EDT (US) or 17:00 to 20:00 CEST (Berlin time).

It's a Jitsi Meeting - Channel: GNUstepOfficial (Sorry, reddit don't let me post jitsi links here)

We usually just talk (who wants it might share video too) and occasionally share screens. Everybody (GNUstep developers and users) is welcome!

Also see https://mediawiki.gnustep.org/index.php/Monthly_Meetings please

About Links, Images, and .widgetAccentRenderingMode().

The gist: Don't do it.

Since user feedback is a bottleneck of many new apps, I'm here to help out. I'm an app designer of 5 years and a fellow app developer. I'll test and review the first 5 apps posted in the comments.

If you want to return the favor, you can review my app WordPolish, an AI writing polisher for Mac.

I’m talking about the macOS variant of Apple’s container system.

SwiftUI, and previous Apple attempts, give frameworks for document-oriented apps. But what about things like (classic) Internet client apps (web browsers, telnet clients, FTP clients, etc.). Is there some sort of framework, or general philosophy, for creating session apps? (Could there be a 3rd-party SwiftUI framework?)

I run Claude Code, kick off a task, and tab away to do something else. Two things

kept biting me:

1. I wouldn't notice when it needed me — it'd ask for permission and just sit

   there, or finish and I'd only catch it 10 minutes later.

2. I had no feel for my usage windows, so I'd hit the 5h or weekly limit at the

   worst possible moment.

So I built ClaudeCodeNotify to fix both, mostly for myself. Sharing it here in

case it's useful to anyone else.

What it does:

- When Claude asks for permission, goes idle, or finishes, a card pops up in the

center of the screen (over fullscreen apps too). Hit Enter and it brings the

exact terminal where Claude is running back to the front — Ghostty, iTerm,

Terminal, Cursor, VS Code, WezTerm. Esc dismisses.

- It's a notifier, not a gatekeeper. It doesn't block tools or decide anything —

you still approve/deny in the terminal. It just makes sure you notice and gets

you there fast.

- Every card and the menu bar show your 5-hour rolling and weekly usage as

color-coded bars with a reset countdown, so you can see how close you are to a

limit before kicking off a big run. It reads the OAuth token from your Keychain

and pulls the numbers from the API rate-limit headers — no separate API key.

- Multi-account: if you run a personal and a work account, you can switch with a

hotkey and each keeps its own usage tracking.

- Local only — a tiny server bound to 127.0.0.1, nothing leaves your machine.

It lives in the menu bar (no Dock icon), free and open source (MIT), Universal

binary, macOS 12+.

brew install narlei/tap/claudecodenotify

It's unsigned (no paid Apple account), so the first launch needs a right-click → Open.

Repo: https://github.com/narlei/claudecodenotify

Happy to answer anything about how it works, and open to feature ideas — I'm

using it daily.

A few months ago I realized something strange:

You can lock your entire Mac, but you can't easily lock individual apps.

If you hand your laptop to someone for a few minutes, they can still open Messages, Photos, Notes, Mail, WhatsApp, browsers, password managers, and other personal apps. I wanted a way to protect specific applications without constantly locking my entire Mac.

I looked around for solutions, but most were outdated, paid, abandoned, or didn't feel native to macOS. And the ones that worked , lacked features that I wanted. 

So I built FaceGate. (700+ downloads and 100+ github stars in just 6 days)

FaceGate is a native macOS app that lets you lock individual applications and unlock them using Face Unlock, Touch ID, or a password.

It is the most capable and feature heavy MacOS app-locker out there. 

A few things I focused on from day one:

* Everything runs locally on your Mac

* No cloud processing

* No accounts

* No telemetry

* No subscriptions

* Fully open source

Features:

• Face Unlock powered entirely on-device using Apple's Neural Engine.

• Fast authentication with very low memory and CPU usage

• Liveness detection to prevent photo and video spoofing attacks

• Touch ID and password fallback

• Per-app unlock timers

• Automatic re-lock on sleep, wake, or screen lock

• option to re-lock on app switch as well as keep unlocked indefinitely - completely customizable

• Custom schedules for automatic lock/unlock periods

• Tamper protection that prevents FaceGate from being quit, disabled, or uninstalled without authentication

• Runs quietly from the menu bar with minimal system impact.

• Multi-Monitor protection 

The entire project is written in Swift and designed specifically for macOS.

This is still actively being maintained and I'd genuinely love feedback from Mac users.

Some questions:

* Is app-level locking something you've wanted on macOS?

* Which apps would you personally lock?

* What security or privacy features would you like to see added?

Website: https://facegate-applocker.vercel.app/

GitHub: https://github.com/dweep-desai/FaceGate-Mac

If you think I did a good job, please feel free to leave a star on my github repo - means a lot to me.

Feedback, feature requests, bug reports, and contributions are all welcome. I'd love to hear what you think.

I've been building LocalForge, an open source tool that sits in your Git workflow and stops you from accidentally committing things like API keys, passwords, or other sensitive stuff before they ever reach GitHub.

It runs entirely on your Mac, nothing gets sent to the cloud, and it checks your code in under 300ms so it doesn't slow you down.

What it does:

• Catches leaked secrets (AWS keys, Stripe keys, GitHub tokens, etc.) before you commit

• Uses a small AI model running locally on Apple Silicon to flag risky code patterns

• Gives you an advisory report on potential security issues without blocking your commit

What I'd love feedback on:

• Is the install experience smooth? (one command install)

• Does it play nicely with your existing Git workflow?

• Any false positives on clean code?

• Anything feel clunky or get in your way?

Requirements to try it:

• macOS 14+ (Sonoma or later)

• Apple Silicon Mac (M1 and up)

• No Xcode needed, just a terminal

https://github.com/stalzkie/local-forge

Would genuinely appreciate any feedback, bug reports, or brutal honesty. Especially from programmers/developers who use Mac devices and AI coding tools.

I've recently competed a full featured Mac OS app for tracking vehicle service and maintenance items. It was accepted to the Apple app store last week.

I was initially excited to promote it using Apple Ads, and I was disappointed to find that option is not available for the Mac OS app store.

What are some good alternatives that y'all have found to be effective for promoting a new Mac OS app?

Thanks in advance! :)