Mos: smooth mouse scrolling on macOS with per-app overrides

The macOS wheel problem Mos was built around

A mouse wheel reports discrete detents. macOS maps those detents to scroll steps, and the result on screen is a jump rather than a glide, because the hardware does not produce the continuous stream of positions a trackpad produces. Mos takes over the wheel events and interpolates them, turning each discrete step into a short animated scroll. The README states the tool takes over mouse wheel events and converts the scroll behavior into something smoother while keeping per-app, per-direction and per-button control.

That framing matters. Mos is not a driver and not a preference pane hack. It sits in the menu bar, reads input events, and rewrites them. The target user is narrow and specific: someone running macOS 10.13 or later with a third-party mouse, who finds the stock wheel behavior unpleasant and wants finer control than the system offers. The README lists custom minimum step length, speed gain and duration as the smoothing parameters, plus a simulated trackpad mode. Vertical and horizontal scrolling can be smoothed and reversed independently, which the system settings do not separate. If you already use only the built-in trackpad, Mos has nothing to do for you.

The README also frames the problem as a precision mismatch rather than a missing feature. A wheel cannot report sub-detent positions, so any smoothing has to be synthesized, and Mos synthesizes it rather than asking the hardware for something it cannot deliver. That is why the parameters are exposed as numbers instead of a single smoothness slider: the amount of interpolation is a taste decision, and the correct value depends on the wheel's detent spacing, the scroll speed you use, and how much latency you will tolerate.

How Mos intercepts and rewrites scroll events

The architecture implied by the README and the repository layout is a menu bar agent built in Swift, with the app bundle in Mos/ and the Xcode project at Mos.xcodeproj/. Mos registers for input events, applies a smoothing transform, and posts the rewritten events back. The README describes the smoothing as interpolation of the original wheel behavior, and it exposes the parameters that shape that interpolation rather than hiding them behind a single slider.

Two design choices stand out. First, the axes are independent: vertical and horizontal scrolling each get their own smoothing and direction settings, so a horizontal tilt wheel can be reversed without touching vertical scroll. Second, configuration resolves per application. Each app either inherits the global settings or overrides scrolling, shortcuts and button bindings on its own. That is the right call for a tool like this, because the failure mode of global smoothing is always the same app that behaves badly under it, usually a game, a virtual machine or a remote desktop client.

Beyond scrolling, Mos records mouse, keyboard or custom events and binds them to system actions, shortcuts, launching an app, running a script or opening a file, with a built-in action library covering Mission Control, space switching, screenshots, Finder operations, document editing and mouse scrolling. The README also documents Logi/HID++ support for Logitech button events over Bolt and Unifying receivers and Bluetooth-connected devices, including proprietary Logi actions. That is a substantially larger surface than the project's one-line description suggests, and it is the part most likely to break when macOS changes how it delivers HID events.

The cost of this design is that Mos sits in the input path for every scroll event. Anything that goes wrong in the transform is felt immediately, and the README's contribution policy reflects that: changes to input event handling, permission prompts, update checks or persistence formats are listed as not currently merged without prior discussion.

Installing Mos with Homebrew and setting a first scroll profile

The README offers two install paths. Manual install means downloading the latest build from GitHub Releases, extracting it, and moving Mos.app into /Applications. Homebrew users get a cask, which is the path to prefer if you already manage applications that way, because upgrades are one command:

brew install --cask mos

After the cask installs, Mos appears in the menu bar. On first launch macOS may ask for Accessibility permission. The README states Mos needs this permission to read and rewrite scroll events, and points to a wiki page on permission troubleshooting if the app still does not work after you grant it. Grant it in System Settings under Privacy & Security, then quit and relaunch Mos if scrolling does not change.

Updating later is the standard cask sequence:

brew update
brew upgrade --cask mos

For a first real use, open the scrolling settings and set the three smoothing parameters the README names: minimum step length, speed gain and duration. Start by changing only the duration and leaving the rest alone, then scroll a long document. If the result feels laggy rather than smooth, the duration is too long for your wheel. Then open the per-application settings and add the one app where smoothing bothers you, setting it to inherit the global configuration but override scrolling. That two-step order, global tuning first and a single exception second, matches how the settings are structured.

If you prefer the manual route, the README's instruction is to download the latest release from GitHub Releases, extract the archive, and place Mos.app in /Applications. Either way the app is the same bundle, and the Accessibility grant is per copy, so replacing a manually installed Mos.app with the cask version can leave a stale permission entry behind.

Where Mos is the wrong tool

The licence is the first constraint. The README states Mos is licensed under CC BY-NC 4.0 and explicitly asks that it not be uploaded to the App Store. The repository entry reports NOASSERTION for the licence, so the two signals do not agree, and anyone who needs a permissive licence for commercial use or redistribution should read LICENSE in the repository before depending on it. Non-commercial is the stated intent.

Accessibility permission is the second constraint, and it is not optional. Mos reads and rewrites input events, which is exactly the capability macOS gates behind that permission. If your environment blocks Accessibility grants, through MDM policy or a hardened configuration, Mos will install and then do nothing. The README acknowledges this by linking to a troubleshooting page rather than claiming the permission is automatic.

The third constraint is scope. Mos is a macOS tool. There is no Windows or Linux build in the repository layout, despite search interest in a Windows version. If your workflow spans operating systems, Mos covers only one of them, and the settings do not travel.

