# BrightIntosh and unlocking the 1000 nit XDR brightness on a MacBook Pro > BrightIntosh is a Swift and SwiftUI app that shifts the brightness range of a MacBook Pro XDR display so it can reach its 1000 nit peak at any time, rather than only while HDR content is on screen, and it ships a menu bar item for toggling that shift. The interesting design constraint is that the tool deliberately avoids low-level API calls and leaves the display under the operating system's control, and the interesting limitation is that HDR video clips while the shift is active. **niklasr22/BrightIntosh** — Unlock the full brightness of the XDR display of your MacBook Pro - Repository: https://github.com/niklasr22/BrightIntosh - Website: https://brightintosh.de - Stars: 556 · Forks: 62 - Language: Swift - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/niklasr22-brightintosh ## What the app actually changes BrightIntosh enables your MacBook Pro M1 or newer to use the increased brightness of its XDR display at any time. By default, that is only possible when displaying HDR content. The app can shift your brightness range to higher values, and the brightness slider in the app controls how much you shift this range. That is the whole mechanism, and it is a narrower claim than it first appears. This is not a utility that pushes the panel beyond its rated specification. The XDR display can already reach 1000 nits, but macOS only permits that when the content being shown is HDR. What BrightIntosh does is move the window of brightness the operating system will allow upward, so ordinary SDR content can occupy the top of the panel's range. Two practical details follow from the design. The brightness slider controls the amount of the shift rather than the output brightness itself, so the app is a range adjustment with a slider, not a replacement brightness control. And you can still use the brightness keys to control the brightness, so the hardware keys keep working once the shift is in place. There is also a menu bar item, described as a handy way to toggle the increased brightness quickly and easily. For a setting that is a shift rather than a static level, having a one-click toggle matters: the shift is something you enable for a bright room and disable for a dark one, and reaching for a slider in a preferences window each time would be friction. The audience is narrow and identifiable: someone with an XDR MacBook Pro who has noticed that the screen only gets properly bright in HDR content and wants the same brightness for everything else. The homepage is brightintosh.de, and the app is also on the Mac App Store under a link in the installation section. The project is Swift and SwiftUI, GPL-3.0 licensed, and the last push was on 2026-10-08, the same day as release v6.0.11. The two releases before it were v6.0.10 in September 2026 and v6.0.9 in August 2026, so the patch line is moving at a reasonable clip. ## Why the author says no low-level API calls There is a note in the readme that is worth quoting in full, because it is the design position of the project and it also sets the limits of what you can expect from it. The tool should not harm your display as it doesn't use any low-level API calls and your OS is in full control over the display, but there is no warranty. Three things are packed into that sentence, and they pull in different directions. The claim about safety rests on the absence of low-level calls. An app that pokes at private frameworks, registers display system extensions or writes to a framebuffer can do things the operating system never intended, and the failure mode is a damaged panel. An app that stays inside the supported brightness mechanism cannot do that, because the operating system is still doing what it was designed to do. The argument is not that the tool is harmless because it has been tested a lot, it is that the tool is harmless because of where it sits in the stack. The concession is the missing warranty. No warranty means the author is not willing to stand behind the panel on your machine, even with the conservative implementation, and it also means that if something does go wrong you have no one to appeal to. That is honest, and it is a reasonable position for a utility that touches display behaviour on hardware where a mistake is expensive. The operating system remaining in full control is also a functional limitation, not just a safety property. If the OS is the one deciding what brightness is permitted, then what BrightIntosh can do is influence that decision through the documented interface, which is precisely the reason it can shift the range but cannot, for example, push a panel past its rated peak. So the honest way to read the tool is: it is a consumer of an operating system feature, not a driver, and the warranty caveat comes from the fact that the operating system does not promise to keep honouring the request on future macOS versions. The 6.x version line is the visible evidence that it has kept working as the system has changed. ## The device list, and what it excludes The compatible devices section is the most useful part of the readme for deciding whether to install, and it is unusually precise about model identifiers. The list runs from the M5 MacBook Pro of 2025 and 2026, with model identifiers Mac17,2, Mac17,6, Mac17,7, Mac17,8 and Mac17,9, through the M4 of 2024 with Mac16,1, Mac16,5, Mac16,6, Mac16,7 and Mac16,8, the M3 of 2023 with Mac15,3 and Mac15,6 through Mac15,11, the M2 14 inch and 16 inch of 2023 with Mac14,5, Mac14,6, Mac14,9 and Mac14,10, and the M1 14 inch and 16 inch of 2021 with MacBookPro18,1 through MacBookPro18,4. Two external displays are also on the list, the Pro Display XDR and the Studio Display XDR, with the latter marked as experimental. The naming pattern gives the project a way to keep the list current, since Apple model identifiers are what you check against the About This Mac panel. It also means the list is not simply everything with an XDR screen, which is the sort of claim that is hard to verify. If your identifier is not in one of those rows, the app is not for your machine. The experimental marking on the Studio Display XDR is the one entry to be careful about, since the readme also lists a documented clash with another brightness tool and with HDR video in the problems section. An experimental entry in a compatibility table normally means it works for some users and not others. The project also ships a Widgets directory and a WidgetsExtension.entitlements file in the repository, so there is a widget component alongside the main app and the menu bar item. The top-level entries show the shape of the codebase, with BrightIntosh.xcodeproj, the main BrightIntosh/ directory, a Shared/ directory for code used in more than one target, Widgets/, the entitlements file and an asc_data/ directory for App Store Connect metadata. ## Two documented incompatibilities The known problems section is short, and both entries are about interaction with other software rather than about the app failing. The first is that BrightIntosh and f.lux will likely not work simultaneously. That word likely is doing a lot of work and it is the important qualifier in the whole readme. f.lux adjusts colour temperature and brightness over the course of the day, and it works by driving the same brightness and display characteristics that BrightIntosh is shifting. Two tools both adjusting the same underlying value, one of them on a schedule and the other one on a slider, is a conflict waiting to happen. For a user this is a real decision rather than a bug. If you use f.lux for a night-time warmer display, you are choosing between the two, and the readme does not say which one wins. The second entry is shorter and more surprising: HDR videos will clip when BrightIntosh is active. That is the price of the feature, stated plainly. The whole point of the app is to make SDR content reach the top of the panel's brightness range, and the panel's behaviour when driven into that range with HDR content is that highlights clip. So the app is best understood as a tool for bright rooms and non-HDR content, and as something you switch off before watching an HDR film. The menu bar toggle matters here. Because the shift is a toggle rather than a slider you set once, you can turn it off for the duration of a film and back on afterwards, which is the workflow the design supports. If the app had only a global brightness control with no quick off switch, this incompatibility would be much more annoying. Neither of these problems is a defect in the usual sense. They are the boundaries of what shifting the brightness range means, and a reader considering the app should treat them as part of the feature description rather than as bugs to wait for a release to fix. ## Installing BrightIntosh from the App Store or from source The installation section offers two routes, and they are worth reading together because they say something about how the project is run. The first is the Mac App Store, linked in the readme, and the badge in the header points at the same listing. The second is described as building it yourself, with a developer emoji pair in the readme that is the only informal flourish in an otherwise plain document. The presence of both, plus the fact that the readme links the App Store listing with a promotional badge, means this is a commercially distributed app with the source also published. That combination is common for Mac utilities that want App Store distribution and code transparency at the same time, and it is worth noting that the GPL-3.0 licence in the repository covers the source you can read, which is the same code that ships. The repository structure is a normal Xcode project. There is a BrightIntosh.xcodeproj directory, the main BrightIntosh/ source directory, a Shared/ directory that presumably holds the code shared between the app and the widget extension, the Widgets/ directory itself, and WidgetsExtension.entitlements. The asc_data/ directory is for App Store Connect metadata, which confirms the App Store release is part of the workflow rather than an afterthought. The contributing note is brief: if you have any ideas, enhancements or proposals, feel free to open an issue. The project also carries a CONTRIBUTING.md file and a separate LICENSE file at the root, alongside a .github/ directory and a .gitignore. There is no changelog in the top-level listing, so the release history lives in the tags and in the GitHub releases, and the version numbers tell their own story. A 6.0.9, 6.0.10 and 6.0.11 sequence over a couple of months suggests an app that is being maintained against a moving target, which is what you would expect from something that depends on undocumented-adjacent system behaviour even if it avoids the truly private parts. ## Conclusion BrightIntosh is a good fit for a MacBook Pro owner with an XDR display who wants the 1000 nit peak brightness for regular content and not only for HDR video, because the brightness shift is applied through documented behaviour rather than private APIs and the operating system stays in control of the panel. It is a poor fit if you watch HDR video regularly, since the readme states that HDR videos will clip while BrightIntosh is active, and a poor fit if you also run f.lux, which will likely not work at the same time. Before installing, confirm your machine is in the supported list, since the compatibility table runs from the M1 14 and 16 inch models up to the M5, and note that the Pro Display XDR and Studio Display XDR are listed too, the latter as experimental. ## FAQ ### What does BrightIntosh do to a MacBook Pro display? It shifts the display's brightness range upward so the XDR panel can reach its 1000 nit peak for ordinary content, not only for HDR content as macOS does by default. A slider in the app controls how much the range is shifted, and the hardware brightness keys keep working. ### Which Macs does BrightIntosh support? MacBook Pro models from the M1 14 inch and 16 inch of 2021 through the M2, M3, M4 and M5, listed with their model identifiers, plus the Pro Display XDR and the Studio Display XDR, the latter marked as experimental. ### Is it safe to run BrightIntosh on my display? The readme states the tool should not harm your display because it does not use any low-level API calls and the operating system stays in full control of the display, but it adds that there is no warranty. ### What are the known problems with BrightIntosh? Two. BrightIntosh and f.lux will likely not work simultaneously, and HDR videos will clip while BrightIntosh is active. A menu bar item is provided to toggle the increased brightness quickly. ### How do I install BrightIntosh? From the Mac App Store, using the link in the installation section, or by building it yourself from the source in the repository, which is offered as an alternative to the store version. ### What licence is BrightIntosh released under? GPL-3.0, with the LICENSE file at the repository root. The most recent release is v6.0.11 from 2026-10-08, following v6.0.10 in September 2026. ## Sources - [License: GPL-3.0](https://github.com/niklasr22/BrightIntosh/blob/main/LICENSE) - [niklasr22/BrightIntosh on GitHub](https://github.com/niklasr22/BrightIntosh) - [Project website](https://brightintosh.de) - [README](https://github.com/niklasr22/BrightIntosh/blob/main/README.md) - [Releases](https://github.com/niklasr22/BrightIntosh/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/niklasr22-brightintosh