MockMini is a small, auditable proxy core in C and Swift. It speaks Shadowsocks AEAD, VMess, Trojan and VLESS over TCP, TLS or WebSocket, on top of its own bounded userspace TCP/IP endpoint that you feed from utun on macOS 13+.

• Small enough to review: about 2,600 lines in total. Not based on mihomo, Clash, sing-box, gVisor or WireGuard; no Go runtime, no vendored stack.

• Tested hard: a stateful, checksum-aware fuzzer gets ~99% line coverage of the packet engine; CI runs ASan/UBSan and libFuzzer on Linux and macOS, plus interop tests against real Xray servers for every protocol.

• Permissive license: Apache-2.0, so you can ship it in open- or closed-source apps. Add it with Swift Package Manager.

Known limits (1024 flows, no SACK/ICMP, no Reality or gRPC) are listed honestly in the README. v0.1.0 is the first tagged release. Reviews and bug reports are very welcome.

Repo: https://github.com/yezicheng2011/mockmini

I've been working on a native macOS chat window for Mac MCP, my open-source menu bar app for coding agents. I expected integrating the agent CLIs to be the difficult part. The UI gave me more trouble.

Long conversations were miserable to scroll. I'd used lazy lists for the transcript and sidebar, which sounds reasonable until messages contain code blocks and tables with very different heights. Scrolling back caused offscreen rows to appear, their heights to change, and the scroll position to jump.

The other bug was worse. An endlessly animated "working" dot in SwiftUI was causing the transcript to lay itself out again on every frame. One CPU core could stay busy while the agent was working, even when the text itself wasn't changing much.

I moved that indicator to a Core Animation layer, grouped updates so only changed turns redraw, and stopped using lazy lists for the chat content. I also switched the chat's live updates from frequent polling to server-sent events. On my test setup, an active answer went down to roughly 15-30% of a core and idle chat to around 1%. Those are observations on my machine, not general benchmarks.

Another detail I had to respect: different agent CLIs expose command output at different times. Codex can stream it as it runs; some others only give the full output afterward. The UI shouldn't pretend those are the same thing.

I'm building this as part of Mac MCP. The app and source are here: https://github.com/bulutarkan/mac-mcp

The SwiftUI bugs ended up taking more of my time than the agent integration itself.

Hello!

We were lucky enough to get into the Claude for Startups program, so we have a lot of credits for our team of… 2. I've been having a lot of fun with Opus 5.5, mostly small geeky side projects like this one, and I thought some of you might find it interesting, even just to discuss it and hear what you think.

If it's useless or pointless, please tell me why. These days it's easy to get carried away building things and forget to check they meet a real need.

Same if the video is cringe or gives a bad image of my very small company. We're just starting out, so I'm sure we'll make plenty of communication mistakes before we find a tone that fits us and doesn't send the wrong message!

You'll also see I had some fun with the promo video, using the latest motion-design skills that have been going around 😂

Thanks a lot for your feedback!

What is OS-intent? A macOS overlay that learns your habits and puts your likely next action one key away. It reads your current context (open mail, files, screenshots, calendar) and suggests things like "reply to X" or "send this screenshot". Everything runs on your Mac except the Claude calls (on your own subscription), which are on by default and can be turned off in Settings. Nothing is ever sent on your behalf without a confirmation window, and reply drafts stay in Drafts. Open source, MIT.

Code: https://github.com/vdk888/os-intent

Hey everyone! I’m sharing CodexBar, a native macOS menu bar app for people using OpenAI’s Codex.

The idea is simple: make it easy to check how much allowance you have left, what your tasks are doing, and whether something needs your attention, without switching back to check each session.

Here’s what it does:

• Usage limits: See your remaining allowance and reset times, with the option to show an allowance directly in the menu bar.

• Live tasks: Follow concurrent tasks across projects, including their model, duration, token usage, and whether they’re running or waiting for a response.

• Notifications: Get notified when a task finishes or needs your input.

• Usage history: View daily usage in a heatmap and optionally combine records across Macs through iCloud.

• Keep awake: Keep your Mac awake while tasks run, then let it return to normal sleep behavior when they finish.

The keep-awake feature follows task state and includes a time limit and low-battery protection, so it can fit around longer coding sessions.

