created an app to make ntfs work on mac, without any GUI and anything extra, just the ntfs on your files like it was always there!

it's free and open-source and built on C

https://github.com/ninerf/NTFS-C

I was just approved for 2.1.0 last week and both of these two build bump updates with tiny changes got put into a review queue. What is this? Did I miss this announcement?

Hi everyone! I’m looking for early testers for Notchest, a native macOS app that brings developer tools and everyday utilities into an expandable panel near the Mac’s notch.

The current public build is 0.6.0. It includes an interactive terminal, developer utilities, Codex/Claude Code usage statistics, a focus timer, notes, optional clipboard history, and a file shelf.

I’m especially interested in feedback on:

1. Installation: Is the download and first-launch process clear?
2. The interface: Do opening, closing, resizing, and switching sections feel smooth?
3. Daily use: Which tools are useful, confusing, or unnecessary?
4. Your setup: Does it behave correctly with an external display or a different macOS version?

If you already use Codex or Claude Code, feedback on the usage panels would also help. Those integrations require their own local setup.

Compatibility: The packaged build is for Apple Silicon. Source targets macOS 13+, with testing across older versions still in progress.

Signing status: This is a development build and isn’t Apple-notarized yet. macOS may show a first-launch warning; the website provides the explanation and opening instructions.

The app is free and open source, with no subscription.

Demo & download · Source code · Report an issue

You can leave feedback here or on GitHub. Including your Mac model, macOS version, and whether you use an external display would help me reproduce any issues.

Thanks for helping shape the next version!

Wondering if this lead time for a review is normal for MacOS apps? Never had to wait this long for an iOS review before.

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.

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.

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

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.

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 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.

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 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 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?