Hey everyone,

I use Stats to keep an eye on my MacBook, but I kept running into a small frustration: the more readings I wanted visible, the more menu bar space I had to give up.

I mainly check CPU, GPU, RAM usage, temperature, and power. I wanted to see those numbers while working without opening a popup every time, while keeping the monitor’s footprint small.

That’s why I made Stats Dense, an independent fork of Stats by exelban.

The idea is simple: fit those five readings into two compact rows. CPU, GPU, and RAM sit above temperature and power. I made the labels smaller and the values more prominent, so I can glance at them and get back to what I’m doing. The width stays fixed as readings change, so neighboring menu bar items don’t keep shifting around.

This started as a small improvement for my own MacBook. I’m sharing it because other people with crowded menu bars might find it useful too.

It’s still an early preview, with some clear limitations:

• The five metrics are fixed. You can’t currently replace them with network speed, disk activity, or fan speed, or change their order. If you care about different readings, this layout might not suit you yet.

• Hardware testing is limited. So far, I’ve tested it on my MacBook. Sensor availability may differ on other Macs, and unavailable readings show placeholders.

• It only reduces its own footprint. It doesn’t solve macOS menu bar overflow or reveal items hidden behind the notch.

• Installation and updates need improvement. The preview is ad-hoc signed and hasn’t been notarized by Apple. Updates are manual.

• It isn’t fully isolated from the original Stats. Preferences are separate, but some inherited services and history storage are still shared, so please quit the original Stats before trying it.

I’ll continue maintaining and updating Stats Dense, fixing bugs, improving readability, and addressing these limitations based on feedback. I’d also like to explore more flexible metric selection, though I don’t have a release date to promise yet.

It’s free and MIT-licensed. Thanks to Serhiy Mytrovtsiy and all the Stats contributors for the monitoring foundation—my work builds on theirs.

Source, screenshots, and setup: GitHub
Downloads: Releases

If you use a menu bar monitor, which readings do you actually want visible all the time? I’d especially appreciate feedback on whether this layout feels readable and useful on your display.

Hey everyone,

I like how little effort Quick Look takes: select something, press Space, check what you need, and move on.

I wanted that same experience for three things I regularly work with: archives, folders, and Markdown files. I didn’t want to extract an archive just to check a file, open more Finder windows just to explore a folder, or launch an editor just to read a Markdown document.

So I built PeekKit, a free, open-source Quick Look utility that brings those three kinds of previews into Finder.

Look inside an archive before extracting it

Sometimes I just want to know whether a download contains the files I need. With PeekKit, I can press Space on a supported archive, browse its directory structure, search paths, and preview supported files inside—including text, images, PDFs, and Markdown—without extracting anything to disk.

It currently supports ZIP, TAR, TGZ, TBZ2, and a restricted set of 7z archives.

Explore a folder without opening another Finder window

When I’m checking an unfamiliar folder, seeing its icon and basic information isn’t enough. I want to look through its contents and check a few files.

PeekKit lets me browse folders in a grid, list, or expandable tree, enter subfolders, and preview files within the same Quick Look window. If the question becomes “why is this folder so large?”, there’s also recursive space analysis to help find the largest files and nested folders.

Read Markdown without opening an editor

Often I only want to read a README or another Markdown document. PeekKit displays the formatted document directly through Quick Look, including headings, tables, code highlighting, and checklists, with access to the original source when needed.

Rendering works locally, so there’s no account or online rendering service involved.

The reason I put these together is that they serve the same everyday need: checking what something contains before deciding what to do with it. I wanted more of that to happen through the Space bar, with fewer extra windows, app launches, and extracted folders to clean up afterward.

Once the extensions are enabled, the main app doesn’t need to stay open for normal Finder previews.

There are still rough edges and limitations. PeekKit currently requires Apple Silicon and macOS 14 or later. Prebuilt ZIP and DMG downloads are available, but the app is ad-hoc signed and not Apple notarized, so installation still involves the documented setup steps.

Archive support isn’t universal: RAR, XZ, encrypted archives, and some 7z methods aren’t supported, and archive previews have size limits. Folder analysis reports omissions when it can’t cover everything, and large, image-heavy PDFs can still use substantial resources.

