フォルダの自動振り分け alternatives: what you can drop

Automatic folder sorting is usually the first idea and rarely the cheapest one. The plan starts as a rule that files PDFs into a documents folder, and three evenings later it is a rule set with a dozen conditions, an exception list, and a folder tree that nobody but its author can navigate. Before building any of that, it is worth checking which parts of the job have substitutes that require no rules at all, and which parts genuinely need a rule engine. The answer is often that two thirds of the intended rule set can be dropped, and the remaining third can be built in an afternoon.

What automatic sorting is actually buying

Rules deliver three separate things, and they are worth pricing separately because each has a different substitute.

The first is a shorter list. A folder holding four hundred items cannot be read, and moving most of them elsewhere fixes that regardless of where they go. The second is a predictable location, so that a known file can be reached without searching. The third is reduced handling, meaning nobody has to drag anything anywhere.

Only the third genuinely requires automation. The first can be achieved by one move with no conditions at all. The second can be achieved without moving anything, because search on macOS reaches files wherever they are. A rule set that is built to deliver all three at once tends to be justified by the third while actually being used for the first, which is why elaborate taxonomies get abandoned without anyone noticing the loss.

Search instead of sorting

macOS indexes metadata for every file continuously, and a saved search presents the matches as if they were a folder. What is stored is the condition, not the files, so nothing moves and nothing can be lost by deleting the search.

The attributes worth knowing are the ones a file type cannot express. The date a file arrived in its folder is recorded separately from the modification date, which matters because downloaded files usually carry the server's modification date. The source address is recorded for anything that arrived over the network.

mdfind -onlyin ~/Downloads 'kMDItemDateAdded > $time.today(-14)'
mdfind -onlyin ~/Downloads 'kMDItemWhereFroms == "*invoice*"c'

What this replaces is the entire "predictable location" argument. If the reason for sorting was to know where to look, a saved search knows where to look already, and it keeps working when a file ends up somewhere unexpected. What it does not replace is the item count. The folder still holds four hundred things and still opens slowly.

One dated archive instead of a folder tree

The category tree is the most expensive part of a sorting setup and the easiest part to drop. The substitute is a single archive folder named by month, with one rule that moves anything past a chosen age into it.

This is a real trade, not a shortcut. Retrieval by category is lost, and retrieval by rough date is gained, which suits how people actually remember files better than most category schemes do. It also removes the two hardest problems in rule writing: deciding which category an ambiguous file belongs to, and debugging a rule with many branches. A rule with one destination either acted or did not, and the answer is visible in one place.

There is a second reason category trees underperform on a downloads folder specifically. Extensions describe formats, not purposes. A PDF folder accumulates invoices, manuals, tickets, and papers; after a few months it has the same item count and the same opacity as the folder it replaced, one level deeper. Conditions based on source address or name pattern hold up much better, and those are conditions that a flat archive plus search handles without any tree at all.

Splitting the inbox at the source

Some of what rules are asked to do can be handled by changing where files land in the first place. Browsers let the download location be set to any folder. Pointing a browser at a dedicated folder and leaving the system Downloads folder for mail attachments, AirDrop, and chat produces a split between deliberately fetched files and received ones, which is one of the most useful distinctions in practice and one of the hardest to express as a condition.

The same logic applies to screenshots, which have a configurable destination on macOS, and to anything else with a settable output path. Every setting changed at the source is a rule that never has to be written, never has to be debugged, and never has permissions problems. This is the highest return move in the whole list, and it takes a few minutes across three or four applications.

Tags are a related option with a narrower fit. A file can carry several of them, which folders cannot, and applying one moves nothing. The catch is that somebody has to apply them, and a folder filled by other people's attachments arrives untagged. Tags work well for files created locally and poorly for an inbox. Where they do pay off is as the output of a rule rather than as a manual habit: a rule that tags matching files without moving them gives the grouping benefit with none of the reversal risk, and a saved search on that tag behaves like a folder without being one. That combination is often what people actually wanted when they set out to build a sorting tree.

Treating the backlog once instead of continuously