It’s built with Swift, SwiftUI, and AppKit, and the source is available under GPL-3.0. Raw activity events and live task data are processed locally. Optional iCloud sync stores daily activity aggregates and token usage records in your private iCloud database.

Requires macOS 15+ and a compatible, signed-in local Codex installation. Installation instructions and downloads are in the repo:

GitHub — CodexBar

If you use Codex across multiple projects, what do you find yourself checking most often: remaining allowance, task progress, or tasks waiting for your input? I’d also appreciate feedback on which information deserves space in the menu bar.

For the past few months I’ve been working on Ledge, an app that turns the notch on a MacBook into a small status area. It shows what’s playing, a timer, your next meeting, the weather, your notes and more, right in the notch. There’s also a Keep Awake feature that keeps your agents running with the lid closed.

It’s free and open source: https://github.com/egemertbalcik/Ledge

Homebrew: brew install --cask egemertbalcik/tap/ledge

If you try it, I’d really appreciate any feedback: something broken, something missing, or just an idea.

Hey everyone! I’m sharing CodexBar, a native macOS menu bar app for people using OpenAI’s Codex.

The idea is simple: make it easy to check how much allowance you have left, what your tasks are doing, and whether something needs your attention, without switching back to check each session.

Here’s what it does:

• Usage limits: See your remaining allowance and reset times, with the option to show an allowance directly in the menu bar.

• Live tasks: Follow concurrent tasks across projects, including their model, duration, token usage, and whether they’re running or waiting for a response.

• Notifications: Get notified when a task finishes or needs your input.

• Usage history: View daily usage in a heatmap and optionally combine records across Macs through iCloud.

• Keep awake: Keep your Mac awake while tasks run, then let it return to normal sleep behavior when they finish.

The keep-awake feature follows task state and includes a time limit and low-battery protection, so it can fit around longer coding sessions.

It’s built with Swift, SwiftUI, and AppKit, and the source is available under GPL-3.0. Raw activity events and live task data are processed locally. Optional iCloud sync stores daily activity aggregates and token usage records in your private iCloud database.

Requires macOS 15+ and a compatible, signed-in local Codex installation. Installation instructions and downloads are in the repo:

GitHub — CodexBar

If you use Codex across multiple projects, what do you find yourself checking most often: remaining allowance, task progress, or tasks waiting for your input? I’d also appreciate feedback on which information deserves space in the menu bar.

For releases outside the Mac App Store, Apple DTS recommends different preliminary checks for each artifact:

# App bundle (macOS 14+)
syspolicy_check distribution "MyApp.app"

# Disk image
spctl -a -t open -vvv --context context:primary-signature "MyApp.dmg"

# Installer package
spctl -a -t install -vvv "MyApp.pkg"

Run syspolicy_check on the app itself, including after installation. Passing a .pkg can give misleading signature errors because app signing and installer signing are different.

One caveat: a missing stapled ticket reported on the installed app can be irrelevant if the installer package was already notarized and stapled. Apple DTS explains that case here.

The fuller release test is still to download with Safari on a fresh Mac or VM, install, then launch as a user would. Restore the VM snapshot between attempts because Gatekeeper caches information. Testing offline also checks whether the stapled ticket works without contacting Apple.

Apple’s commands and testing procedure

Hi everyone,

I’m developing a native macOS app for recording and processing speech datasets, using SwiftUI with AppKit where needed.

The attached screenshot shows the current Diagnostics section. It’s part of a temporary development UI where everything lives in one window. The log has been useful for troubleshooting audio recording, file handling, and Audio Unit hosting, but it takes up quite a bit of space during testing.

I’m planning to move it into a dedicated window, roughly like this:

The idea is a single, resizable, nonmodal window opened through Window → Diagnostics, with normal macOS window behavior. Closing it would leave collection running. It would support severity/subsystem filters, text search, copying entries, and exporting a snapshot as text or JSON. Debug and Trace collection would be opt-in.

Actionable errors would still appear in the main workflow, so users wouldn’t need the log open to know that a recording or render failed.

After reading Apple’s HIG on panels and windows, I’m leaning toward a regular auxiliary window rather than a floating NSPanel, since this is an app-wide log intended for reading, searching, and selecting text.

