Sometimes the best software comes from scratching your own itch. That’s definitely the case with BarCuts, my take on a contextual macOS Shortcuts launcher. What started as a personal annoyance turned into a proper little utility that I’m genuinely proud of – and it’s been quite the journey getting here.
The Problem That Started It All
Picture this: you’ve got dozens of Shortcuts workflows on your Mac. Some are for processing files in Finder, others for grabbing URLs from Safari, maybe a few for formatting text in your notes app. But they’re all just sitting there in the Shortcuts app, or worse: in Shortcuts' own menu bar, mixed together in one giant list with no context about when you’d actually want to use them.
I kept thinking: wouldn’t it be nice if the right workflows just appeared when you needed them? Like, when I’m in Finder, show me my file-processing workflows. When I’m in Safari, Chrome, Edge, or another browser, show me my web-related ones. Context-sensitive launching, basically.
Turns out, that’s exactly what I ended up building.
What BarCuts Brings To The Table
As an example, let’s pretend you have a Shortcuts workflow named “Get today’s appointments” which fetches your appointments from the calendar, and which you only ever need when working in Notes. Here it is in the Shortcuts editor:
You want this workflow to be available in BarCuts whenever the Notes app is in front. So you’ll find the floating panel titled “BarCuts Tagger” next to the window, and “tag” Notes as a related app to this Shortcuts workflow, as shown above.
Now, BarCuts' menu will list the workflow when Notes is the frontmost app:
And that’s all there is to it!
The menu can be opened with the mouse, but you can also configure a global hotkey that will open it, in the app’s Settings tab. Alternatively, you could also hook up BarCuts to Alfred, or connect it to your Raycast.
Timeline, or: Everything’s A Journey Now
Prototype: Actions-Based Tagging
My initial approach was pretty straightforward (and, in hindsight, a bit naïve). I created a special Shortcuts action called “BarCuts Tagger” that you’d add to your workflows. You’d configure it with the app you wanted to associate the workflow with — say, “Finder” — and BarCuts would watch for when that app was active and surface the relevant workflows in its menu bar.
It worked! The concept was solid, and I was pretty pleased with the initial implementation. Little did I know there was a significant problem lurking that I wouldn’t fully appreciate until later…
The Public Beta
In February 2025, two weeks after starting the project, I launched the public beta, and the initial feedback was encouraging! People got the concept and found it useful.
Shortly thereafter, I properly launched version 2025.1. 🚀
Version 2025.2: A Reality Check
But as I was working on version 2025.2, I started hearing from more users about a problem I hadn’t fully grasped initially. To be honest, most of my own tagged workflows are macOS-only anyway, so I rarely ran into the sharing or iOS compatibility issues that were frustrating other people.
I realized there was this massive, glaring problem with my original approach: your workflows were no longer “clean.” They had this Tagger action cluttering them up, which meant:
- You couldn’t share them with anyone who didn’t have BarCuts
- They’d throw errors on iOS (where BarCuts obviously doesn’t exist)
- Your beautiful, artisanal workflows suddenly had this extra cruft in them
My practical approach turned out to be the opposite of elegant.
Despite this workflow pollution issue, I kept working on BarCuts because the core concept was still solid. Version 2025.2 was all about “connectivity”: I added proper scripting support, built companion extensions for Alfred and Raycast, and included a CLI tool for my fellow automation nerds.
Because a launcher like that shouldn’t be a closed system. If you prefer launching workflows from Alfred or Raycast instead of the menu bar, great – you should be able to do that and still get the contextual filtering that makes the app useful.
I also finally got around to writing proper documentation.
Version 2025.3: Polish and Fixes
Better settings, fixed some annoying bugs, improved the workflow execution system. The kind of update that doesn’t look like much from the outside but makes everything feel more solid and reliable.
During that time my old #1 problem was rearing its fugly head again: building the software is actually the easy part. Getting people to notice a new Mac utility? That’s the real challenge. Turns out there are lots of great apps that barely anyone knows about because, well, marketing is hard. Who knew?
I was trying to get the tech news and pundits interested in earnest. Nobody cared. 🫤
Version 2025.4: The Present
And that brings us to the latest update, which I’m genuinely excited about because it finally got around to solving that nagging workflow pollution problem I mentioned earlier.
I completely replaced the old Shortcuts action approach. Instead, BarCuts now adds a floating “BarCuts Tagger” panel directly to the Shortcuts editor. When you’re editing a workflow and BarCuts is running, you’ll see this lovely little panel floating next to your workflow window:
Here’s the nice bit: your workflows remain “clean”. No more BarCuts actions. You can share them with anyone, run them on iOS, whatever – they’re just normal Shortcuts workflows, as they should be. Lesson learned.
To tag a workflow now, you open it in Shortcuts and use the floating panel to tag it to whichever apps you want. You can even tag a single workflow to multiple apps if it’s useful in different contexts. Or put it in a submenu for even more structure.
All existing tagged workflows get migrated automatically, and if you still have old BarCuts actions lying around, the app will help you clean them up.
How It Works Today
The current BarCuts experience is dead simple:
- Install the app and grant it the necessary permissions
- Open any workflow in Shortcuts
- Use the floating panel to tag it to relevant applications
- Switch to one of those apps, and your tagged workflows appear in the BarCuts menu bar
That’s it. No actions to configure, no workflows to modify, no compromises on shareability.
Why This Matters
Look, I know there are lots of ways to launch Shortcuts workflows. Spotlight search, the Shortcuts app itself, various launcher apps – they all work fine for what they do.
But BarCuts does something different: it surfaces the right workflows at the right time. When you’re in Finder and want to process some files, you don’t want to see your Safari bookmarking workflows cluttering up the list. When you’re writing in Notes, you want your text-processing workflows front and center, not your photo editing ones.
It’s about reducing cognitive overhead. Instead of remembering which workflow does what and hunting through lists, the relevant ones just appear when you need them.
And now, with the floating panel approach, you get all that contextual goodness without any of the workflow pollution that was holding people back.
What’s Next?
I’ve got a proper backlog of ideas for future updates. Keyboard shortcuts for the menu, bulk workflow configuration, maybe some deeper integration with other automation tools – the usual “wouldn’t it be cool if…" stuff that keeps me up at night thinking about software.
But for now, I’m pretty chuffed — chuffed!! — with where BarCuts has ended up. The core concept is the same as when I started, but its implementation is cleaner now.
Give It a Whirl
If you’re a macOS Shortcuts user who’s ever felt overwhelmed by a growing collection of workflows, BarCuts might be worth a look. There’s a 14-day trial, no strings attached, and the app works with macOS 14 and later.
You can download it from the website, and if you want to chat about automation or share your setup, the ActionsDotWork Forum is full of friendly folks who love this stuff as much as I do.
P.S. Building and launching an indie Mac app has been quite the education. If you’re curious about that journey — the technical challenges, the marketing struggles, the weird satisfaction of solving problems for yourself and maybe a few other people — drop me a line. Always happy to chat about the indie dev life!
