Desktop time tracking on Windows, macOS and Ubuntu

A cross-platform desktop tracker is the same application everywhere. What differs is what each operating system requires before it will let that application see the screen or measure input — and those differences are where a rollout stalls.

Platform summary

Windows

The easiest of the three. A signed installer, a per-user install with no administrator rights, and no permission prompts in normal operation. The tracker appears in the system tray and stays there while recording.

The one thing that catches deployments is endpoint protection. Anything that watches input and captures the screen looks, to a heuristic scanner, quite a lot like something you would want to block. Allow the signed publisher in your endpoint policy before rolling out to fifty machines rather than after.

macOS

The most permission-heavy, and the one that needs a sentence of explanation in your rollout email.

• Screen Recording must be granted in System Settings before captures work. Until it is, screenshots are blank.
• Accessibility must be granted for input activity measurement. Without it, activity reads as zero all day.
• Both prompts appear on first run and the app must be restarted after granting them, which is the step people skip.

These prompts are a feature, not an obstacle. macOS will not let an application watch the screen without the user knowingly permitting it. Any tracker that gets around that is doing something you should be uncomfortable with.

Ubuntu and other Linux distributions

Time tracking, activity measurement and application titles all work normally. Screen capture is where it gets interesting.

Wayland, the display server that recent Ubuntu releases default to, deliberately prevents an arbitrary application from reading the screen. That is a genuine security improvement, and it means screenshot capture requires an Xorg session.

# on one machine, before rolling out to the fleet
echo $XDG_SESSION_TYPE
# x11     -> screenshots will work
# wayland -> screenshots will not; time and activity still will

Two workable answers: switch the login session to Xorg on machines where captures are required, or accept that those machines run with screenshots disabled. The second is fine more often than people assume — developer teams on Linux are usually the ones you would run without captures anyway.

The offline queue, on every platform

All three write sessions, activity intervals and screenshots to a local queue before uploading. If the network drops, recording continues and the backlog uploads in order when it returns. The queue survives an application restart and a reboot, and uploads are idempotent so a retried partial upload does not duplicate a session.

This matters more than it sounds. A tracker that loses an afternoon because the office Wi-Fi dropped is a tracker your team stops trusting, and trust is the whole ballgame.

A rollout order that works

1. Install on your own machine firstWhatever you run. Live with it for a day and look at what the report says about you before showing it to anyone else.
2. One machine per platformOne Windows, one Mac, one Linux. Find the permission and session issues on three machines rather than fifty.
3. One team, two weeksIdeally a team whose hours genuinely need to be defensible, so the value is visible rather than theoretical.
4. Then the restWith a short written note on what is recorded and what is not. The privacy page is written to be circulated for exactly this.

Related