Time Tracking on macOS Without Screen Recording or Screenshots

Open the Mac App Store and search for "time tracker." Install three of the top results. Run them.

You will see the same prompt three times: " would like to record this computer's screen and audio."

This is not a coincidence and it is not malice. There is a real engineering reason. There is also a much better alternative most products have not bothered with.

This post explains what Screen Recording actually buys a tracker, why most products take it anyway, and how to track work on macOS without ever granting it.

What macOS Screen Recording permission gives an app

The Screen Recording permission was added in macOS 10.15 (Catalina) to gate access to:

• the contents of any window, including windows in other apps
• the entire desktop, including dynamic content
• audio output (sometimes — depends on API)

For a time tracker, the permission is useful for two specific things:

1. Reading text from the active window via OCR or ML. Page titles, URLs, document names — anything visible to the human eye becomes readable to the tracker.
2. Capturing screenshots at intervals. Some products use this to build a visual timeline or as "proof of work" for clients.

Both are real features. Both have serious privacy costs.

The privacy cost is asymmetric

When you grant Screen Recording, you are not granting it just for the time-tracking app's window. You are granting it for everything you ever look at on that Mac. The permission has no scope below the application boundary.

Practically, that means:

• the tracker can see your password manager when you open it
• the tracker can see private Slack DMs in other workspaces
• the tracker can see banking, medical, and personal email content
• the tracker's vendor inherits responsibility for that data, whether they capture it or not
• a future bug or supply-chain compromise in the tracker exposes a much larger attack surface

macOS gives you the menu-bar indicator (the small purple dot in the menu bar when Screen Recording is active) to make the cost visible. That indicator is the OS reminding you, every minute of every workday, that something is watching.

Why products take it anyway

Two reasons. One technical, one commercial.

Technical: until you discover the Accessibility API approach, Screen Recording feels like the obvious way to extract page titles and URLs from a browser. It works for any browser, on any version, without depending on the browser's own UI tree. It is the universal hammer.

Commercial: "screenshot proof of work" is sellable. Agencies and outsourcing platforms have been buying it for a decade. Once a product is built around screenshots, it stops being a privacy product and starts being a surveillance product. The two sell to different audiences.

Neither reason is inherent. Both reasons can be designed around.

The Accessibility API alternative

The macOS Accessibility (AX) API was designed for assistive technology — screen readers, voice control, switch access. As a side effect, it exposes the structure of every running app: the windows, the views, the buttons, the text fields, and crucially the contents of those text fields.

For a time tracker, AX provides:

• the title of the active window in any app
• the URL of the active tab in Safari, Chrome, and Firefox (each browser exposes its tab strip in AX)
• the titles of other open tabs in the focused browser window
• the focused element across the system

What it does not provide:

• pixel data
• text from windows other than the focused one (without explicit walking)
• keystrokes or input events
• data from apps that block AX (most web browsers do not; some banking apps do)

For the specific job of "reconstruct what app and what website I was using," AX gives you everything you need. Screen Recording is overkill.

What this looks like in practice

Imagine a typical 3pm sample on a freelance developer's Mac:

| Method | What gets captured | |---|---| | Screen Recording + OCR | Pixels of the GitHub PR review window, including PR title, file paths, comments, code snippets, the colleague's avatar, the time of day, the Slack notification banner that just appeared | | Accessibility | App: Google Chrome. Window title: "PR #1284: refactor auth middleware". Active tab URL: github.com/clientco/api/pull/1284. Other tabs: list of titles |

The Accessibility row is sufficient to bill the client for thirty-eight minutes of code review on the auth middleware. The Screen Recording row contains two orders of magnitude more data — most of it irrelevant to billing, all of it now the tracker's responsibility.

Pick the method that produces the row you need, not the row that contains everything.

The workflow without Screen Recording

The workflow looks identical to a screenshot-based tool, except the menu-bar indicator never turns on:

1. Install a tracker that uses AX (your candidates: DayReplay, Timing, Tyme, others).
2. Grant Accessibility on first launch — this is the only system permission required.
3. Work normally. Tracking runs in the background.
4. Review at end of day: timeline shows app + URL + duration per session.
5. Export weekly for invoicing or retros.

The output you get for billing — start time, end time, app, domain, duration — is identical. The data your tracker holds about your day is dramatically smaller.

A note on screenshot-based "proof of work"

If you work for a client who requires screenshots (some agency platforms do this contractually), you do not have a choice. Use a tracker that does screenshots, accept the privacy cost, and consider whether that contract is one you want long-term.

If you work for clients who do not require screenshots — most freelance and consulting work — you have a choice. Make it deliberately. There is no engineering reason a tracker must use Screen Recording in 2026. There is only inertia.

Verifying a tracker before installing

Before installing any macOS time tracker, do two things:

1. Check the App Store listing for required permissions. Apps that need Screen Recording typically disclose it; if a tracker says "no Screen Recording" but the listing requires it, that is a signal to pass.
2. Run lsof -i -nP | grep -i <app> after installing to see what network connections it opens, and log show --predicate 'subsystem == "com.apple.TCC"' --last 1h to verify what permissions it actually requests at runtime. macOS gives you the tools; use them.

A tool that survives both checks is a tool you can install with confidence.

DayReplay's position

For full disclosure: I built DayReplay specifically because I could not find a Mac tracker that captured URL/tab context without also asking for Screen Recording. DayReplay uses only Accessibility. The activity database is local SQLite at ~/Library/Application Support/DayReplay/dayreplay.db with mode 0600. License keys are stored in the macOS Keychain. The only outbound request is the update-manifest GET, sending platform/channel/version and nothing else.

If you want the engineering details, Security & Privacy Details covers them. If you want to see the workflow end to end, the macOS guide walks through it.

Whatever tool you end up using, pick it deliberately. Screen Recording is a much bigger commitment than a single click on an installer suggests.