fix(ci): bump MACOSX_DEPLOYMENT_TARGET from 10.9 to 12.0 by ErikBjare · Pull Request #1363 · ActivityWatch/activitywatch

ErikBjare · 2026-07-22T10:04:37Z

Problem

The submodule bump (372fd95) pulled in ActivityWatch/aw-watcher-window#126, which compiles the Swift helper with -target $(arch)-apple-macosx$(MACOSX_DEPLOYMENT_TARGET), defaulting to 14.0 but overridable via env (?=). This workflow still exported MACOSX_DEPLOYMENT_TARGET: 10.9 — below rustc's 10.12 floor (#1327) and Swift Foundation's 10.10 minimum — so both macOS jobs on master (run 29907762087) failed compiling macos.swift:

error: 'URL' is only available in macOS 10.10 or newer

Fix

Set MACOSX_DEPLOYMENT_TARGET: "12.0" in both macOS build jobs.

Why 12.0 and not upstream's 14.0: 14.0 in aw-watcher-window#126 was chosen to stop the runner-default (macOS 15) target from leaking in — not because the code needs macOS 14 APIs. Compiling macos.swift at various targets (both arches) shows the true floor is 12.0: Swift concurrency (Task) needs 10.15, Date.now needs 12. Targeting 12.0:

still fixes the Swift build (verified: compiles OK at 12.0 for x86_64 and arm64; fails at 10.15 and below)
still avoids the aw-watcher-window#125-class Sonoma dyld crash (any explicit target ≤ user's OS does)
satisfies rustc's 10.12 minimum, subsuming fix(ci): bump MACOSX_DEPLOYMENT_TARGET 10.9 -> 10.12 #1327
keeps a future x86_64/universal build (build: macOS builds are now arm64-only, consider universal binaries #1263) usable on Intel Macs back to ~2014–15 (Monterey) instead of 2018+ (Sonoma)

Current builds are arm64-only, so today this only affects arm64 (floor 11.0 anyway); the Intel-relevant part matters when #1263 restores x86_64 artifacts.

Follow-up worth doing upstream: lower aw-watcher-window's Makefile default (and its minos CI check) from 14.0 to 12.0 to match.

Context

Last blocker for re-cutting the v0.14.0b2 release (signing + notarization fixed in #1362 and via secret rotation; see #1339).

ErikBjare · 2026-07-22T10:04:42Z

@greptileai review

greptile-apps · 2026-07-22T10:06:24Z

Greptile Summary

This PR aligns the macOS release builds with the Swift helper’s minimum deployment target. The main changes are:

Raises the Qt release job target from macOS 10.9 to 14.0.
Raises the Tauri release job target from macOS 10.9 to 14.0.

Confidence Score: 5/5

This looks safe to merge.

No blocking issues found in the changed code.
The target change is consistent across both macOS release paths.
Non-macOS matrix entries inherit the variable, but their toolchains do not use this macOS-specific setting.

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Updates both release-job deployment targets to macOS 14.0, matching the Swift helper’s stated requirement.

_{Reviews (1): Last reviewed commit: "fix(ci): bump MACOSX_DEPLOYMENT_TARGET f..." | Re-trigger Greptile}

greptile-apps · 2026-07-22T10:06:37Z

Greptile Summary

This PR raises the deployment target in both macOS release jobs. The main changes are:

Set the Qt release job target to macOS 14.
Set the Tauri release job target to macOS 14.
Quote both environment values as strings.

Confidence Score: 4/5

Both release jobs can produce native artifacts that require macOS 14, including bundles that still declare support for older systems.

The job-level variable reaches all delegated native builds.
Native artifacts can fail to load on macOS 11–13.
The Tauri bundle still declares a 10.14 minimum.

.github/workflows/release.yml

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Raises the deployment target for every command in both macOS release jobs, rather than only the Swift helper build.

_{Reviews (2): Last reviewed commit: "fix(ci): bump MACOSX_DEPLOYMENT_TARGET f..." | Re-trigger Greptile}

greptile-apps · 2026-07-22T10:06:42Z

    env:
      AW_EXTRAS: true
-      MACOSX_DEPLOYMENT_TARGET: 10.9
+      MACOSX_DEPLOYMENT_TARGET: "14.0"


Job-Wide Target Raises Binary Minimum

This job passes MACOSX_DEPLOYMENT_TARGET=14.0 to every child build, including Cargo, native Python extensions, and delegated submodule builds. Any resulting Mach-O artifact can require macOS 14, causing the packaged application to fail during loading on macOS 11–13 even when only the Swift helper needed the higher target.

Now moot at 12.0 — that's the measured floor of the Swift helper itself (Task needs 10.15, Date.now needs 12), so no artifact gets a higher requirement than the helper already imposes. The job-wide setting is intentional so all binaries share one floor, and the bundle's LSMinimumSystemVersion now derives from the same variable (d620cc5).

greptile-apps · 2026-07-22T10:06:43Z

      AW_EXTRAS: true
      TAURI_BUILD: true
-      MACOSX_DEPLOYMENT_TARGET: 10.9
+      MACOSX_DEPLOYMENT_TARGET: "14.0"


Bundle Minimum No Longer Matches

The Tauri job applies the macOS 14 target to all native compilation, while scripts/package/build_app_tauri.sh still declares LSMinimumSystemVersion as 10.14. On macOS 10.14–13, users can receive a bundle that advertises compatibility but fails when dyld loads an executable or library built by this job.

Fixed in d620cc5 — LSMinimumSystemVersion now derives from ${MACOSX_DEPLOYMENT_TARGET:-12.0}.

The submodule bump in 372fd95 pulled in aw-watcher-window#126, which builds the Swift helper with -target $(arch)-apple-macosx$(MACOSX_DEPLOYMENT_TARGET) (default 14.0, env-overridable). The bundle workflow still exported 10.9 — below rustc's 10.12 floor and Swift Foundation's 10.10 minimum — so the macOS Build step failed with: aw_watcher_window/macos.swift: error: 'URL' is only available in macOS 10.10 or newer 12.0 is the Swift helper's true floor (Swift concurrency needs 10.15, Date.now needs 12; verified by compiling macos.swift at 10.12/10.13/ 10.15/12.0 for both arches). Unlike upstream's 14.0 default, it keeps a future x86_64 build (#1263) usable on Intel Macs back to ~2014-15 (Monterey) instead of 2018+ (Sonoma), and still avoids the #125-class Sonoma crash caused by inheriting the runner-default macOS 15 target.

TimeToBuildBob

The 12.0 revision fixes the concrete master failure, and both macOS jobs passed on the previous run at 14.0. One compatibility mismatch remains before merge: scripts/package/build_app_tauri.sh still emits LSMinimumSystemVersion=10.14, while this change compiles all native Tauri-job artifacts with MACOSX_DEPLOYMENT_TARGET=12.0. The app would advertise support for 10.14–11 even though its binaries may require 12.

Please change that plist value to 12.0 in this PR (ideally derive it from ${MACOSX_DEPLOYMENT_TARGET:-12.0} so the build target and advertised floor cannot drift again). The Qt/PyInstaller bundle does not currently declare an equivalent minimum in aw.spec, so that mismatch is specific to the Tauri bundle.

Separately, run 29907762087 also had an unrelated flaky-looking Tauri macOS test failure in aw-client: both eager RequestQueue.register_bucket tests failed even though the same SHA passed on Linux/Windows and the replacement PR run's macOS job passed. I would not broaden this CI repair PR for that unless it recurs.

…RGET The Tauri app bundle hardcoded LSMinimumSystemVersion=10.14 while its binaries are now built with MACOSX_DEPLOYMENT_TARGET=12.0, so the bundle would advertise support for macOS 10.14-11 and then fail at dyld load. Derive the plist value from the same variable (defaulting to 12.0) so the build target and advertised floor cannot drift again.

ErikBjare · 2026-07-22T10:41:13Z

Addressed the review in d620cc5: LSMinimumSystemVersion is now derived from ${MACOSX_DEPLOYMENT_TARGET:-12.0} in build_app_tauri.sh, so the advertised floor can't drift from the build target again. Agreed on leaving the flaky aw-client macOS test out of this PR. Upstream PR lowering aw-watcher-window's default to 12.0 is coming next.

TimeToBuildBob

d620cc5 does exactly what I asked for — LSMinimumSystemVersion now derives from ${MACOSX_DEPLOYMENT_TARGET:-12.0} so the advertised floor can't drift from the build target again. Both Greptile P1 threads are resolved. LGTM, merging when CI clears.

) 14.0 (#126) was chosen to stop the runner-default target (macOS 15) from leaking into the binary, not because the code needs macOS 14 APIs. The actual floor is macOS 12: Swift concurrency (Task) needs 10.15 and Date.now needs 12; the helper compiles cleanly at 12.0 for both x86_64 and arm64, and fails at 11.0 and below. Lowering the floor keeps the helper usable on Monterey-era machines (Intel Macs back to ~2014-15) ahead of restoring x86_64 bundle builds (ActivityWatch/activitywatch#1263), and matches the bundle repo which now builds everything with MACOSX_DEPLOYMENT_TARGET=12.0 (ActivityWatch/activitywatch#1363). Still fixes the #125 Sonoma dyld crash, which only required an explicit target <= the user's OS. Verified locally: swiftc -target arm64-apple-macosx12.0 builds and otool reports 'minos 12.0'.

Adds macos-15-intel to both the Qt and Tauri build matrices, restoring Intel macOS artifacts that were dropped when the matrix moved to macos-latest (arm64) — see #1263. GitHub retired the free macos-13 x86_64 image, but macos-15-intel is its designated standard-image successor (distinct from the paid -large runners). With MACOSX_DEPLOYMENT_TARGET=12.0 (#1363) the x86_64 artifacts support Intel Macs back to ~2014-15 (Monterey). Artifact names already use uname -m (#1262), macOS steps key off runner.os, and signing/ notarization run per-job, so no other changes are needed.

greptile-apps Bot reviewed Jul 22, 2026

View reviewed changes

ErikBjare force-pushed the fix/macos-deployment-target branch from ac09d9a to 24b4986 Compare July 22, 2026 10:23

ErikBjare changed the title ~~fix(ci): bump MACOSX_DEPLOYMENT_TARGET from 10.9 to 14.0~~ fix(ci): bump MACOSX_DEPLOYMENT_TARGET from 10.9 to 12.0 Jul 22, 2026

TimeToBuildBob suggested changes Jul 22, 2026

View reviewed changes

ErikBjare mentioned this pull request Jul 22, 2026

fix(macos): lower swift helper deployment target from 14.0 to 12.0 ActivityWatch/aw-watcher-window#132

Merged

TimeToBuildBob approved these changes Jul 22, 2026

View reviewed changes

ErikBjare merged commit bb19d73 into master Jul 22, 2026
15 checks passed

ErikBjare deleted the fix/macos-deployment-target branch July 22, 2026 11:14

ErikBjare mentioned this pull request Jul 22, 2026

feat(ci): restore x86_64 macOS builds via macos-15-intel runner #1364

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(ci): bump MACOSX_DEPLOYMENT_TARGET from 10.9 to 12.0#1363

fix(ci): bump MACOSX_DEPLOYMENT_TARGET from 10.9 to 12.0#1363
ErikBjare merged 2 commits into
masterfrom
fix/macos-deployment-target

ErikBjare commented Jul 22, 2026 •

edited

Loading

Uh oh!

ErikBjare commented Jul 22, 2026

Uh oh!

greptile-apps Bot commented Jul 22, 2026

Uh oh!

greptile-apps Bot commented Jul 22, 2026

Uh oh!

greptile-apps Bot Jul 22, 2026

Uh oh!

ErikBjare Jul 22, 2026

Uh oh!

greptile-apps Bot Jul 22, 2026

Uh oh!

ErikBjare Jul 22, 2026

Uh oh!

TimeToBuildBob left a comment

Uh oh!

ErikBjare commented Jul 22, 2026

Uh oh!

TimeToBuildBob left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

ErikBjare commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Context

Uh oh!

ErikBjare commented Jul 22, 2026

Uh oh!

greptile-apps Bot commented Jul 22, 2026

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Uh oh!

greptile-apps Bot commented Jul 22, 2026

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Uh oh!

greptile-apps Bot Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

ErikBjare Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

ErikBjare Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

TimeToBuildBob left a comment

Choose a reason for hiding this comment

Uh oh!

ErikBjare commented Jul 22, 2026

Uh oh!

TimeToBuildBob left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ErikBjare commented Jul 22, 2026 •

edited

Loading