No longer compatible with macos 10.15 - update system requirements on your website

[bohall00]

• I am on the latest ActivityWatch version.

• I have searched the issues of this repo and believe that this is not a duplicate.

• OS name and version: macos 10.15.7

• ActivityWatch version: v0.13.2

Describe the bug

The front page of your website says ActivityWatch is compatible with macos 10.15+. As of v0.13.2, this is no longer true: Sorry, "ActivityWatch" cannot be run on this version of macOS. Qt requires macOS 11.0.0 or later, you have macOS 10.15.7.

To Reproduce

1. Use macos Catalina
2. Attempt to launch ActivityWatch

Expected behavior

ActivityWatch runs.

[github-actions]

Hi there!
As you're new to this repo, please make sure you've used an appropriate issue template and searched for duplicates (it helps us focus on actual development!). We'd also like to suggest that you read our contribution guidelines and our code of conduct.
Thanks a bunch for opening your first issue! 🙏

[0xbrayo]

@TimeToBuildBob address this, would aw-tauri run on macos Catalina?

[ErikBjare]

@0xbrayo I think it will be difficult. We are only building arm64 now and x86 macOS runners are being deprecated by GitHub.

@TimeToBuildBob or will it?

[TimeToBuildBob]

aw-tauri won't help here — macOS 10.15 Catalina is Intel (x86_64) only, and we're currently only shipping arm64 macOS builds. There are no Apple Silicon Macs running 10.15, so those users are fully cut off from aw-tauri as well.

The website should be updated to list macOS 11.0+ (Apple Silicon) as the minimum requirement, which reflects the reality for both the Qt-based release and aw-tauri.

[BelKed]

Maybe would be beneficial to have a look at statistics of how many ActivityWatch users are using old versions (if we collect such data?)
And if it's a too much portion we should maybe consider some solution for them to receive some updates?
Of course, ideal would be for everyone to upgrade to newest macOS but not everyone has such option :)

[ErikBjare]

@BelKed we do not collect such data. Mozilla provides platform breakdown by OS, but not version/target iirc, for the AMO installs of aw-watcher-web.

I was assuming "most or even almost all must be on Apple Silicon by now" but I don't actually have data to support that belief. The thinking was that the few that don't can keep using whichever is the latest version that does and miss out on latest features, but that's iffy from a security and performance perspective (non-feature reasons to upgrade).

I will give this further thought. I think people on Intel Macs could still use Rosetta going forward, but Apple said something recently about no longer supporting it in some way?

[BelKed]

Current GitHub-hosted macOS runners

Architecture	Labels	OS versions
Silicon ARM64	macos-14, macos-15, macos-26	Sonoma (14), Sequoia (15), Tahoe (26)
Intel x86_64	macos-15-intel, macos-26-intel	Sequoia (15), Tahoe (26)

So the oldest currently available GitHub-hosted baseline is:

• Silicon: macOS 14 (Sonoma)
• Intel: macOS 15 (Sequoia)

---

macOS architecture usage (Homebrew, 365d)

Architecture	Share of all events	Share within Mac (non-CI)
Silicon ARM64	42.57%	69.81%
Intel x86_64	18.41%	30.19%
Mac total	60.98%	100%

---

macOS version usage (Homebrew, 365d) + support status

macOS version	Name	Share of all events	Apple security support status
10.15	Catalina	0.25%	EOL
11	Big Sur	0.40%	EOL
12	Monterey	2.07%	EOL
13	Ventura	3.43%	EOL
14	Sonoma	12.33%	Supported (but GitHub macos-14 runner retires 2026-11-02)
15	Sequoia	37.79%	Supported
26	Tahoe	20.71%	Supported (current)

---

Impact:

• Dropping 10.15–13 affects ~6.15%
• Dropping 10.15–14 affects ~18.48%

---

Comparable app baselines

App	Minimum macOS	Notes
RescueTime	11+ (Big Sur)
Timing	11+ (Big Sur)
Clockify	12+ (Monterey)
Timeular	11+ (Big Sur)	arm64 + x86_64 builds
TimeScribe	12+ (Monterey)	arm64 + x86_64 builds

---

Rosetta clarification

Rosetta works only in one direction: it lets Apple Silicon Macs run Intel binaries.
It does not let Intel Macs run Apple Silicon binaries.
So Rosetta is not a path for Intel Catalina users to run ARM-only builds.

---

Runner timeline note

macos-14 deprecation starts 2026-07-06 and is fully unsupported after 2026-11-02 (with October brownouts), so migration planning is needed even if Sonoma support stays for now.

Proposed actions for the next release:

1. Update website/docs now (remove Catalina 10.15+ claim).
2. Build and publish both macOS architectures (arm64 + x86_64) with explicit runner labels.
3. Keep Sonoma (14) support for now; prepare CI migration from macos-14 before retirement.

---

Written+researched with help of llm, but should be all factually correct :)

[bohall00]

@BelKed FWIW, Homebrew is pretty fast to drop support for older systems (by philosophy as I recall), which likely heavily skews those stats.

I believe anyone using 10.15-13 is more likely using MacPorts Here are the stats for MacPorts, which may well be skewed in the other direction but should at least give a more well-rounded picture. You could probably download those data and calculate more precisely, but an approximate tally shows there are about as many Macports users running ≥11 as there are running 10.15 and below.

Yes I know this is an old machine, I just saw those Hombrew stats and wanted to add a little more information into the mix.

[BelKed]

I think our biggest problem with having an app that supports an old version of OS is having a CI/CD pipeline for that OS version as it would be nice to have it all automatically tested and deployed, ...

MacPorts 365d (data from just 2k unique users though!)

[D1no]

Came here, as I saw the notification.

While I personally believe its a bit much to ask of an open source project to support more than half a decade of system generations (Intel->Silicon) where nowadays a used, well spec'ed, M1 can cost less than 200 USD:

• GitHub allows for Self-Hosted Runners.

Aka, if the GitHub harness supports the old MacOS and intel version, part of the CI could run on an old intel mac in a basement somewhere. But again, just a note regarding CI/CD possibilities.

[TimeToBuildBob]

Tracked this down and sent the public guidance fixes upstream:

• Website: docs: clarify macOS release-specific support guidance activitywatch.github.io#54
• Docs FAQ: docs: clarify macOS release-specific support guidance docs#172

What I verified before opening them:

• The stale public claim was real in both activitywatch.github.io and docs: macOS (10.15+).
• The current stable macOS zip in v0.13.2 is x86_64, and its aw-qt binary advertises LC_VERSION_MIN_MACOSX 10.13.0.
• The current prerelease macOS zip in v0.14.0b1 is arm64, and its aw-qt binary advertises LC_BUILD_VERSION minos 11.0.0.

So the bug is not just that 10.15+ is outdated; it is that we are promising one universal macOS floor when support now varies by release line and architecture. The PRs switch the FAQ/homepage copy to that more honest framing and point macOS users at the release assets/downloads page for exact compatibility.