macOS feedback wanted — signed builds ship every release, but the maintainer develops on Linux

[ArthurDEV44]

Context

Paneflow ships a signed + notarized macOS build (Apple Silicon, macOS 13 Ventura+) with every release, and macOS is a first-class target — Metal rendering via GPUI, Homebrew cask, in-app auto-update. The catch: my daily driver is Linux, so macOS coverage relies on CI and occasional manual passes rather than daily use.

If you run Paneflow on a Mac, your feedback is the main safety net between releases.

How to help

Install the latest release:

brew tap arthurdev44/paneflow && brew install --cask paneflow
# or grab the .dmg from https://github.com/ArthurDEV44/paneflow/releases/latest

Anything you notice is welcome, but these areas get the least eyes-on-Mac time:

• Rendering (Metal): font crispness, ligatures, scrolling smoothness, multi-display / mixed-DPI
• Keyboard: Cmd+C / Cmd+V / Cmd+Q, and option_as_meta behavior (Option as Meta prefix vs typing Unicode characters)
• Window chrome: custom title bar, fullscreen, Mission Control behavior
• Auto-update: the in-app updater swapping the .app in place across versions
• Agent CLIs in panes (Claude Code, Codex, opencode, …): launch, status dots, desktop notifications
• Dock icon: sizing next to other apps (new keyline since v0.4.2)
• IPC / MCP: paneflow mcp install and the socket under $TMPDIR

Reporting

Even a "works fine on my M2, Sonoma 14.5" with your hardware and macOS version is valuable signal. For problems, the bug report template captures the details.

Intel Mac user? x86_64-apple-darwin is currently out of the build matrix — a 👍 or comment here from Intel users helps me gauge whether to bring it back.

[laywens]

nice work

hey, just wanted to say, first off, this is a hell of a job you just pulled together here with this app @ArthurDEV44 . my baseline/fallback app is Zed using terminal agents in the left side panel, but i will spend many sessions every week trying out a new terminal multiplexer type app, and what you've built feels exceptionally smooth and polished with how it feels and renders graphically. it's hitting a lot of the pain points I feel with other terminal multiplexer type apps and still stays lean and focused. Fonts and edges are crisp. Placement of elements is nice in the agent mode. And so far I've had no issues that are showstoppers after using the interface after multiple sessions with Claude Code, Codex, GLM via Opencode, and GLM via Droid cli.

My local dev environment is an Apple M2 Max with 96gb ram. I also use an i3 Lenovo 8GB laptop running xfce when I travel but I haven't used paneflow on it yet.

Feedback/Observations

Context/Use Cases

One of the main things I'm going to be keeping track of is how easy it is to move between branches and work trees while using (a) a main coding agent, (b) review agents and (c) occasional third-party/custom cli's running from terminal for auditing. My use cases: hook-driven infra tool development, local audio/music gen, ASR-related apps, visualization tools for designers.

Toggling between CLI/Review/Agents

So far the only UI feedback I would have is that there's this three-button toggle that appears in the left-hand vertical column/bar that when you select the switch interface button, it reveals the CLI, review, and agents buttons.

It feels a bit like a tab bar on the bottom, which is great but the group disappears once you select one of them, and the settings buttom takes over again. For me, in just my workflow, I imagine it would be more comfortable/easier to orient if those three tabs persisted rather than the settings tab take over. So, I think there's something there about optimizing that section of the UI that might be worth exploring...

Persisting system-level menu items

while in the app's settings, the main system-level menu drop-down items are active

outside of settings, i.e. in agents/terminal, the menu drop-down items are disabled

This can feel a little disorienting to mac users (or at least me, lol), who might be confused as to why those menu options are disabled.

Terminal 1 tab in CLI

i was wondering about the decision to keep the Terminal 1 labeled vertical tab persistent in the CLI view. I've noticed my eyes seem to be kind of tracking between the terminal tab inside the main window and the left-hand labeled terminal tab in the vertical tab section.

Minor distraction or just my unaddressed OCD perhaps. However, given that that Terminal 1 tab defaults to the root directory, I can't think of a use case in which I'd want to launch from there, and accordingly a use case for that tab in general. This is speaking as a Mac user where I'm very infrequently outside of my home folder during dev work.

keyboard driven navigation: workspaces