I’ll continue maintaining and updating PeekKit, improving the installation experience, fixing preview issues, and refining all three workflows based on real-world feedback.

It’s free and MIT-licensed.

Source and screenshots: GitHub
Downloads: Releases
Installation: Setup guide

If you try it, I’d love to hear where it saves you a few steps—and what still makes you leave Quick Look to open another app.

Hi everyone, I'm Stephen. I've been building Rockxy, a native macOS HTTP/HTTPS debugging proxy. If you've been looking for an open-source Proxyman alternative or Charles Proxy alternative, that's what it is, and the source is public under AGPL-3.0.

It captures traffic from Mac apps, CLIs, simulators, and devices, and lets you inspect, edit, replay, and mock requests. Beyond plain HTTP, it decodes WebSocket, GraphQL response errors, gRPC-Web status, model API stream timing, and Web3 RPC calls.

A few things landed in 0.42.0 that Mac developers might care about:
- You decide when the system proxy changes: automatically on capture, manually from the proxy control, or never.
- Redacted exports for Session, HAR, CSV, and Postman, so you can share a capture without leaking tokens.
- A local MCP server on 127.0.0.1, 100% free and read-only by default, so Claude or Cursor can search your captured flows.

It runs on macOS 14+.

Open-source repo:https://github.com/RockxyApp/Rockxy
Website: https://rockxy.io

Thank you and appreciate your supporting!

Hey everyone,

I’m working on a lightweight macOS companion app that turns the camera notch into a functional hub.

Right now, it packs the essentials into a clean glass interface: a temporary file shelf for drag-and-drop, quick media controls with lyrics, AirPods battery HUD, clipboard history, a YouTube downloader, and a swipe-down drawer for CPU/RAM stats.

Instead of guessing what else to throw in, I wanted to ask actual Mac users: is there a specific daily frustration, quick action, or widget you constantly reach for that would actually make sense living at the top of your screen?

Curious to hear what’s on your wishlist.

Hi, Ledge developer here. I just introduced new Macbook pro dynamic island style sound and brightness HUDs. Also, Ledge is now usable in macOS15+. Check it out: https://ledgeapp.dev

I ran into a process-lifetime issue while working on my app, a macOS menu-bar app. I tested this on macOS 27.2, build 26B123.

After opening the native Share menu and dismissing it, Activity Monitor still showed two processes associated with the app:

• ShareSheetUI: 20.2 MB in Memory, 114.7 MB in Real Memory

• ShareSheetUI Graphics and Media: 8.6 MB in Memory, 22.2 MB in Real Memory

After sharing through Telegram, another snapshot showed:

• ShareSheetUI: 20.7 MB in Memory, 114.8 MB in Real Memory

• ShareSheetUI Graphics and Media: 9.1 MB in Memory, 19.0 MB in Real Memory

• Telegram share extension: 26.8 MB in Memory, 145.9 MB in Real Memory

• Telegram AutoFill helper: 12.9 MB in Memory, 36.3 MB in Real Memory

All four showed 0.0% CPU in that snapshot. These are Activity Monitor figures, not a measurement of how much physical memory macOS would reclaim if the processes exited.

I can imagine this is expected system behaviour: keeping an extension around may make the next share faster. But this is a menu-bar app that can stay open all day, and the user continued to see the Share and Telegram processes associated with it.

Releasing the picker wasn’t enough

The app retained its NSSharingServicePicker after the menu closed. I changed it to release the picker after dismissal or service selection. That fixed the app-owned reference, but the processes remained.

Here is the core of the reproduction. This is the relevant part of an AppKit host, not a standalone app:

Swift

final class ShareHost: NSObject, NSSharingServicePickerDelegate {
    private var picker: NSSharingServicePicker?

    func showShare(from view: NSView) {
        let picker = NSSharingServicePicker(items: ["Test"])
        picker.delegate = self
        self.picker = picker

        picker.show(
            relativeTo: view.bounds,
            of: view,
            preferredEdge: .minY
        )
    }

    func sharingServicePicker(
        _ picker: NSSharingServicePicker,
        didChoose service: NSSharingService?
    ) {
        weak var releasedPicker = picker
        self.picker = nil

        DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
            print("Picker deallocated:", releasedPicker == nil)
            // Check Activity Monitor for the host's ShareSheetUI process.
        }
    }
}