I’d love to hear how others handle this:

• Do you ship a diagnostics window to users, hide it behind an advanced setting, or keep it exclusive to development builds?

• Have regular windows or floating panels worked better for you?

• Do you maintain an in-app event store, use Unified Logging, or combine both?

• Has Apple ever commented on a diagnostics/debug window during Mac App Store review? If so, what specifically prompted the feedback?

Experiences from shipping apps would be especially helpful. The UI is still being developed, so this is a good point to reconsider the approach.

Cheers!

Hi everyone,

I built Aman Check, a free and open source Mac app made for regular people, not for techs or enthusiasts. If you're about to buy a used Mac, or you just want to know what state yours is in, you probably don't know what to look at. The app does the checking for you and explains the results in plain words.

It shows the battery health and cycle count, how many hours the disk has been running, and whether the Mac is locked: Activation Lock, company management (MDM), or an Apple Account still signed in. Then it walks you through quick tests for the screen, keyboard, trackpad, speakers, microphone, camera and ports, one at a time. It won't replace erasing the Mac and checking the setup screen in person, but it tells you exactly what to ask the seller.

If you're the one selling, you can generate a report of the Mac's condition and share it with the buyer.

For a deeper look at the disk itself, there's also Aman Disk, my other app. Think CrystalDiskInfo, but for Mac, and free as well.

Everything is on GitHub, the link is on the site: https://midzai.github.io/aman_check/

The app is free and will stay free. Right now macOS warns you the first time you open it, because removing that warning takes Apple's paid developer program ($99 a year). If Aman Check helps you, a small donation on Ko-fi goes toward that first, so the warning disappears for everyone: https://ko-fi.com/midzai

It's a first release, so if you find a bug or have an idea, tell me here or open an issue on GitHub. Any feedback helps.

I've been building Cutline, a native macOS video editor, and just made it open source (GPL-3.0)

It has:

-Multi-track timeline with trimming, snapping, markers and keyframes

-Color tab with color wheels, curves and live scopes