A large share of sorting rules exist to deal with a backlog rather than with incoming files, and a backlog is a one time problem. Several hundred accumulated items need one sweep, not a standing rule. The two are easy to conflate because both are described as organizing, and conflating them leads to rules written to handle cases that will never occur again.

Separating them is straightforward. Move everything currently in the folder into a dated archive in one operation, without conditions and without categorizing. That handles the backlog completely and takes a few seconds. Then look at what arrives over the next two weeks, which is a far smaller and far more consistent set, and write rules only for what actually appears. Most people find that the incoming mix is three or four recurring kinds of file, not the twenty kinds the backlog suggested.

This sequencing also makes the rules better. A rule written against a backlog is written against years of accumulated variety, including files from tools no longer in use and projects long finished. A rule written against two weeks of current arrivals is written against the present, which is what it will have to handle. The backlog only needs to be searchable, and it already is, because indexed metadata does not care which folder something sits in.

The one thing worth checking before the sweep is whether anything in the folder is currently referenced by another application, since moving those breaks the reference. Project media, build dependencies, and configured export destinations are the usual cases, and they are the reason to sweep into an archive rather than into the Trash.

If a rule engine is still the answer

Some workloads really do need conditions evaluated on a schedule with a record of what happened. Below are the options that exist for that on macOS, with what each costs.

Option	Price	Requires	Notes
Folder Actions, Automator, Shortcuts, launchd	Included with macOS	Nothing to install	Actions and schedules, but no built in rule list or run history
Hazel 6	42 USD single licence, 65 USD family pack	macOS 13 Ventura or later	Family pack covers up to 5 members of one household. Upgrade from earlier versions is 20 USD
Keyboard Maestro 11	36 USD	macOS 10.13 High Sierra or later	Upgrade from earlier versions is 25 USD. A general automation tool rather than a file specific one

Two factual notes that affect planning. Hazel moved from being a System Preferences pane to a standalone application at version 5, a change its developer attributes to problems Apple introduced for preference panes in Catalina, so older instructions describing it as a preference pane no longer match what gets installed. Keyboard Maestro states that purchases made since 1 March 2023 receive a free upgrade to version 11, which is worth checking before paying an upgrade fee.

The choice between a graphical rule editor and a script is less about capability than about who maintains it later. A rule built in an editor is readable by anyone who opens the application, and it is difficult to express conditions the editor did not anticipate. A script can express anything, including queries against indexed metadata that no editor exposes, and it is readable only to someone comfortable with the shell. Both can be equally reliable. The failure mode differs: an editor based setup tends to grow rules nobody remembers creating, while a script based setup tends to be abandoned when the person who wrote it stops wanting to read it.

The built in tools cover more ground than they are given credit for. The gap they leave is specific: there is no single place listing all active rules, and no history of which files were moved by which rule. For one or two rules that gap costs nothing, because a shell script plus a log file covers it. For fifteen rules it is the entire difference between a maintainable setup and one that becomes unexplainable within a year.

What none of the alternatives remove

Every option above leaves the same loop in place. Look at what is in the folder. Decide on a condition. Express the condition somewhere. Run it without acting, and read the result. Adjust. Run it for real. Check the folder again.

That loop runs several times before any condition is trustworthy, and it runs again whenever the incoming mix changes. Paid rule engines shorten the "express the condition" step by replacing query syntax with a form. They do not shorten the reading or the checking, which is where most of the time goes.

There are two operational costs that also survive every choice. Anything watching a folder has to be running to watch it, so it needs to start at login and it observes nothing while the Mac sleeps. Anything on a schedule needs the Mac awake at that time, which on a laptop that gets closed means missed runs with no error anywhere. And rules touching locations outside the home folder need explicit approval in the privacy settings, without which some operations fail silently rather than reporting a problem. Comparisons of how different tools handle this are collected on the Compared with other file managers page.

What to change first

Change the download locations at the source before writing any rule, then add one rule that moves anything older than a set age into a single dated folder. Most of the intended rule set becomes unnecessary at that point, and what remains is small enough to debug.

If the loop of listing, querying, and checking is currently split across a file browser and a separate terminal, that split costs more per adjustment than the rule engine choice does. What Atriens keeps in one window is listed on the Features page, and the Pricing page covers what it costs.