DockAnchor and the event tap that keeps the macOS Dock on one screen

The problem is the Dock chasing the cursor

The problem section of the README describes the behaviour precisely: in macOS with multiple monitors, the Dock automatically moves to whichever display your cursor approaches at the bottom edge. That can be distracting and interfere with workflow, especially when you want the Dock to stay on a specific display.

This is not a bug in macOS so much as a design choice, and it exists because the Dock is a system-wide singleton rather than a per-display object. When the pointer crosses into the bottom edge of a second screen, the Dock has to relocate, and the only way to change that without touching system behaviour is to prevent the trigger from ever firing.

So the audience is specific: a user with more than one display who has decided which display the Dock belongs on and is tired of it moving. The README is explicit in the requirements that multiple displays are needed for the feature to be useful, and that macOS 10.15 Catalina or later is the floor.

It is a small utility with a small scope, and the interesting question is not what it does but how it does it without the usual side effects.

Event taps instead of killing the Dock

The solution section names the approach directly: DockAnchor intercepts mouse movement events and blocks the Dock from moving to secondary displays, and unlike scripts that kill and restart the Dock, DockAnchor prevents the movement entirely at the system level.

The How It Works section gives the five steps. It creates a low-level event tap to monitor mouse movements. It calculates the Dock trigger zones on secondary displays. It prevents mouse events from reaching the Dock when in those trigger zones. It provides real-time feedback on protection status. And it uses system APIs to get actual display names and positions.

The README argues the point at length, and the argument is worth taking seriously because the alternative is common. Killing and restarting the Dock does stop it moving, but the README lists the consequences: visual flashing or animations, interruption to running applications, and dock restart delays. Those are the symptoms users report when they try the script approach.

The trade of the event tap is that it is a broader permission. The README is upfront that accessibility permissions are required to monitor mouse events and control system behaviour, and that the app only monitors mouse movement events and does not collect or transmit any personal data, running entirely locally with source code that is open and auditable.

Installation: a signed app, a Homebrew cask, or Xcode

There are three ways in, and the README presents them in order of convenience.

The simplest is a pre-built Apple signed app from the releases page, linked as Download Apple Signed App. The README notes that signing matters here, since a signed app is one macOS will grant accessibility access without extra friction.

The second route is Homebrew, in two commands. First tap the repository:

brew tap bwya77/tap

Then install the cask:

brew install --cask dockanchor

and later, to upgrade:

brew upgrade --cask dockanchor

The third route is building from source, which is five steps: clone the repository, open DockAnchor.xcodeproj in Xcode, build and run the project, grant accessibility permissions when prompted, which the README says is required for functionality, and optionally enable Start at Login in settings.

The permission flow is documented in detail because it is the step that decides whether the app works. On first launch DockAnchor prompts for accessibility access, and the path is System Preferences, Security and Privacy, Privacy, Accessibility, where you click the lock icon to make changes, add DockAnchor to the list, check the box, and restart the app if needed. The README states plainly that without accessibility permissions DockAnchor cannot prevent Dock movement between displays.

The feature set beyond the core trick

Once the event tap is in place, the settings screen grows a long list of controls, and a few of them are more than cosmetics.

Profiles let you create and switch between different configurations, and automatic profile switching can be enabled based on the connected displays, which is the feature that turns the app from a toggle into something usable across a desk setup that changes.

Auto-Move Dock to Anchor Display moves the Dock to the selected anchor display when protection starts, and Auto Fallback handles the case where the selected anchor display is removed by returning to the Primary display. A Default Anchor Display option covers the case where you always want the Dock on the primary or built-in display. Cursor Position lets you set the horizontal position, Left, Center or Right, with an adjustable offset when relocating the Dock, which is a detail that only matters to someone who has a specific layout in mind.

The rest is interface and housekeeping. There is a Virtual Monitor Display that shows your monitors visually and updates in real time as they are connected, disconnected or moved, with friendly names detected automatically. There is a status icon in the Dock and a menu bar icon showing protection status with green for active and red for inactive, right-click for quick controls and left-click to open the main window. There is a Show DockAnchor option, light, dark and system themes, and a check for updates that fetches new releases automatically.

The Settings and Interface sections add Start at Login, Run in Background to keep protection active when the window is closed, a Show Menu Bar Icon toggle, and a Hide from Dock option for menu-bar-only operation.

Architecture, permissions and the limits of the approach

The Technical Details section is short and gives you the stack: SwiftUI for the interface, Core Data for settings and preferences storage, the Accessibility APIs for system-level event monitoring, menu bar integration for background operation support, and system profiler integration for display names.

Two permissions are listed. Accessibility is required, to monitor mouse events and control system behaviour. Apple Events are used to force dock positioning when needed, which is the API path for the part of the behaviour the event tap cannot intercept.

The limits follow from the mechanism. A low-level event tap that observes every mouse movement is a wide permission for a utility whose job is watching the cursor, and it is granted to an app that can persist at login. The README's privacy section addresses the data side, saying the app only monitors mouse movement events, does not collect or transmit any personal data, and runs entirely locally with open source code. That is a reasonable position, but it is a statement by the author rather than something the event tap itself guarantees, and the permission you grant is the actual boundary.

There is a second, smaller limit. Because the Dock is anchored by preventing the trigger from firing, the behaviour depends on macOS continuing to use a cursor-position-based trigger zone. If a future macOS release changes how the Dock relocates, the app's assumption is what breaks, and the release history shows the author has shipped a good number of point releases, which suggests those changes get chased rather than ignored.

Editorial conclusion

DockAnchor is a good fit for a macOS user with two or more monitors who finds the Dock jumping screens and wants it pinned without the flicker of a restart, because the event tap approach means the Dock is never disturbed and the menu bar icon shows the protection state at a glance. It is a poor fit if you are on a single display, where the feature has nothing to do, and a poor fit on a managed Mac where you cannot grant accessibility permissions, since the app cannot function without them. Before installing, read what the accessibility grant actually permits, because a low-level event tap that sees every mouse movement is a broad permission for a utility whose job is watching the cursor, and decide whether you will use the pre-built signed app or build from source before you grant it.

Frequently asked questions

Official sources

1. bwya77/DockAnchor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases