Daylight shifts your display's warmth and brightness on a schedule you set: gradually, predictably, and out of the way. It lives in the menu bar, works entirely offline, and tells you exactly what it is doing and why.
Requires macOS 14 or later. Not yet notarised: one extra step on first launch.
Below is the app's actual schedule engine, not a picture of it. Pick a preset, choose your city, and drag through the day.
The interactive version needs JavaScript, and it has not run here, so it is not below. Everything else on this page, including the download and what the app does and doesn't claim, is unaffected.
Open a step to change when it happens and what it does.
An approximation drawn in this browser by multiplying the colours on screen, which is the same operation Daylight performs, but on this box only. A web page cannot change your display; the app does.
Daylight imports the file this writes, and a link carries the whole schedule to anyone else.
This is the app's own schedule engine and colour maths, running the presets it ships with. Pick a city and the sun-following schedule uses your real sunrise and sunset, calculated here, with no network request.
Most of the work in Daylight went into being explainable. Every state has a sentence attached, in plain language, naming whatever is responsible for it.
The highest layer that speaks about a control wins it, and warmth and brightness are decided separately, so a rule that only dims cannot quietly discard your schedule's warmth. The six layers and the order below are the app's own; the little schedules and rules attached to them are examples, so there is something for the resolver to decide between.
That sentence is not written for this page. It comes from the same resolver the app runs, checked against it across every combination of the six layers.
Six layers, a fixed order, no user-assignable priorities. A rules system you can predict beats one you can fully rewire, and the ladder is printed in the app with the active layer marked: the same one you just used above.
Daylight distinguishes what it asked for, what macOS accepted, and what it could read back and confirm. Each display reports which of the three applies. An API returning success is not evidence that anything changed, and the app does not treat it as such.
f.lux, Night Shift and similar tools write to the same colour table. Daylight reads back after every write, and when something else has overwritten it, it says so rather than silently losing. It will not fight another app, and will not disable one behind your back.
Daylight-saving changes, time-zone moves, clocks corrected by hand, schedules that cross midnight, night shifts, non-Western weeks, polar day and polar night. Anchors follow the clock; fades follow elapsed time. Getting that backwards put the whole schedule an hour out on a 23-hour day: a test now pins it.
Solar times are computed on your Mac from a place you choose: 101 cities built in, or coordinates. Daylight can suggest a starting point from your time zone, which is a setting rather than a position. It never asks macOS where you are and makes no network requests.
Settings key to a durable identity, never a display index: indices are reassigned on every dock and wake. Two identical monitors that genuinely cannot be told apart are reported as ambiguous instead of guessed at.
Interpolation runs in mired rather than kelvin, because 2000→3000 K is a large visible change and 8000→9000 K is nearly invisible. The write rate is derived from how much the value actually moves, so a 90-minute ramp writes about once a minute instead of once a frame.
Before adjusting anything, Daylight captures what "normal" means for a display, and validates it. When f.lux was running during development the table read back as R 1.00 / G 0.36 / B 0.10; adopting that as neutral would have baked another app's tint in permanently. There is a test pinned to those exact numbers.
⇧⌥⌘R restores normal output from anywhere, with no permissions required. Quitting restores your displays. If the app is force quit or crashes, macOS restores the colour table itself: verified under SIGKILL, which is why Daylight ships no watchdog helper.
This is a comfort and routine tool. It is not a medical one, and the wording throughout the app is careful about the difference.
For something evidence-based on sleep habits, the US National Heart, Lung, and Blood Institute is a reasonable place to start.
Settings live in one readable file you can export, import, or delete. History is off by default, and switching it off deletes what was kept. If you turn on app rules, Daylight reads the identifier of the frontmost application while deciding what to do and keeps no record of it.
SHA-256 8ec455957faa47e78f0676ece6bc5ddbb4901e0c81cd2be4a6347b6b8bb4dcae
Daylight is signed, but not notarised by Apple: that needs a paid Developer ID, and this build does not have one. macOS will refuse to open it on the first attempt. That is Gatekeeper doing its job, and you should be sceptical of any download that asks you to work around it.
Two honest options:
xattr -d com.apple.quarantine ~/Downloads/Daylight.app
No Xcode required. Command Line Tools is enough. There are no third-party dependencies to fetch.
./Scripts/build-app.sh release && open build/Daylight.app
Multi-display behaviour has never run on real hardware.
Every path is written and covered against simulated devices, but only
one display was ever attached during development. Run
Daylight --diagnose to see what your own displays report.
External-monitor backlight control over DDC has never exchanged a byte with a monitor. Its packet framing is unit-tested; the hardware path is unproven. It is off by default.
Daylight is a macOS application. It will not run on this device.