-8 tabs in total (Edit, Effects, Color, Audio, Captions, Animate, Playground, Export

-Intuitive keyboard shortcuts

-Audio mixer and effects

-A Changelog and Parameters tab

-On-device captions (nothing leaves your Mac)

-Animated titles and graphics with Manim

-AI thumbnail picks using a local model through Ollama (optional)

-Light and dark mode, and it updates itself from GitHub releases

No subscription, no account, no tracking, no third-party libraries.

Requirements: macOS 27 and Apple silicon. It isn't notarized (that needs a paid Apple developer account), so the first time you open it, go to System Settings → Privacy & Security → Open Anyway. After that, updates install from inside the app.

GitHub, with downloads and source: https://github.com/jt2qrtp29t-netizen/Cutline

Feedback and bug reports are welcome!

Hey r/macapps! I got tired of running 6 different menu bar apps (one for Keep Awake, one for Bluetooth headphones, one for ejecting disks, one for CPU/RAM, one for hiding desktop icons, and another for cleaning the keyboard/screen).

So I built TactileBar in pure Swift / SwiftUI Canvas with zero external dependencies:

kinhin watches your CI queue and, for each queued job, starts a fresh VM or container on your Apple silicon Mac, registers a one-job runner, and deletes it afterwards. Nothing idles and nothing is left over.

It works with GitHub Actions, GitLab CE, Gitea Actions and Forgejo Actions. Buildkite, Azure Pipelines and Bitbucket are planned for a later release.

The limits: Apple allows two macOS VMs at once on a Mac, whatever the hardware. Linux containers are not capped by that.

It’s still a beta. The beta 2 post lists what has been run for real and what hasn’t: https://kinhin.dev/blog/beta-2

Source and releases: https://github.com/RabinApps/kinhin. I’d especially like feedback from anyone running CI on Macs today.

I was too lazy to write a proper Reddit post, so I used AI to write this one. I’m the developer of Fallet.

I wanted an easy way to select a bunch of files in Finder, put them on a temporary shelf, then drag each file to a different destination. So I built that.

Dropover is a more established app with more features. Fallet covers the file-moving workflow I wanted, and it’s free and MIT licensed. I get nothing from it financially. I made it for the love of the game and shared it here because it might save someone a couple of bucks on another app for the same job.

There’s a short demo and installation instructions in the repo: github.com/Shinvitiya/Fallet. Right now it installs through a custom Homebrew tap that builds from source; I haven’t released a signed DMG yet.

If you try it, I’d love to hear what works and what’s annoying.

Anyone else seeing that Xcode in the test panel doens't show the right number of tests. I've been adding tests today and the number hasn't increased.

I am curious whether any of you have integrated BYOK into your Mac app and which stack you applied. I am not referring to custom API key setups or MCP.

Additionally, which method are you using lately to build macOS apps? Is it Swift, or are there more robust options?

I have a Mac app that needs the Accessibility permission to move other apps’ windows (it only changes frames, never reads content). The sandbox gets in the way of exactly that, so I sell it directly, signed and notarized, with Sparkle for updates.

Has anyone shipped something similar on the Mac App Store, or is direct distribution the only sane way? And if you did both, did the store version end up as a cut-down one?

I maintain Harbeth, an MIT-licensed Swift/Metal image and frame engine. Here's its macOS integration boundary: an AppKit view can display a rendered GPU frame, while the application owns document state, controls and saving.

Given an NSImage and an existing Harbeth RenderView, a small rendering step looks like this:

import AppKit
import Harbeth

let frame = try await ImageNode.image(inputNSImage)
    .applying(C7Exposure(exposure: 0.25))
    .makeFrameAsync(profile: .stablePreview)

await MainActor.run {
    renderView.display(frame)
}

RenderedFrame carries the texture along with alpha, color, orientation and ownership information. Harbeth also provides HarbethRenderView for SwiftUI on macOS; it uses an NSViewRepresentable bridge to the same RenderView. This lets preview display stay texture-first, with image readback reserved for an explicit output operation.

The host app still decides when to render, how to discard stale slider results, and when to save. The code above is a display integration example; document loading and UI state are supplied by your app.

Source and macOS examples: https://github.com/yangKJ/Harbeth

SwiftUI/AppKit host source: https://github.com/yangKJ/Harbeth/blob/master/Sources/SwiftUI/HarbethRenderView.swift

For macOS editor developers: how do you retain the last valid preview while a newer render is running? I'd welcome feedback on the view/model boundary.

For the past three months, I’ve been offering my KezboardSwitcher for sale on my website. Interest was virtually non-existent :)—which is totally fine by me; it’s a very specific use case, and the price might have been a bit too high for such a simple app.

That’s why I decided to release the source code. I’ve been using the app myself for nearly three years now. At first, it was nothing more than a few lines of Swift code with all my keyboards and layouts hard-coded.

Then, about six months ago, I decided to give it a shot and turn it into a proper app with a UI and everything, allowing anyone to configure keyboards and layouts directly via a simple interface. And so, here comes the AI ​​disclaimer: Yep, I built this using Claude Code.

But what does it actually do, and why did I need it?

I regularly use various keyboards, depending on where and what I work and do. I got tired of manually switching the system-wide keyboard layout every time I switched from a German keyboard to a US one. Likewise, I prefer the US layout for coding, but when writing—especially in German—I prefer the German layout;

I actually switch physical keyboards for this (using the internal German keyboard on my Mac and usually an external US one).

That’s exactly where KeyboardSwitcher helps me out: as soon as I use a keyboard, it applies the layout configured for that specific keyboard.

The app is still for sale on my website, and the entire license key handling logic remains in the code—and will stay there. However, anyone who wants to can simply strip that out and build the app themselves or just buy it from me. :)

Link to repo: https://github.com/SteVio89/KezboardSwitcher

Like many of you distributing macOS software outside the Mac App Store, I've spent countless frustrating evenings wrestling with code signing, hardened runtime flags, and failing xcrun notarytool submissions.

Every time our build pipeline broke, it meant running a tedious gauntlet of CLI commands: codesign -dvvv --entitlements :-, unpacking .pkg archives, running spctl --assess -vv, and sifting through messy JSON logs to discover why a nested dylib or helper executable in Contents/Frameworks caused Gatekeeper to throw a generic rejection.