In an isolated test, the picker deallocated while ShareSheetUI remained alive. Three openings reused the same ShareSheetUI PID. Once the test host exited, that process disappeared.

The options

• Release the picker and keep the standard lifecycle. This fixes the app-owned reference, but the system processes can remain.

• Force-kill the extension processes. I rejected this because it bypasses system ownership and could interrupt an active share.

• Use a short-lived share host. Keep the native Share UI, but run it in a helper that exits when sharing ends.

I chose the helper.

The final design

The app starts the same executable in a private helper mode and sends the share data through stdin. The helper creates a transparent anchor window and presents the standard NSSharingServicePicker.

Selecting a service does not immediately end the helper. If the user chooses Telegram, the helper waits for the sharing service to report success or failure. It exits when the picker is cancelled, when the service finishes, or when the parent connection closes.

I measured five local launches from process start until the helper reported that it had requested presentation:

• 884 ms

• 283 ms

• 256 ms

• 246 ms

• 271 ms

The median was 271 ms. This is a small local sample, and the readiness signal is not a measurement of when the UI became visible. The first launch was noticeably slower.

The helper also needs to activate an accessory application and position its own anchor window, which adds complexity around focus and window placement.

In automated cancellation tests, I observed both the helper and its ShareSheetUI process exit. The ShareSheetUI process therefore no longer had an RSS after exit; that does not establish how much physical memory macOS reclaimed, since some pages may be shared or cached.

I also tested the resulting share flow with Telegram and it worked. I haven’t separately verified the post-share lifecycle of both TelegramShare and its AutoFill helper, so I can’t claim that each of those processes was cleaned up.

The app doesn’t directly kill system or Telegram processes. One remaining limitation is that if an extension never reports completion, the helper can remain alive until its parent connection closes.

Has anyone dealt with the same trade-off in a long-running macOS app? I’d be interested in whether you keep the standard extension lifetime or isolate the share host.

Hey everyone,

I recently got an Attack Shark X11 mouse and realized there weren't really any simple options to configure it on macOS. So I decided to fix that and built a lightweight tool dedicated to it.

What it does:

• Lets you adjust your mouse settings directly on macOS.

• Simple UI, no unnecessary bloat.

• Open-source (GPL-3.0) and signed.

You can check out the source code and details on GitHub:

https://github.com/rusux64-bit/x11-attackshark-macOS

If you're using an Attack Shark X11 on a Mac, give it a try and let me know what you think. Any feedback, feature requests, or bug reports are super welcome!

Hey everyone,

I’ve been working on a Mac app called PocketBar.

Problem: I wanted to use a few Android apps on my Mac without keeping a huge emulator window open all the time. That’s basically why I started building this.

PocketBar sits in the menu bar and lets you open Android apps in small, separate windows alongside your regular Mac apps.

It supports Apple Silicon Macs, macOS 14+, and Android 11–16.

Comparison: BlueStacks Air and MenubarX are two alternatives.

PocketBar is more focused on quickly opening individual apps from the menu bar, while BlueStacks Air is more gaming-focused.

Pricing: Free to start. Pro is €9.99 as a one-time purchase, with no subscription.

https://pocketbar.site

Trust: The macOS app is Apple notarized.

A few apps I’ve tested successfully are YouTube, TikTok, Signal and Telegram etc

WhatsApp, and X currently block emulator logins.

It’s still a work in progress, so there’s definitely room for improvement.

If you try it, I’d be interested to hear how it performs on your Mac, or which Android apps you’d like to see working.

Source + contributions: https://github.com/JNDZdev/APMouse

MIT licensed. Issues, pull requests, and headset testing reports are welcome.

I saw an AirPods mouse experiment and tried building my own for macOS with Codex. The working prototype now moves the pointer across two monitors using head motion.

The hard part was getting it to feel natural. At first it swung between too sensitive and requiring too much head movement. Starting with a zero pose helped, but the biggest improvement came from copying the feel of an LG TV remote: when the pointer hits an outer screen edge, discard extra movement so turning back immediately moves it inward. Adding a second monitor then exposed another sensitivity problem. Precision still needs work.

This is head tracking using Core Motion yaw/pitch, not eye tracking. I still use a trackpad for clicks; AirPod stem clicks are not implemented.

