RClick: extending the macOS Finder context menu with your own actions

Two processes, and why a Finder extension needs one

RClick enhances your macOS Finder context menu with custom actions, and it is built with Swift 6.2 and SwiftUI for macOS 15.6 and newer, with full dark mode support and adaptive icons.

The architecture section is where the design decisions sit, and it is a dual-process architecture with a table of two components. The Main App, in the RClick/ directory, is the SwiftUI menu bar app that manages settings, state and file operations. The FinderSync Extension, in the FinderSyncExt/ directory, is injected into Finder and renders the custom context menu items.

That split is not an implementation detail you can ignore, because it explains the requirements the README lists. Folder Access is per-folder authorisation for file operations, prompted automatically. Accessibility is required for certain automation features. And the Finder Extension must be enabled in System Settings. The note in the installation section says that on first launch you may need to enable the Finder extension in System Settings, Privacy & Security, Extensions, Added Extensions.

So the privacy story is inherent to the design. A context menu extension has to be trusted by the system before it can do anything, and the actions it offers, direct delete and open-with-another-application, are the kind that benefit from being explicit about what they will do.

The primary language is Swift, the licence is GPL-3.0, and the default branch is main. The repository is not archived, the last push was on 2026-10-14, and the release history is quick, with v2.3.1 on 2026-10-14, v2.3.0 on 2026-09-16 and v2.2.1 on 2026-09-13.

The top-level listing also shows the shape of the work: the two application directories, a Shared/ directory for code both processes use, RClickTests/ for the test target, an RClick.xcodeproj/ project, and a specs/ directory that suggests the menu definitions are declarative rather than hardcoded.

The feature set, and the one action that is worth reading twice

The features list is seven items, and most of them are conveniences that macOS does not offer in the Finder menu by default.

Open with External App opens files or directories with any installed application, with support for custom arguments and environment variables. Copy Path copies the full path of selected files or folders to the clipboard. Hide and Unhide toggles file visibility in Finder. AirDrop shares files instantly via AirDrop. Quick Access Folders pins frequently used directories to the right-click menu. Create New Files generates new files from templates directly in Finder, supporting .txt, .json, .md, .docx, .pptx and .xlsx, as well as the Apple iWork formats .pages, .key and .numbers.

The seventh is Delete Directly, which deletes files or folders directly, bypassing Trash.

That one deserves a second look rather than a shrug. Deleting straight to the void removes the safety net that most people rely on without thinking about it, and it is a deliberate feature in a menu that is one right-click away. It is also the kind of feature that a user enables once, expects the confirmation prompt of a normal delete, and then discovers differently. The README does not describe a confirmation step or an undo, so anyone enabling it should decide deliberately rather than by reflex.

The template feature is the other one with a specific design. A file template is a starting point rather than an empty file, and the list of supported types is deliberately broad, covering both Microsoft Office formats and Apple's own, which means a user is not forced to keep two template sets. The examples/ directory contains a custom_menu.json, which is the clearest hint about how the menu is configured.

Dark Mode is described as full light and dark appearance support with adaptive icons and SF Symbols, and the localisation section separately mentions adaptive icons. Since the app is a menu bar item, its own appearance in the menu bar matters as much as the menu it draws.

Building it, and the toolchain floor it assumes

The README gives both an install route and a build route, and the build route is where the requirements become concrete.

The distribution route is a .dmg from the Releases page: download it, open it, and drag RClick to your Applications folder.

Building from source is a clone and an Xcode project open:

git clone https://github.com/wflixu/RClick.git
cd RClick
open RClick.xcodeproj

and the requirements are Xcode 16.4 or newer and macOS 15.6 or newer. You select the RClick scheme and then use Product, Build with the keyboard shortcut, and the README notes that the FinderSync extension will be automatically registered. That last point saves the step that a manual extension build otherwise requires.

The command line equivalent is in the development section:

# Build
xcodebuild -project RClick.xcodeproj -scheme RClick -destination 'platform=macOS'

# Build for Release
xcodebuild -project RClick.xcodeproj -scheme RClick -configuration Release

The toolchain floor is high by current standards, and it is worth being explicit about that. macOS 15.6 is a recent Sequoia point release, and Xcode 16.4 with Swift 6.2 is a specific pairing. A team with a mixed macOS estate, or with a build environment pinned to an older Xcode, will not be able to build this from source, and the pre-built .dmg is the only option in that case.

The key technologies list explains what the floor buys. Swift 6.2 with full concurrency checking, SwiftUI for all UI components, AppKit for system integration only, with NSWorkspace and NSPasteboard named, SwiftData for persistence with a shared container, the FinderSync framework for the extension, and DistributedNotificationCenter for IPC.

The AppKit restriction is the one to notice. The README is explicit that AppKit is for system integration only, and the two named classes are the ones you would need anyway. NSWorkspace is how you launch an application with a file, and NSPasteboard is how you write to the clipboard for the Copy Path action. So the Copy Path feature is essentially NSPasteboard plus some path arithmetic, which is a good illustration of what a Finder extension can and cannot do.