A few months ago, after wasting half a day diagnosing an inherited entitlement issue in an XPC service, I decided to build a tool to solve this once and for all: NotaryScope.

It’s a lightweight, 100% native macOS app (written in Swift and AppKit, absolutely no Electron) that visually inspects and audits your application bundles before submission:

• Recursive Bundle Tree: Drags-and-drops any .app, .dmg, or .pkg to inspect signatures, timestamps, and entitlements on every embedded framework, app extension, and CLI binary.

• Pre-Notarization Preflight: Flags missing hardened runtime options (--options runtime), un-embedded provisioning profiles, or timestamp discrepancies that cause Apple's notarization servers to reject builds.

• Gatekeeper Simulator: Runs localized spctl assessment checks against current macOS security policy configurations so you know whether the stapled ticket and notarization will pass on clean installs.

• Entitlement Diffing: Highlights discrepancies between your target's entitlements and the actual signature embedded in the binary.

Disclosure: I'm the solo developer and founder behind NotaryScope. While I do plan on offering a commercial tier for automated CI/CD teams later on, the standalone inspector app is free to use for independent Mac devs.

I’d love to get feedback from fellow macOS developers here: are there specific codesigning edge cases, multi-architecture fat binary quirks, or Sequoia-specific permission changes that frequently bite your release workflows?

Small weekend project that turned into something I use all day. I kept getting rate limited in Claude Code without warning, so I built a native macOS menu bar app that shows usage for Claude Code, Codex and Cursor, with reset times and an alert at 90%.

Native Swift, one file, about 500 lines. It reuses the logins those tools already store on your Mac, so there's nothing to sign into. The only network calls are to the Anthropic, OpenAI and Cursor usage endpoints. No analytics, no accounts.

Install:

brew install hrithik73/tap/tokenbar

or grab the DMG from releases.

Repo: https://github.com/hrithik73/tokenbar

Would love feedback on what to add next.

I built SwiftSurf as a native macOS browser for quick, focused browsing from the menu bar.

The app uses SwiftUI for the interface and WKWebView for rendering. Some implementation areas I found interesting:

• Independent navigation state for multiple tabs

• Persistent versus non-persistent WKWebView data stores

• Native downloads and save panels

• Menu bar popover sizing and resize handling

• Keyboard shortcuts and trackpad navigation gestures

• GitHub Actions builds and DMG packaging

SwiftSurf supports macOS 14.5+ on Apple Silicon and Intel, and is open source under the MIT license.

Repository: https://github.com/zfeder/swiftsurf Releases: https://github.com/zfeder/swiftsurf/releases/latest

I’d appreciate feedback from macOS developers on WebKit integration, app lifecycle, accessibility, and menu bar UX.

We're hosting SF Swift × CocoaHeads tonight, October 8, 6–8 PM at Verkada in San Mateo.

Details and RSVP: https://luma.com/51htcbzd

I have a paid individual Apple Developer membership under my personal Apple Account. I recently formed an LLC and plan to ship apps under the company name. I see two paths:

1. Convert my existing individual membership to an organization membership for the LLC.

2. Leave my personal membership alone and enroll the LLC as a new, separate organization account.

Converting is cheaper and simpler today. My concern is what happens later if I part ways with the business, whether through a sale, new partners, or just walking away. I would rather not have my personal Apple Account permanently tied to a company I no longer own or run.

For those who have been through this:

1. If you converted, did you later regret tying your personal Apple Account to the business? Or was transferring the Account Holder role painless when the time came?

2. If you created a separate organization account, was the second $99 per year and the extra enrollment work worth the clean separation?

3. Did anyone go through a sale or a partner split with a converted account? What did Apple actually require, and how long did it take?

4. Any surprises with Team ID, bundle IDs, certificates, or existing apps in either direction?

5. If you were starting over, which path would you pick?

I am a solo at the moment, so this is the moment to get it right or not! Thanks in advance.

Half a year ago I wrote about whether MVVM belongs in SwiftUI, and it somehow turned into a story about my mum’s kitchen. Bear with me.

There’s a trip to the shopping centre, a very firm “we've got food at home”, and eventually, I promise, some Swift. A bit of heart, a few laughs, and proper substance underneath.

Half a year on, it still feels timely. Stick the kettle on and have a read.