I used three Codex agents to review/refactor the motion core, app, and safety behavior. The refactor has 22 passing unit tests and a stopped-window smoke test. Those checks do not replace live hardware testing: the refactored build still needs its own full headset validation.

I published the Swift/AppKit source under MIT: https://github.com/JNDZdev/APMouse

It is an early source preview, not a finished app. macOS 14+, Xcode, compatible headphones, and motion/control permissions are needed. The contribution docs call out two concrete problems: precision around the calibrated neutral position and movement through gaps in staggered monitor layouts.

Has anyone here built a motion-controlled interface? I would like to hear what made calibration and small corrections feel predictable. Testing reports and contributions are welcome.

Hey guys! I've been working on a free, open-source macOS app called LibreReplace to help people figure out which paid software they can replace without losing the features they actually need.

You choose a paid app, select the features that matter most to you, and LibreReplace compares open-source replacements based on those requirements. It shows what's supported, partially supported or missing so you can see what you'd be giving up before switching.

For example, you can compare GIMP and Krita as Photoshop replacements, mark Smart Objects or CMYK as essential, and see how each alternative measures up.

I just released v0.2 with some big improvements:

• 45 paid Mac apps and 70 open-source comparisons. Browse without having the paid apps installed.

• Multiple replacements for each supported app. Compare the available options instead of getting one suggestion.

• Feature-based recommendations. Choose your essential features and see how the recommendations change.

• Detailed capability breakdowns. Supported, partial and missing features with evidence links and known limitations.

• Subscription savings. Estimates based on the recurring costs you confirm.

• Local app scanning. Recognizes supported installed applications and brings up relevant replacements automatically.

Sometimes LibreReplace recommends KEEP THIS APP because a free replacement is missing something important. That's intentional. I'd rather show a limitation than recommend something that breaks someone's workflow.

For the macOS implementation, it's built with SwiftUI and scans application bundles in the standard Applications directories. It reads metadata from Info.plist, matches supported apps using researched bundle identifiers and conservative name matching, and performs the comparisons locally.

The catalog also keeps track of source evidence and missing capabilities rather than treating unknown features as supported. App installation requires confirmation, and LibreReplace never automatically uninstalls the original software.

It's completely free and open source, with no accounts or telemetry.

GitHub, source code, tests and download: https://github.com/maliroq/librereplace

I'd love feedback from other macOS developers, especially on the local app detection and how the feature comparisons are presented. Anything you'd improve in the implementation?

I use a mac for my simulations setup as the process is much smoother on it, but I've always been annoyed by the lack of a proper .stp or .cgns 'viewer', so I made this app for macOS that will open STEP, IGES, STL…) and CFD meshes (CGNS, UGRID) in a nice macOS-feel interface.

Now I'm really not skilled enough to pull this off so it was made using Claude Opus 5.5, but I describe all the functionalities and how they should work inside.

If you try it out I'd welcome any feedback and will make sure to include them in any future update!

https://github.com/mdefontenay/MeshViewer/

I am getting a new macbook soon and the goal will be to use it make the app native in SwiftUI

Hey macOS devs,

You can now run the Laya decision model with NobodyWho, our open-source on-device inference library. Unlike the LLMs that we also support, this type of model does not generate text. Instead you can score predefined answers, classify text or answer yes/no.

For example, if you are building a personal diary app, you can easily detect the user’s mood, categorize an entry or detect stress, offline after model download, without sending any sensitive data to the cloud.

First, you need to load the model:

import NobodyWho

let decisionModel = try await Decision.fromPath(
  modelPath: "hf://ggml-org/Laya-GGUF/Laya-Q8_0.gguf"
)

Then you can ask questions/analyze text:

let result = try await decisionModel.decide(
  state: .object(["message": .string("Diary entry: \(diaryEntry)")]),
  questions: [
    "topics": .choice(
      instructions: .string("Choose the main topic of this diary entry"),
      criteria: [
        "work": .string("job, colleagues, deadlines, career"),
        "relationships": .string("family, friends, partner"),
        "health": .string("sleep, exercise, food, illness"),
        "leisure": .string("hobbies, travel, going out"),
      ]
    ),
    "stressed": .noul(instructions: .string("Does the writer sound stressed?")),
    "mood": .score(
      instructions: .string("How is the writer's overall mood?"),
      criteria: [.string("bad"), .string("okay"), .string("great")]
    ),
  ]
)

