Automatic Time Tracking for Mac (Without Timers)

The real problem: Mac users lose billable work the same way everyone else does

If you bill hourly and run a Mac, your workday is fragmented by design. You move between Slack, iMessage, Safari, Chrome, Xcode, VS Code, Figma, calendar invites, terminal sessions, and a stack of Notion pages. By 5pm your manual log is missing chunks — not because you were lazy, but because manual timers assume long uninterrupted blocks. Real work is constant context switching.

DayReplay reconstructs what actually happened in the background, then lets you review it in a few minutes at end of day. Same model on macOS as on Windows, with capture mechanisms that respect Apple's privacy boundaries.

What "automatic" actually means on macOS

Most automatic trackers in the App Store either rely on screen recording (which feels like surveillance and triggers a permanent menu-bar indicator) or stop at app names ("Safari for 4h 12m") which is too coarse for invoicing.

DayReplay takes a third path. It uses the macOS Accessibility (AX) API to read three pieces of metadata every five seconds:

• the active application's process name
• the active window's title
• for the focused browser window, the active tab's URL plus the titles of other open tabs

That's the entire data model. No pixel data, no keystrokes, no clipboard, no microphone, no Full Disk Access. The Accessibility permission is the only system permission DayReplay ever requests, and the OS makes the prompt explicit on first launch.

Why URL and tab context changes invoicing

App-level totals are nearly useless for client work. "Chrome for 4h 12m" hides the fact that two of those hours were on the GitHub repo for Client A, ninety minutes were on a research thread for Client B, and the rest was your own admin. You cannot send that to a client without a 20-minute reconstruction from memory.

With domain-level grouping, the same four hours become three rows in your CSV with start times, end times, durations, and the tab list that proves it. That is the difference between an invoice you defend in 10 seconds and one you spend Friday afternoon reconstructing.

Privacy claims need specifics

Privacy-first only matters if it is explicit. On macOS specifically:

• No screen recording. DayReplay never requests the Screen Recording permission. There is no menu-bar indicator because there is nothing to indicate.
• No keylogging. Keystrokes are never captured. No Input Monitoring permission either.
• No clipboard, microphone, or camera access.
• License keys live in the system Keychain under service=DayReplay, account=license_key with kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly — never synced to iCloud, never accessible before the first unlock.
• Activity database lives at ~/Library/Application Support/DayReplay/dayreplay.db with file mode 0600 (owner read+write only).
• The only outbound request is the update-manifest GET. That request sends your platform, channel, and current version — no identifier, no license key, no captured activity.

You keep visibility into your work without surveillance-style capture. The signed and notarized package means Gatekeeper accepts it on first launch with no scary warnings.

How in-app updates work

Updates download in the background and stage themselves on disk as a "ready to install" .zip. Nothing touches the running application until you explicitly click Restart to Install in the Updates dialog (or Quit and install now on a freshly-downloaded update). When you opt in, the app exits and a small helper script atomic-swaps the new bundle into /Applications/ in ~2–3 seconds — one admin password prompt (since /Applications/ is system-wide), then automatic relaunch at the new version.

The staged bundle is verified twice: SHA-256 at download, and codesign --verify --deep --strict plus spctl --assess immediately before the swap. That second check closes the time-of-check / time-of-use window between download and execution — Apple's notarization ticket is re-validated offline pre-launch, so a swapped or tampered bundle never reaches the swap step. If a newer release ships while you have an update staged, a Check for newer version link lets you swap in the newer release before installing.

Who this is for

DayReplay is intentionally focused. It is built for:

• macOS-based freelancers and consultants who bill hourly and need defensible logs
• developers who write standups and sprint retrospectives and want them grounded in real activity
• solo operators who want weekly planning based on evidence rather than guesswork

If your workflow is one client, predictable hours, and a single timer that you actually start and stop, you do not need this. If your day involves more than two contexts and your invoice reconstruction takes more than ten minutes, this is what DayReplay solves.

First week workflow on macOS

A practical first week looks like this:

• Day 1: open the .dmg from cdn.dayreplay.app/latest-macos.dmg, drag DayReplay to your /Applications folder, grant Accessibility when DayReplay asks. Then forget it exists and work normally.
• Day 2-3: open the app at end of day, glance at the timeline, tune categories where the auto-classification was wrong (figma.com → Design rather than Other, for example).
• Day 4-5: compare what you intended to do this week with what your timeline shows you actually did. The gap is usually the most interesting thing on the screen.
• Day 6-7: export the week to CSV (Pro), turn it into an invoice or sprint retro.

The goal is not perfect minute-level accounting. The goal is reliable, decision-ready history.

Apple Silicon and macOS version support

DayReplay's macOS build is Apple Silicon native (arm64) and targets macOS 13 (Ventura) and newer. If you are still on Intel hardware or an older OS, the Mac build will not run today; the Windows build remains an option if you have a parallel Windows workflow.

Pricing confidence and free-to-paid path

Free includes today's replay (1-day history) with granular detected categories, the diagnostics panel for troubleshooting, and read-only access to the built-in category rules so you can verify value quickly without spending anything. Pro unlocks 30-day history, day navigation (← →), editable custom category rules, and CSV export — at $7/month or $59/year.

The same license activates on both Windows and macOS, so switching between machines does not require a second purchase. Activation runs through Lemon Squeezy once when you enter your key, then revalidates at most once every 24 hours in the background; a seven-day offline grace window covers travel and intermittent connectivity. One key covers up to five devices, manageable from the activation portal in your purchase confirmation email.

Product constraints we are explicit about

• macOS 13 (Ventura)+ on Apple Silicon. Intel Macs are not supported today.
• Browser tab capture depends on each browser's accessibility tree exposing tab metadata. Safari, Chrome, and Firefox are fully supported on macOS. Chromium forks (Brave, Arc, Microsoft Edge on Mac) currently fall back to process-and-window-title only — DayReplay sees them as the focused app but does not capture per-tab URLs.
• The Accessibility permission must be granted, or DayReplay falls back to process names only. The app prompts you on first launch and the permission is revocable any time in System Settings → Privacy & Security → Accessibility.
• Browser and OS updates can occasionally change accessibility tree shapes; we iterate continuously to keep capture reliable.

Clear constraints build trust better than vague promises.

The outcome

At the end of the week, you should be able to answer:

• What should I invoice, line by line?
• Where did focused execution time get diluted by coordination?
• What single calendar or process change improves next week?

That is DayReplay's job on macOS: help you move from fuzzy memory to accurate decisions, without compromising the privacy posture that made you choose macOS in the first place.