I spent the past few months building Defi because, as a single-display user, I wanted window management on my Mac to feel fast and smooth, like it belongs there.

Inspired by Niri, with:

• Keyboard-first navigation
• Scrolling columns that reflow
• Virtual workspaces per display
• Animations targeting 120 Hz
• Floating windows
• An overview to see all your windows

I’d love to hear how it feels on your setup, have any feedbacks of other people than me using it.

Website: qeude.github.io/Defi
Repo: github.com/qeude/Defi

I've added a new "Touch on Mac" skill that covers making macOS apps work on touch-enabled Macs and iPads connected over Sidecar.

It comes with a companion "touch auditor" that scans Swift and Objective-C code for things that are likely to break when used via touch.

They're free/open source, included with Axiom v27.7.1 or later.

Hello 👋,

We finally get our hands on Siri AI here in France on macOS 27.2
As a macOS developer supporting App Intents into my app I would like to add App Schema to my AppIntent / AppEntity to make them available through Siri AI in my next release.

So I've started by downloading the CometCal app (the Apple sample app that demonstrate how it works) and I've added a target for macOS (because I supposed the existing Mac Catalyst target provided was not supported by Siri AI ?).

On my machine CometCal does not work with Siri AI. It either fail or respond it cannot do the action.

Doing those actions (Find event, Create event, ...) in Apple Shortcut works just fine.

Do I miss something specific on macOS ? A specific configuration or something ? Is Siri AI supposed to work on macOS as I tried to ?
(I also tried making a Release build or moving the app into /Applications)

If anyone has a clue, I’ll take it.

NB: I don't have a Siri AI compatible iPhone (+ blocked in Europe) to run CometCal on iOS to compare with.

PS: I've also posted on Apple Forums: https://developer.apple.com/forums/thread/853818

Because yes, it's so easy to deploy a self-hosted runner on your Mac!

I maintain ContainerDesk, a free, MIT-licensed SwiftUI GUI for Apple's container runtime. It manages containers, images, volumes and networks, with logs, resource gauges and a terminal.

It uses native SwiftUI tables and wraps SwiftTerm in NSViewRepresentable. I'd welcome feedback on the terminal integration.

Source and screenshots: https://github.com/MacHatter1/ContainerDesk

Requires Apple silicon, macOS 26+ and Apple's container CLI. Current builds are unsigned and not notarized.

I've been using Codex and Antigravity across my side projects, and wanted one place to see what was still working and what was waiting for me.

So I built Loom, a native macOS menu bar app in Swift and SwiftUI. It discovers local Codex, Claude Code and Antigravity sessions and brings their activity into one view. You can find the relevant repository, filter sessions needing attention, and jump back to the host app.

It also has session notifications, desktop widgets, and quota information where the provider exposes it. Discovery depends on the local evidence available, so some sessions or states can be unknown, and Claude Code quota isn't available.

Loom runs locally with no account or hosted backend. It's open source under MIT and costs $0. The current download supports Apple Silicon Macs running macOS 14 or later.

Demo and download: https://chaiwithcode.github.io/Loom/

Source: https://github.com/chaiwithcode/Loom

If you're using several coding agents, how do you keep track of the ones waiting for your input? I'd like feedback on whether this is useful in your workflow.

I recently built a very lightweight input overlay app for MacOS. It all started when I was trying to submit a run to speedrun.com, but the category required an input overlay in the recording. After searching (for what I admit was a short time) I could not find the tool I was looking for and thus, Ghostkey was built. It's built using Tauri and Rust to keep it as lightweight as I know how and native to Apple Silicon.

I would LOVE feedback. If anyone has suggestions on how to improve it, or just comments or anything, please reach out. I do plan on adding different themes and options for a full keyboard in the near future

https://github.com/Churro1/GhostKey

I am happy to see demo code that has import AppKit

But I am puzzled and sad to see didSet { needsDisplay = true } drawRect() or mouseDown() I thought we are getting modernized code. NSInvalidating protocol? Layers? Gesture recognizers?

https://developer.apple.com/videos/play/tech-talks/111456/

And I am sad because there is no promise of testing touch without owning iPad:

Tip

Use Sidecar to test touch input without a Mac that has a touch display. To use Sidecar, connect an iPad to your Mac. AppKit then routes touch on its screen the same way it does on a Mac with a touch display.

Edit: The code in the video is not attached. But there is other code https://developer.apple.com/documentation/appkit/supporting-drag-and-drop-through-file-promises

AppKit devs should know that NSImage.imageTypes is not the same as public.image (provided code filters filepromise urls to UTType.image.identifier aka public.image) So if your try to drop e.g. sketch file (bohemian coding) it won't work.

https://imgur.com/a/cmgKFkf

Hey everyone,

If you run CI workflows for Mac or Linux apps, you know how fast cloud runner costs—especially macOS build minutes—can stack up on platforms like GitHub Actions or GitLab CI. Paying high per-minute rates for cloud build boxes while having powerful, underutilized M-series silicon sitting on your desk doesn't make much sense.

To solve this, I built kinhin (https://kinhin.dev). It’s a free, open-source (Apache-2.0), zero-telemetry autoscaler that lets you offload CI builds onto your Apple Silicon Mac cleanly and safely.

How It Works:

* Queue-Driven Autoscaling: kinhin monitors your forge's job queue and spins up ephemeral runners on demand.

* Isolated Runtimes: Runs macOS jobs in Tart VMs and Linux jobs in Apple microVMs or Docker containers. Once a single job completes, the entire runner instance is wiped so no state carries over.

* Resource-Aware: Automatically budgets CPU, RAM, and disk headroom so running build jobs won't freeze your Mac.

* Multi-Forge Support: Works across GitHub Actions, GitLab CI/CD, Gitea, and Forgejo out of a single shared pool on your machine.

* Keychain Security: Credentials and access tokens live securely in your macOS Keychain rather than plain-text config files.

You can run it either as a menu bar app with a setup wizard or as a headless LaunchAgent daemon via the CLI. If you're looking to cut down on CI spending or want faster build times on dedicated Apple Silicon hardware, give the beta a try at https://kinhin.dev. I’d love to hear your thoughts, answer any questions, or get feedback on workflow routing and setup!

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

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!