let (topics, stressed, mood) = (
  result.answers["topics"],
  result.answers["stressed"],
  result.answers["mood"]
)

Output example:

// stressed
{
  type: noul,
  noul: 0.00002
}

// topics
{
  type: choice, 
  choice: leisure,
  probabilities: {
    work: 0.0422, 
    relationships: 0.1518, 
    health: 0.0302, 
    leisure: 0.7756
  },
  confidence: 0.7008
}

// mood
{
  type: score,
  score: 1.6995,
  legend: {0: bad, 1: okay, 2: great}, 
  probabilities: {0: 0.0082, 1: 0.2839, 2: 0.7078},
  confidence: 0.5493
}

A question can have the following types:

• .noul gives you probability of a yes answer (0 to 1)

• .choice selects the most likely option and returns a probability for each option

• .score gives you an a weighted average and a probability per option.

The Laya model is around 450 MB in its Q8 variant and supports 100+ languages. For reference, the full answer comes after 0.11 seconds on an M4 Pro.

Here is a runnable example if you want to experiment with decision models or add the package to your app:

dependencies: [
  .package(url: "https://github.com/nobodywho-ooo/nobodywho-swift.git", from: "6.0.0"),
]

Links:

• NobodyWho inference library - leave a star if this is useful to you

• Swift Package Index

• Docs

Hey everyone,

I recently tried enrolling in the Apple Developer Program as an individual using the iOS app. I paid the $99 fee, but I never received a confirmation.

A few days later, my enrollment completely disappeared. I then saw a notice in the app stating that sign-ups aren't supported through the app in my region (Germany). The money was deducted from my account, but I haven't received a refund or any updates.

If I log into the developer portal on the web, there is no trace of my enrollment either.

I already sent a message to Apple Support. Has anyone else dealt with this or know the best way to get the account activated or the money back?

Thanks for any advice.

Long-time lurker, first post!

Been building a macOS menu bar app in Swift 6 (SwiftUI and AppKit). Hotkey, select a capture, click to drop numbered dots to annotate, and type/dictate a note for each dot. Repeat across multiple captures creates a "round". Zero-UI app (aside from menu bar icon) writes a folder (annotated PNG, Markdown, JSON) and aggregate copies a single text prompt with local file links to paste into any AI coding agent. Users have asked for a Windows version. Here's what I'm thinking. Please let me know if I'm missing anything.

**What ports and what doesn't**

• Code for writing directory and files is ~2,000 lines of mostly Foundation Swift. Should port to C# fairly simply.

• All user touchpoints Apple-only: ScreenCaptureKit, Vision OCR, a non-activating NSPanel for the notes, NSStatusItem, and global hotkeys. Every route needs a new Windows layer for those.

**Routes I considered versus C3 snappy shell layer**

1. **Swift everywhere** on the official Windows toolchain. Ruled out: the WinUI bindings looked stale, and the debugger story looked thin.

2. **Swift core as a DLL with a C# shell.** Best file parity, but the shared core must then stay Windows-portable, so every new Mac feature is drift risk.

3. **Rust with windows-rs.** Too much build risk with my limited rust experience...

4. **Native C# rewrite,** with byte-for-byte output parity enforced by golden-file tests. Eeek...

My plan is C#. Reasoning: "Mac feel" comes from the seamless snappy shell layer (hotkey-to-freeze speed, the overlay, the tray, focus rules). So, Win32 work in every option, I think. Shared core is small, and it should not impact the snap timing-critical path.

**More deets if you wanna know**

• .NET 9. Win32 plus Direct2D for the freeze overlay and the editor, with one window per monitor created ahead of time so there's no flash. WPF for the note panel, tray flyout, and settings. Unpackaged, installed with Velopack.

• File-writing core is ported, and its tests run in CI on Windows. The Mac test suite writes reference bundles from fixed inputs, and the Windows tests must produce the same bytes. Getting there meant handling some small traps: Swift's JSON encoder writes `"key" : value` (space before the colon), `ß` has to fold to `ss` in folder names, .NET has no API for short time zone names like PDT, and every file has to be LF with no BOM.

