StartupFolder puts a login folder where launch agents usually go

A home directory folder stands in for a launch agent

macOS gives you several ways to start a program when you log in, and most of them ask you to write XML plists into a Library folder or click through a settings pane that hides the actual list of running items. StartupFolder takes a different route. The app creates a `Startup` folder in your home directory, and anything you place inside it runs at startup. That is the entire contract, and it is stated plainly in the project documentation: "The app creates a `Startup` folder in your home directory. Anything you place in this folder will run at startup automatically."

The project is written in Swift and ships as a native macOS application, with the source laid out as an Xcode project (`StartupFolder.xcodeproj/`) alongside the app target, release notes and a `Releases/` directory. The intended user is someone with a personal Mac who wants an app, a background helper or a shell script ready when they sit down at the machine, and who would rather express that as a file in a visible folder than as a launch agent they have to hand edit. The trade is immediate. A folder is legible and editable in Finder, and it offers no way to express ordering, conditions or failure handling that a plist could carry.

The background agent that launches and keeps track of what it finds

The mechanism is a background agent that the project describes as launching and keeping track of startup items. Its stated design goal is simplicity: the documentation claims the agent uses zero resources and has no impact on system performance. That claim is the author's, not a measurement reproduced here, and the repository does not publish a benchmark behind it. What is visible in the project layout is a small macOS app target with an agent component, not a daemon distributed as a separate system service.

The agent does not limit itself to a single kind of item. The documentation lists apps, scripts, Shortcuts, links, and "really anything you want" as acceptable contents, and the app adds an interface for choosing apps, picking Shortcuts, creating scripts and managing the items already registered. So there are two ways to populate the folder: drop files in by hand, or use the app's own window to construct the entry. Both routes end up in the same `Startup` directory in your home directory, which keeps the state inspectable without the app running.

Getting the app onto the Mac and making the first run happen

Installation is two paths, and the documentation gives both. The first is a manual download from the project website at lowtechguys.com/startupfolder, followed by dragging the app into your `Applications` folder. The second is a Homebrew cask, which is the cleaner route if you already manage apps that way, and the documented command is `brew install --cask startupfolder`.

After the app is in place, the first real use is a file operation. Launch StartupFolder once so it creates the `Startup` folder in your home directory, then put a target in it. Each item type has its own convention, and the documentation is specific about them. Apps dragged in with `Command-Option` become an alias rather than a copy. Links can be dragged straight out of the browser address bar. A Shortcut is represented by an empty file whose name ends in `.shortcut`, so a file named `Shortcut Name.shortcut` is enough to register one. Scripts can be written directly inside the folder, with no wrapper.

There is no documented build from source path for regular users. The `Makefile` in the repository does contain `build`, `dmg`, `upload`, `release` and `appcast` targets, but they shell out to `make-app`, `xcp`, `rsync` and `cfcli`, and the `build` target sets `SHELL=fish`. None of that is set up for a fresh clone, so treat the Makefile as release engineering for the maintainer rather than an installation guide.

Launching apps hidden, including the ones that refuse

Most login items are apps that will eventually show a window, but some are better left running without an icon in the dock and without a dialog appearing in your face at login. StartupFolder can launch apps hidden, and the documentation goes one step further, describing the ability to force hide apps that insist on showing a window anyway. That second part is the interesting one, because it addresses the usual failure of hidden launching: an app whose own settings or accessibility code raises a window the moment it starts, defeating the setting the user just chose.

This feature is what makes a folder of login items tolerable on a machine you use every day. A network tool, a clipboard manager, a sync client: you want them resident, not visible. The limitation is that this is a macOS GUI application, and its folder is created in a Unix home directory with the literal name `Startup`. On a machine where a different tool, a backup script or a colleague's dotfile setup also expects that path, the two will collide, and the documentation does not say how the app behaves if the folder already exists with contents in it.

Keep alive relaunching, with a cutoff you cannot read from the docs

Some applications are badly behaved and quit on their own, and some scripts die on a transient condition. StartupFolder can keep apps and scripts alive by relaunching them if they crash, which the documentation positions as useful for software that crashes often. That is a meaningful difference from a plain login item, where a crash ends the item's life until the next login.

The safety valve is a crash loop detection mechanism, built in to detect when an app or script crashes too often and stop relaunching it. The existence of the cutoff is what makes the feature usable: without it, a relaunch loop would spin a broken app forever. The trade is that the documentation does not state how often is too often, whether the threshold is configurable, or whether the counter resets on a successful run. The project also does not describe any handling of a script that exits with a nonzero status, so a script that fails cleanly rather than crashing is likely outside the keep alive mechanism entirely. If you are adopting this for a service that must stay up, treat the relaunch behaviour as untested ground rather than a supervision system.

One temporary log file per script, split into stdout and stderr

Running a script at login without watching it is a bad habit, because a failure is invisible until someone notices a missing feature. StartupFolder addresses that with per script logging. The documentation states that script logs are kept in a separate temporary file for each script, so that memory is not clogged with logs from previous runs, and that the files are automatically deleted by the operating system when needed or after a reboot. The rationale is clear: a startup script that appends forever to one file is a slow disk problem, and keeping logs in temporary storage sidesteps it by letting the system reclaim space.

The logs are readable from the app interface, with separate buttons for `stdout` and `stderr`. Splitting the two streams is the right call, because the common failure of a login script is a diagnostic message on stderr while stdout stays empty, and a merged view tends to hide that. What the feature does not cover is equally important. The documentation ties the separate log files to scripts specifically, so output from launched applications is not described as captured. Temporary storage also means the logs are not a durable audit trail, and a user reading them after a reboot may find them already reclaimed.

A Makefile that ships delta updates and a Sparkle appcast

The release side of the repository explains how updates reach users. The `Makefile` names the project `StartupFolder` and sets `DELTAS=5`, and the `upload` target copies `*.delta` and `*.dmg` files to a remote host with `rsync`, then pushes `appcast.xml` separately to a startup folder on that host and calls `cfcli -d lowtechguys.` to clear cache at the edge. The `appcast` target resolves `generate_appcast` out of the resolved SwiftPM artifacts, with a fallback to the same binary on `PATH`, because that tool ships as a package artifact rather than a system command. Version numbers are read out of the Xcode project file with `rg` against `MARKETING_VERSION`, and the base version is pulled from that match with the `b` build suffix stripped.

The presence of delta files and an appcast points to an in-app update channel, which is the normal path for a Mac app that wants users on the current build without a manual download. The three most recent releases were v1.2.0 on 2026-04-04, v1.2.1 on 2026-04-19 and v1.1.5 on 2025-03-13. The project is licensed under GPL-3.0, so redistribution of a modified build carries the usual copyleft obligations, and anyone embedding the source in a larger product inherits them. The last push to the repository was on 2026-10-16, and the project is not marked as archived, so development is not frozen.

Editorial conclusion

StartupFolder is a good fit for a Mac user who wants a handful of apps and scripts alive at login without writing launch agent plists, and a poor fit for anyone who needs a documented startup order, dependency chain or per service restart policy. Before adopting it, open the Startup folder the app creates on your machine and check that the items you intend to add survive a relaunch, and read the keep alive settings to see how the crash loop cutoff is configured, since the documentation does not state the threshold it applies.

Frequently asked questions

Official sources

1. FuzzyIdeas/StartupFolder on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases