Night Shift requires macOS Sierra 10.12.4 and one of these Mac computers,
using the built-in display or the displays listed:
• MacBook (Early 2015 or newer) • Apple LED Cinema Display
• MacBook Air (Mid 2012 or newer) • Apple Thunderbolt Display
• MacBook Pro (Mid 2012 or newer) • LG UltraFine 5K Display
• Mac mini (Late 2012 or newer) • LG UltraFine 4K Display
• iMac (Late 2012 or newer)
• Mac Pro (Late 2013 or newer)
So this doesn't work on arbitrary 3rd party displays, only Apple ones. That's a pretty big constraint. Edit: Some people are saying it works on their 3rd party monitors anyway.
It makes me sad that people on the Internet always try to find some justification for Apple's decisions.
It is nonsense that there's some special requirement for this. Apple decided to do this because they could.
I used Flux to dim my display on my non-jailbroken iOS8 iPad 2, and quite enjoyed it for reading in bed.
Then, Apple held my iPad hostage[1], and forced me to update to iOS9 if I wanted to unlock it. And I could no longer use Flux, and nightshift is disabled for the iPad 2. There is no technical reason why I couldn't change the color temperature on my iPad 2. I did it for months. Apple just wanted to coerce customers into buying new hardware.
This is no different from Apple having a whitelist for TRIM support of SSDs in earlier versions of macOS. People were under the impression that there was some good technical reason for this. But actually, it could be enabled with a simple perl oneliner:
> This is no different from Apple having a whitelist for TRIM support of SSDs in earlier versions of macOS. People were under the impression that there was some good technical reason for this.
I used to force-enable TRIM on my non-Apple SSDs for years, it was irritating but I think they were right to be cautious. Disk controllers have a history of serious bugs being triggered by external commands.
My go-to example is my Samsung HD204UI drives, they shipped with a firmware bug[1] that led to write corruption whenever a specific command was issued to the drive. Samsung issued a firmware fix without bumping the firmware version, so even today several years later, smartmontools prints a warning every time it runs, because it's impossible to tell which drives have been fixed.
Stuff like that is so common[2][3][4] the Linux kernel maintains a list[5] of devices that certain commands shouldn't be used on for various reasons. One has TRIM completely disabled, several have NCQ TRIM disabled due to known corruption issues, including one I still own: the very same drive I used to force-enable TRIM on when it was in my Macbook.
It works fine out of the box on my Dell and Samsung displays. I think your "oneliner" is actually a zero-liner, and Apple just spelled out a list of supported displays so they don't have to be responsible for trouble with others.
I've been told that there was a good technical reason for whitelisting TRIM support, namely that a lot of SSD firmwares have buggy TRIM that caused corruption. Rather than risk it, Apple figured out some that worked, whitelisted them, and just supported those. Which is entirely reasonable.
Apple does some questionable things. Making it impossible to install older versions of iOS is a good example, as are arbitrary hardware restrictions like not providing Night Shift on older hardware. But this list of supported displays and their limited TRIM support don't appear to be among them.
> I forgot my unlock pin (because I lent my iPad to someone else) and there is no way to factory reset it without also updating the OS.
You can do this from a Mac with Erase in Apple Configurator with iOS 10 or later. You always could have done it if you happened to own an Exchange or MDM server.
Well, I couldn't. I deeply regret not rooting it when it was on iOS8. I was given it by my work specifically for development, and wanted it to be pure, so I installed flux by signing it with my developer account, and sideloaded it with xcode.
It actually seems baffling to me that Apple is stricter and more deceptive about forcing updates than most game console companies. Our iPads are specifically for medical use, and we wanted to target iOS7.
And I'm reminded of my mistake whenever I go to read in bed. The one time I turned my back on Apple, and it cost me. Just like when I was a kid and I installed that "emergency" update for iTunes 4.01 that disabled playlist sharing. Or their crippling AirPort administrator update. I had kept copies of all my ipsw files that iTunes offered, and I thought that would be enough, but, I missed the window and I had no choice but to do iOS9.
It's really sad that I now have to be more vigilant about making my own backups, because software has become so unreliable now, I never know if a version of software I'm comfortable with will become extince overnight, replaced with some crummy "upgrade". I remember when I was /excited/ by updates. Now, I have to make sure I've backed everything up first.
But yet, Night Shift works just fine on my Dell U2412M. Toggling Night Shift on/off using the switch in the Notification panel (right side) shows the Night Shift effect just as it does on the built-in display on my Macbook Pro (late 2014).
Does anybody why that is? Does Apple have a real reason here or is it just some kind of arbitrary rule to sell more displays? Considering that even 2012 iMacs are listed I would rule out special display attributes like e. g. 10bit color.
It could be that they just don't want to deal and test with older versions. By only specifying a certain number of supported displays they essentially guarantee it works for those, that doesn't mean however it can't work on others, you just don't get the assurance of it.
I have never really brought it when they say that they are disabling some feature because they can't support it, as if there's an avalanche of phonecalls that is swamping their tech support resources. By that logic, why don't they just disable support for any third party monitors? Actually, better not give them ideas...
My guess is that the Night Shift feature depends significantly on the color profile, various options (color temperature, gamma, contrast, sRGB setting, etc.) and calibration of the display.
With their own displays, they have full control over that in software, and can produce expected results. It'd be much harder to have predictable results with 3rd party monitors that users configure themselves, so Apple probably opted to outright not support those monitors.
It's also a lot easier to test the feature on a limited combination of hardware.
Was about to say basically the same thing, since f.lux works by dynamically altering the colour profile (which results in interesting bugs and glitches here and there). They've been going out of their way to make things work across the board.
I had to stop using f.lux on my Mac Pro because of this. Every five minutes my screens would blink as it adjusted the color profile. Not quite worth it!
If for some reason Night Shift were to cause a similar problem, Apple wouldn't want to put effort into fixing it if it happened with third-party displays. By having an official list, they're free to tell people having problems with other hardware "tough luck, sucks to be you."
I don't think there's one at the moment, but if I were Apple's CEO, I would make all Apple devices have two types of backlights: regular LED backlighting, and LED backlighting with no blue components.
A hardware solution would be more costly, but it would be the "Apple" way. Be aware that even if you use Flux or Night Shift your display still emits significant blue light.
It could be marketed as a big feature on an Apple keynote, given how much we use devices at night.
On my white iBook, it was possible to see what's on the screen, even when backlight was turned off, through the translucent apple logo, if the display was lit from the back, by the sun or a lamp.
I always wished there was a display that could be lit by an external lightsource, e.g. a library lamp.
I would love to see a display with, say, 8 primaries instead of 3. With a careful choice of pixel pattern, it should be possible to get much wider color gamut (especially among intense light reds and blue-green colors which are very poorly supported by “RGB” displays), without causing the metamerism problems that very colorful 3-primary displays have. Unfortunately there’s a big chicken–egg problem since images and other content are all created with the expectation of current display technology.
They definitely don’t want to completely drop the short-wavelength primary for many purposes, but it would be nice to have a “late night writing mode” where that is possible.
There is no chicken-and-egg problem because the OS already does color management to map your source color space (sRGB, mostly) to your target monitor's color space. If it didn't, you wouldn't be able to view sRGB content correctly on wide-gamut monitors, for example.
The real challenge is in developing display backlight and phosphor technology to reproduce colors outside of the standard gamuts.
No, there’s a very serious chicken-and-egg problem. The gamut of RGB displays (televisions, projectors, computer and smartphone displays, etc.) has some parts which are very wide and other parts which are very limited. All content produced in the past 20 years expects to be displayed on such displays. If you increase the intensity of the existing “RGB” (orangish-red R, yellowish-green G, purplish-blue B) primaries, you get a display with a substantially similar gamut to existing displays, but with an ability to make certain colors marginally more intense. This is easy for content authors to target using existing workflows, and even potentially possible to adapt existing content for without too much disruption.
If you invent a new type of display with a radically different color gamut, and then take existing content and amp up the intensity on hue/value regions with a newly wider gamut, you throw off all of the content creators intentions for color relationships. Total non-starter.
What you can do is show old content about the same as it was on past displays, but then there’s not really any advantage to going with the new technology, which is typically going to be more difficult and expensive to produce. A new display needs new content in order to work differently from past displays.
(Believe me: I have spent years studying human vision and color reproduction technologies. I’m not just making this up.)
If you’re curious about the topic of gamut mapping in general, I recommend this 300-page book, http://www.wiley.com/WileyCDA/WileyTitle/productCd-047003032... The gamut mapping algorithms used in most common software systems (e.g. Adobe Photoshop) are actually quite poor.
If it works like iOS it changes the tint based on the contents of the screen so it could require some extra processing power to dynamically change the tint level.
Just to add another datapoint: It works fine using my 27” Acer B276HUL that’s configured using a hacked EDID file. If it works with this third-party setup, it’s probably safe to say it’ll work with any.
I tried it out, and it's nice and simple, but still allows a custom setting for how much shift occurs, and you can trigger it manually, at custom times, or at 'sunset and sunrise'.
It has all the features of f.lux that I'd ever need, so I'm happy to uninstall f.lux on my Macs now.
(I'm not OP.) Not having to install a 3rd party app to have same functionality means it's easier to reinstall macOS from scratch, or start with a fresh Mac in the future. Less baggage.
Not GP, but I'm happy with it because I only need this to work for my laptop display. If I have my TV or external monitor hooked up, I'm either working or consuming media, in which case I don't want the color shift.
Apple has, for decades, incorporated OS-level feature apps into its OS. This kills which ever third party developed that app. I don't necessarily think it's wrong at a technical nor market level - but it sure hurts that third party. Here's hoping some of them become employed at Apple or have the option to do so at some point...
But at the same time, I doubt flux really cares. By the nature of that project I think they probably prefer to see vendors 'doing the right thing'.
Flux can do per-app disabling, which is very handy for movies and videogames. I suspect this feature is too conceptually complex to ever make it into Night Shift (although it could be possibly swung with good AppleScript support… which seems like a low priority to Apple these days)
Source: https://support.apple.com/en-ca/HT207513