A fourth limitation is subtler: smoothing adds latency by construction. Interpolating a discrete step into an animated scroll means the content continues moving after the wheel stops. For reading and browsing this reads as smoothness. For anything where the scroll position is a control input, such as a timeline scrubber, a map, or a game camera, the same behavior is a delay between your hand and the result. This is why the per-app override exists, and why the first thing to configure after global tuning is the list of apps where smoothing should be off entirely.

Finally, the contribution guidelines describe the maintenance cost honestly: Mos handles system input, Accessibility permissions, Logi/HID devices and persisted user configuration, and the README says regression risk is real and prefers small, focused changes. Large features, architecture rewrites, bulk AI-generated code and changes to input event handling, permission prompts, update checks or persistence formats are listed as not currently merged. A project with that policy is stable, but it is not a place to expect a feature request to land quickly.

Mos compared with LinearMouse

LinearMouse is the comparison people search for, and the difference is in what each tool treats as the unit of control. LinearMouse is built around per-device and per-app pointer configuration: cursor acceleration, speed and scroll behavior are set as properties of a device or an application, and the model is declarative. You describe how a device should behave and the tool applies it.

Mos starts from the event stream instead. The README describes it taking over wheel events and interpolating them, with the smoothing parameters (minimum step length, speed gain, duration) shaping that interpolation directly. On top of that it layers a binding system: record a mouse or keyboard event, bind it to a system action, a shortcut, launching an app, running a script or opening a file, with a built-in action library and Logi/HID++ support for Logitech hardware.

So the two overlap on scroll smoothing and diverge on everything else. If you want a declarative configuration file describing pointer behavior across devices, LinearMouse's model is the closer fit. If you want a menu bar app where you tune the interpolation curve and then remap buttons, including Logitech buttons over a Unifying receiver, Mos covers more ground. Neither is a superset of the other, and the choice comes down to whether your main complaint is the pointer curve or the wheel event itself.

Maintenance, upgrades and the licence question

The repository is not archived, and the most recent push shown is 2026-08-20. The release history shows 4.2.0 on 2026-05-05, 4.2.1 on 2026-05-31, and a beta 4.3.0-beta-20260820.1 on 2026-08-20, which indicates ongoing work at a measured pace rather than continuous churn. The README lists Sparkle among the acknowledgements, which is the update framework used by macOS apps distributed outside the App Store, so in-app update checking is part of the design. The README's own contribution policy names update checks as a high-risk area for changes, which is consistent with that.

Upgrade cost is low if you install through Homebrew, since brew upgrade --cask mos is the whole procedure. Manual installs mean re-downloading from GitHub Releases each time. Either way, the settings live in user configuration that the README treats as a compatibility surface: changes that alter how old user data is read or how persistence formats work are listed as not currently merged. That is a deliberate stability trade-off, and it means your configuration should survive minor upgrades.

On licensing, the README states CC BY-NC 4.0 and asks that Mos not be uploaded to the App Store, while the repository metadata reports NOASSERTION. CC BY-NC 4.0 is a content licence, not a software licence, and its non-commercial clause is the practical limit here. If you are an individual using Mos on your own Mac, the non-commercial term is unlikely to be the binding issue. If you plan to bundle, redistribute or ship Mos as part of something you sell, read the LICENSE file and treat the README's stated terms as the project's intent. This is a description of what the repository says, not legal advice.

What to verify before you commit to Mos

Three things are worth checking on your own machine, because the README does not answer them. First, confirm the Accessibility grant actually applies to the installed build by scrolling in a second application after the first one responds, since a stale permission entry for an older copy of Mos.app is a common failure. Second, confirm the licence situation by opening LICENSE in the repository rather than relying on the badge text, given the NOASSERTION metadata. Third, if you depend on Logitech hardware, check whether your specific device and connection type appear in the Logi/HID++ support the README describes, because that feature covers Bolt and Unifying receivers and Bluetooth direct connections, and a device outside those paths may fall back to generic mouse handling.

For the per-app overrides, the useful test is the app you already suspect: open its entry in the application settings, override scrolling, and see whether the override holds after a restart. Mos persists configuration, and the README treats persistence formats as a compatibility surface, so an override that does not survive a relaunch is a real bug rather than a settings quirk.

One more thing to decide before installing: whether you want the button binding features at all. They are a larger attack surface than scroll smoothing, they touch Logi/HID devices and script execution, and the README flags them as high-risk for contributors. If you only want smoother wheels, leave the binding side alone and the app stays a single-purpose scroll transform.

Editorial conclusion

Adopt Mos if you use a mouse on macOS and want wheel scrolling interpolated the way a trackpad feels, with per-app exceptions for apps that fight the change. Do not adopt it if you need an App Store distribution channel, if you intend to ship it inside a commercial product, or if you cannot grant Accessibility permission, since the README states Mos needs that permission to read and rewrite scroll events. Before installing, check the LICENSE file in the repository and the release you intend to run, because the repository entry reports NOASSERTION while the README badge and text say CC BY-NC 4.0. Then verify the Accessibility grant actually took effect by scrolling in a second app after the first one works.

Frequently asked questions

Official sources

1. Caldis/Mos on GitHub
2. Issues
3. Project website
4. README
5. Releases