While it didn't seem conventional for macos, I've gotten used to the idea of cmd-T to switch between CLI workspaces, kind of like cmd-tab in other apps/contexts. One thing that makes the command tab useful is that you can modify it with a shift key to reverse the direction of switching (cmd-shift-tab). Something like that might be helpful here if you want to keep cmd-T as the switching hotkey. It might also be helpful to persist that in the Agents view so it's easier to switch between panes as well.

RAM usage

i'm lucky to have a fairly comfortable window of RAM available, but based on my work in audio/video gen, I do need to have a pretty big margin for bursty processing. So keeping RAM usage relatively low is also important for apps I have constantly in the background/foreground. I've noticed that with Paneflow, it seems like RAM usage is about neck and neck with Zed when I start running 5 or more agent sessions. In Zed, I'm running sessions and I have LSPs and other app-overhead running. My assumption is that an apples-to-apples comparison of an 6-8 agent sessions running in paneflow vs 6-8 sessions in Zed, would show an overall lower RAM usage overhead with paneflow. For me, that would make switching from Zed more compelling.

about the app name and voice transcription

Phonetically, "pain" / "pane" might sound similar, but they can mean quite a different thing between English and French speakers :) When I use voice transcription apps and try to pronounce the name of this app, I will say "pane flow", yet the transcription always resolves to "Pain flow", or in noisy environments, it resolves to "painful". I don't bring this up as feedback saying you should change the name; go with your instincts, don't doubt yourself! I just wanted to point it out if you hadn't been getting a lot of feedback from English speakers that used voice transcription.

Keep going, careful about the bloat

You're really off to a great start here. I'm encouraging you to keep going. I may not have a ton of time for feedback, but I'll try to provide it when I can. The only final parting advice I would give is to be careful about feature bloat. Apps like cmux started off strong, but I believe they are plagued by the vast amount of requests coming in and the feature development rate hasn't kept up with the bug/issue resolution backlog, so it just doesn't make a compelling case over using Zed (for me) anymore.

[ArthurDEV44]

Hey @laywens, thank you so much for taking the time to write such detailed feedback.

This is exactly the kind of feedback I was hoping to get when I opened this issue. You understood the approach behind Paneflow really well: a tool built for multi-agent workflows, smooth, sharp, and deliberately focused. The goal is not to rebuild a full IDE or a huge multiplexer, but to make those sessions much more pleasant to drive day to day.

Your points are really relevant.

The CLI / Review / Agents switch clearly needs more work.

For the macOS menus, that feels different. It looks more like a native integration issue than an UX choice, so I will treat it that way.

The feedback about Terminal 1 is very useful too. I cannot reproduce it on Linux or Windows, so I will check whether this is a macOS-specific behavior or some session/restore state that brings that terminal back in the wrong place.

For keyboard navigation, the idea of a reverse direction makes sense. I want to move in the same direction as Zed: workflows should be controllable from the keyboard, with usage that becomes natural very quickly.

The RAM point matters too. Paneflow has to stay lean, especially when several agents are running in parallel. I will go deeper on the memory work I have already started.

On the name, thank you for bringing it up so directly. As a French speaker, I mostly had “pane” and “flow” in mind. But if a native English speaker can easily hear “pain flow” or “painful”, that is a real signal. I was already starting to question it, and your feedback makes that much more concrete.

And the feature bloat point is probably the most important one long-term. I really want to avoid that. Paneflow has to stay reliable, stable, fast, and focused on the workflows that matter. I would rather strengthen the core of the product than keep stacking features that make the app less clear.

Thanks again. This kind of feedback is extremely valuable, especially coming from someone already using Zed, several agents, and workflows close to the ones Paneflow was built for.

[ArthurDEV44]

A draft PR is ready for macOS testing: #16

It adds global GPUI/AppKit fallbacks so native menu items remain available outside Settings, especially in the CLI, Agents, and Review views.

Local checks pass (fmt, diff --check, cargo check, clippy). I plan to validate the fix soon on an Apple Silicon machine via Scaleway.

[ArthurDEV44]

Update: Paneflow v0.6.1 includes the first batch of fixes and improvements shaped by @laywens' detailed macOS feedback in this thread.

Release notes: https://github.com/ArthurDEV44/paneflow/releases/tag/v0.6.1

I'm keeping this issue open as the main macOS feedback thread. Future macOS-specific fixes and releases will be linked here too, so users can track what changed and keep sharing feedback in one place.