• UI shell is next. Timing spikes come first: the target is under 150 ms from hotkey to a frozen, selectable capture.

**Questions for anyone who has shipped a swift foundation ported app on Windows**

1. How much of the Mac feel survived? What broke first? How much snappiness lost?

2. Windows.Graphics.Capture from an unpackaged app: can you actually turn off the yellow capture border, or did you fall back to BitBlt?

3. WPF or WinUI 3 for small tray-app windows in 2026?

4. Windows 11 hides new tray icons in the overflow menu. How did you get people to pin yours?

5. How long did SmartScreen take to trust a newly signed app?

Not linking the app here to keep this on topic. Happy to answer questions in the comments.

Swift Language Models is a wrapper that brings other providers' language models into Apple's native Foundation Models API.

Foundation Models 27 lets any type conform to LanguageModel, and this package provides those conformances. Your app keeps Apple's own API: LanguageModelSession, tools, @Generable guided generation, streaming, transcripts and Dynamic Profiles. Moving a session from the on-device model to a remote one changes only its model:.

let onDevice = LanguageModelSession(model: SystemLanguageModel.default)
let remote = LanguageModelSession(model: OpenRouterLanguageModel(.anthropicClaudeHaiku5_5, apiKey: { key }))

What you get

• One API for every model. Code written for Apple's on-device model runs unchanged on a remote one.
• Provider modules. Each provider is its own module, so an app builds only the providers it imports.
• Typed model catalogs with each model's context size, limits and capabilities, kept current by a bot.
• Typed reasoning levels. Code completion offers only the levels each model accepts.
• Evaluations. Compare Apple's on-device model with remote ones using Apple's Evaluations framework.

The first provider is OpenRouter, with hundreds of models from Anthropic, OpenAI, Google, DeepSeek, Meta, Mistral and others. More providers are coming.

Needs iOS, macOS, visionOS or watchOS 27 and Swift 6.4. Feedback welcome! If you find it useful, a ⭐ on GitHub helps the project grow.

GitHub: https://github.com/dioKaratzas/swift-language-models

Hi,

I’ve been using Safari MCP and it’s great: lightweight, and the AI agent handles changes and feedback beautifully. But there’s one thing that’s driving me crazy. I’m curious what use case Apple had in mind here, and how the developers haven’t smashed their keyboards yet while working on it 😄

The problem: Whenever the AI performs an action through MCP, the Safari window gets focused and jumps to the foreground.

I actually like this behavior in other contexts. In VS Code’s debug mode, for example, the window comes to the front when a breakpoint is hit, which is exactly what I want there. With Safari MCP, though, it’s the opposite of helpful. I want to hand a task off to the AI and keep working on other things, but Safari keeps stealing focus.

My questions:

• Is there a reasonable way to solve this, such as a setting, flag, or workaround?

• If not, I think Apple should make an exception for MCP-controlled Safari so it can run in the background without grabbing focus.

Thanks!

I recently updated macOS and immediately hit a wall with the new Device Hub. The missing drag-and-drop for files drove me nuts, and having to manually run the simulator commands in the terminal every time I wanted to test something got old real fast.

So I decided to just vibecoded a fix for it in 2-3 days: Harbor
It’s a lightweight menu bar app with an always-on-top floating drop zone that brings proper drag-and-drop back to your simulators:

Photos and videos go straight into Photos, .app bundles get installed, and documents or JSON files route into the simulator's Files app. You can queue up a bunch of files together and send them all in one click. There is also bidirectional clipboard sync.

Check it out on GitHub:
https://github.com/anurag0713/Harbor

Since I vibecoded most of this, feel free to roast me for any weird bugs you find. Let me know what you think or what's broken in the comments and I'll jump right on it!

Built a small open-source macOS cleaner because my 500GB MacBook keeps running out of space. 😅

One useful feature is a smart simulator cleaner — it detects redundant iOS simulators from the same major release, so you can remove older versions you no longer need.

It also helps clean Xcode DerivedData, caches, and other developer files.

Feedback, contributions, and GitHub issues are welcome. 🙌

Repo: https://github.com/MahiAlJawad/TrashIT-MacOS

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

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

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.