The menu is data, not code

The last section of the README introduces hierarchical custom menus. What the contributor list shows is the important part.

The top contributors are listed with the specific change each made, and several of them are about the menu system itself. @Juns-g contributed declarative hierarchical tree menus and watching mounted volumes so external and network drives show the menu. @P013onEr contributed string catalogs and trilingual localization, and draggable menu ordering. @shoal-rat contributed a Finder observation fix so the menu appears in every folder.

Reading those together gives you the shape of the configuration model. The menu is declarative, it can nest, its items can be reordered by dragging, and it can be defined in a JSON file, which is what examples/custom_menu.json is. The mounted-volume work and the Finder-observation fix are both about the same underlying issue, that a FinderSync extension is told about a directory being observed, and the menu appears only where the extension has been given something to show.

The examples/ directory also has a README and a screenshots/ directory, and there is a specs/ directory at the top level of the repository. A specs directory alongside a JSON examples file suggests the menu definitions are validated against a schema, which is what you would expect from a feature that lets a user write their own nested menu structure: a malformed entry should be rejected at load time rather than producing a broken menu.

The scripting side of this is where the design pays off. A user who wants a context menu item that does something specific can express it as a JSON entry rather than as an extension target, and the extension stays a single binary that renders whatever the configuration says. The cost is that the configuration has to be expressive enough, and that a user editing JSON by hand can produce a menu that does not behave as they expected, which is what the specs directory and the declarative validation are presumably there to address.

Localisation, and the five languages the project ships

RClick supports five languages with a documented priority order, and the details are given in a table: English with code en as the default and base language, Simplified Chinese with code zh-Hans as the primary localisation target, Japanese with code ja, Spanish with code es, and French with code fr.

The activation rules are stated as well. Japanese is activated when the system language is Japanese, Spanish when the system language is Spanish, and French when the system language is French. Simplified Chinese is described as the primary localisation target rather than as system-activated.

The principles list four rules. The default language is English, also the fallback for unsupported system languages. All string keys are in English in the code, localised via `Localizable.xcstrings`. The system language is auto-detected, with no manual language picker in the app. And to add a new language you add an entry to `Localizable.xcstrings` and register it in the Xcode project.

The use of the.xcstrings string catalogue format is the modern Xcode approach, and it has a consequence that is visible in the contributor list. @P013onEr is credited with string catalogs and trilingual localization, and @Dam0rt with French localization, and @EliasMatDev with Latin American Spanish localization. So the localisation effort in this project is recent and incremental, and the three-language work by one contributor and the two regional variants by two others are the shape of a catalogue that was being converted into the new format.

The Latin American Spanish entry is worth noting separately from the plain es code, because the table lists Spanish with the code es and the contributor credit says Latin American Spanish. Those are not the same target, and the difference between them is exactly the kind of thing that a translation memory handles and a naive table does not.

Where RClick is the wrong choice

There are three limits, and the first is simply the platform.

The first is that RClick is macOS only, and specifically it is a Finder extension. The FinderSync framework is a macOS mechanism, the context menu it draws is Finder's, and there is no equivalent to graft onto a different file manager or operating system. The README's similar projects list points the same way, with SzContext, MenuHelper, SwiftyMenu and OpenInTerminal. A team with a mixed desktop estate, or with a Linux workstation, gets nothing here.

The second is the permission surface, and it is larger than a typical menu bar utility. The app needs folder access with per-folder authorisation, it needs accessibility permission for certain automation features, and it needs a Finder extension enabled. Accessibility in particular is a broad permission on macOS, and granting it to an application whose context menu can delete files is a decision that deserves more thought than most people give it. The requirement that the extension be enabled manually in System Settings after first launch also means a fresh install is not finished until the user goes and does that.

The third is the one that is easy to gloss over. Because the menu is a configuration file, and the extension renders whatever the configuration says, a badly formed custom_menu.json produces a menu that does the wrong thing rather than one that fails to load, unless the validation in the specs directory is strict. And the Delete Directly action is in the same menu by default, so the failure mode of a misconfigured template that points at the wrong command is a command you did not mean to run.

There is also the licence to weigh. GPL-3.0 for a locally installed application is a low-friction arrangement, since you are not distributing it, but it is worth noticing that the project is a fork-and-build-from-source model, because the build requires Xcode 16.4 and macOS 15.6. A user on an older Mac is limited to the last prebuilt release that supports their system, and the.dmg is signed for the maintainer's own machine, so the usual Gatekeeper friction around running an unsigned or differently signed build applies to anyone building it themselves.

Editorial conclusion

Adopt RClick if you want the Finder context menu to carry your own actions and your own nested menu structure, and you are on macOS 15.6 or newer with Xcode available. Do not adopt it if you need Windows or Linux support, since it is a macOS Finder extension and nothing else. Verify first that you are comfortable granting folder access and accessibility permissions, that the Finder extension is enabled under System Settings, Privacy & Security, Extensions, Added Extensions, and that the GPL-3.0 licence is acceptable for a tool you install on your own machine.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. wflixu/RClick on GitHub