A radial menu for Mac developers (and VS Code users)

The VS Code command palette is a masterpiece of developer UX. Cmd+Shift+P, type three letters, run anything. If you live inside one editor, it's the best launcher ever shipped.

But developers don't live inside one editor. A real day looks more like this: VS Code → Chrome → DevTools → terminal → Slack → VS Code → Postman → GitHub → VS Code. The command palette has nothing to say about the transitions between those apps. That's where we lose time, and it's where a radial menu is worth setting up.

This post is about the developer's version of a Swik layout — what to put on the top ring, what belongs in sub-menus, and how Apple Shortcuts turn a wedge into a package.json script without the typing.

The developer's launch loop

I count my own transitions during a normal coding afternoon. It's absurd. Writing a feature means I open the browser to check a design in Figma, swap to DevTools to inspect a component, hop to the terminal to run a test, drop into Slack because someone pinged me, come back to VS Code. That's five app switches for one "write this component" task.

On Cmd+Tab that's five tax payments — half a second each, plus the cognitive work of visually picking the right icon from whatever order the switcher put them in. On a keyboard launcher it's five of: trigger, type, enter. On a radial menu it's five flicks, each with no visual search because the positions never move.

The gain isn't really about milliseconds. It's that app switching stops pulling focus off the task. You never stop thinking about the component because your hand knows where the browser is.

VS Code complements a radial menu, and vice versa

This is the key framing: they do different jobs.

There's no overlap because the question "which tool?" is answered by "where are you going?" Inside the editor: palette. Outside the editor: radial.

The developer's top ring

Five wedges. Resist putting in more until you've used this layout for a week.

• VS Code (or Cursor, or Xcode). The return-to-work wedge. You leave it constantly; you want to come back to it without thinking.
• Browser. Whichever one you actually use for development. Chrome if you live in DevTools; Safari if you're doing iOS web work; Arc if you like profiles.
• Terminal. iTerm2, Warp, Ghostty, whatever. The app, not a specific session — tmux or your shell handles that.
• Chat. Slack for work, Discord for open-source, both if you do both. Pick one for the top ring; the other can live in a sub-menu.
• Notes or docs. Obsidian, Notion, Apple Notes, or a personal wiki. This is the "scratch brain" wedge — you reach for it to note a finding, paste a query, capture a link.

Five is the right number because spatial memory works best with distinct quadrants. You can cram in twelve but the ring stops feeling positional and starts feeling like a crowded menu you have to read.

The sub-menus

Two sub-menus cover most developer needs:

Dev tools sub-menu. The things you open once or twice a day, not forty times. Postman or Insomnia. TablePlus or Sequel Ace. Docker Desktop. GitHub Desktop or Tower or Fork. A second browser for testing. Proxyman or Charles. These don't deserve top-ring slots — but they shouldn't live in the Dock either, where you'll misclick something else while hunting for them.

Shortcuts sub-menu. This is the interesting one. Apple Shortcuts has a "Run Shell Script" action. You can build Shortcuts that run npm run dev in a specific directory, open a repo in GitHub Desktop by path, clone a new repo from a URL in your clipboard, pull main across every repo under ~/code. Each of those becomes a wedge in the sub-menu. Full walkthrough here.

Here are seven Shortcuts I've personally set up, roughly in order of how often I use them:

1. Start dev server. Opens terminal, cd's into the project, runs npm run dev. The top wedge of the Shortcuts sub-menu.
2. Open current repo in GitHub. Reads the remote URL of the repo in my active terminal, opens it in the browser.
3. Copy git branch name. Puts git rev-parse --abbrev-ref HEAD of the current repo into my clipboard. Great for PR descriptions.
4. Clone from clipboard. Takes whatever URL is in my clipboard, clones into ~/code, opens in VS Code.
5. Pull everything. Runs git pull across every repo under ~/code. Fire once a week.
6. Focus mode. Toggles Do Not Disturb, quits Slack and mail, opens a Lofi playlist. Bound to start of deep-work blocks.
7. Screenshot of commit. Takes the last git commit's diff and copies a syntax-highlighted image to clipboard for posting in Slack or PR reviews.

Each is a wedge. One flick, one action. None of this is inside VS Code — that's the whole point. You can trigger any of them from any app.

Drag-to-wedge for "open this file with…"

Small feature, disproportionate developer value. Drag any file onto a wedge and Swik opens that file with the app in that wedge. Concrete developer uses:

• Drag a .sql file from Finder onto the TablePlus wedge.
• Drag an API response .json onto a second-editor wedge for diffing.
• Drag a log file onto a log-viewer wedge.
• Drag an image from a design review onto the browser wedge to pop it in a new tab.

The macOS "Open With…" menu has this information buried under a right-click and a submenu. A radial wedge puts it one gesture away, with the apps you actually use.

Context profiles for frontend vs backend vs solo

If your days split cleanly — Monday morning is backend on one codebase, Tuesday is frontend on another — context-aware profiles swap the whole layout based on which Wi-Fi you're on, which display is connected, or what time of day it is.

My actual setup:

• Office Wi-Fi + external display. Frontend profile. Browser, DevTools shortcut, Figma on the top ring. Sub-menu heavy on design-review Shortcuts.
• Home Wi-Fi, no external display. Backend profile. Terminal, TablePlus, Postman promoted. Sub-menu heavy on migration and docker Shortcuts.
• Any Wi-Fi, Saturday or Sunday. Open-source profile. GitHub wedge, different editor (Zed instead of VS Code), chat goes to Discord not Slack.

You don't have to do this. It's optional. But if your work genuinely splits into modes, the ring changing with the mode stops you reaching for the wrong tool.

Clipboard history for snippets

Developers live in copy-paste. A commit hash, a SQL query, an error message, a URL. Swik's clipboard wedge opens a sub-menu of your last eight text clips, each a flick to re-paste. It's not a replacement for a searchable clipboard database (Alfred and Raycast both have deeper ones) but for the "paste the thing I copied two copies ago" case, it's the fastest tool on the Mac.

A full suggested layout

That's four rings total, ~20 actions one trigger away. The trigger is a mouse side button or F19. The learning curve is about three days before your hand stops thinking.

What this doesn't replace

To be clear on what not to expect:

• Not a VS Code extension. It runs at OS level. It doesn't know about your open files or debugger state.
• Not a terminal multiplexer. Use tmux or your shell's sessions for that.
• Not a replacement for Raycast or Alfred. If you need file search, calculator, process management — keep those. The split between typing launchers and radial menus is in this post.
• Not an automation platform. Apple Shortcuts is. Swik is the surface that triggers Shortcuts.

It's a small tool doing one job well: getting your hand to the next app without thought. For developers, whose day is defined by the transitions between apps, that one job covers a lot of ground.