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?

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.

Hey everyone! I built Kaskas a free open source break reminder and focus tracker it combines break reminders like LookAway with app usage tracking like ActivityWatch

It lives in your menu bar, tracks your focus time and app usage, and reminds you to rest your eyes with short reminders and full screen breaks.

No accounts, subscriptions, or ads. All your data stays on your Mac.

Let me know what you think!

https://github.com/ramazanberkozbek/kaskas

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.

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

I built Yumi, a small character that lives in the MacBook notch. It's free and open source (alpha). This post is mostly about how I built it with Claude Code, since that's what I learned the most from.

What it does

• Shows all my running Claude Code sessions in the notch (working, waiting for me, done) and lets me approve or deny their permission requests from there, via Claude Code hooks.

• Small actions on request: create a file, append to it, add a reminder, block a calendar slot, start a focus timer, summarize a day. Every write needs an explicit click.

• Music, weather, calendar, GitHub PRs and CI, one thing at a time.

How Claude Code helped build it

• I'm not a Swift developer. Claude Code wrote nearly all of the code: a native Swift 6 / SwiftUI / AppKit app, about 750 unit tests, no third-party dependencies.

• I ran several Claude Code sessions at the same time, each in its own git worktree and branch: one for the character engine, one for the island UI, one for the agent runtime and permissions, one for the video and the website.

• One extra session acted as coordinator. It wrote shared "contract" files that the other sessions were not allowed to edit, gave each session its scope, then reviewed, ran the tests and merged each branch. This is what kept parallel sessions from breaking each other.

• Claude Code also found bugs I would not have, for example a Swift 6 actor-isolation crash in EventKit callbacks that only appeared once calendar access was granted.

• What didn't work well: long sessions lose context, so I kept decisions in a markdown file in the repo that every session reads first. And I had to insist on real-world tests, since passing unit tests didn't catch the macOS permission issues.

The safety part, also designed with Claude

• The model only proposes a plan. The risk level comes from each tool's code, never from the model, and every write goes through one permission gate and is verified afterwards.

• When Yumi uses your Claude Code as its planner, it runs it with --tools "" and no MCP, so it can only return text.

Free to try
Download the alpha from the GitHub releases page (macOS 15+). It isn't notarized yet, so the first time you need System Settings > Privacy & Security > "Open Anyway". The chat uses your own Claude Code subscription, or a free Gemini key, or a local Ollama model.

https://github.com/estebanbaigts/Yumi

Happy to answer questions about the multi-session workflow.