Apple Releases MacOS 10.12.4 with Night Shift | Hacker News Reader

Apple Releases MacOS 10.12.4 with Night Shift

9to5mac.com

66 pointstotorokun43 comments

System requirements for Night Shift:

    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.

Source: https://support.apple.com/en-ca/HT207513

That's very weird, does anyone have any insight about this decision on a technical level?

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.

I think changing to OLED screens is the next logical step toward that?

Personally I wish there were display options sans backlight.

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.

It's because they have a whitelist of allowed version numbers: https://pikeralpha.wordpress.com/2017/01/30/4398/

I would strongly suspect that there is absolutely no technical justification for this decision at all.

This was a political and marketing decision, to punish customers who use third party devices. This falls neatly into line with Apple's agenda.

Apple refused to support TRIM on SSDs, unless you make on small patch to their kext. I would imagine that there is something similar for this feature.

Welcome to Apple!

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...

They haven't disabled it, they just don't officially support it. It works fine, you just can't get help from them if it doesn't.

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).

Night Shift works on my Dell UltraSharp U3415W

It works fine on my random circa 2006 Dell monitor.

On a Mac Mini (Late 2014), it works just fine on an LG 25UM58-P monitor. Looks and works the same as Night Shift does on iOS.

I use a 27" iMac as the screen for a Mac mini, I wonder if it will work. I will report back later

Oh yeah, it works

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:

> sudo perl -pi -e 's|(^\x00{1,20})[^\x00]{9}(\x00{1,20}\x54)|$1\x00\x00\x00\x00\x00\x00\x00\x00\x00$2|sg' /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorage.kext/Contents/MacOS/IOAHCIBlockStorage

It is only a matter of time until there is a oneliner to enable nightshift for all display devices.

[1] https://news.ycombinator.com/item?id=11986523

[2] https://gist.github.com/clarencesong/3768688

> 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.

[1] https://www.smartmontools.org/wiki/SamsungF4EGBadBlocks

[2] https://github.com/torvalds/linux/commit/cda57b1b05cf7b8b99a...

[3] https://bugzilla.kernel.org/show_bug.cgi?id=71371

[4] https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/144900...

[5] https://github.com/torvalds/linux/blob/master/drivers/ata/li...

From the old post:

> 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.

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.

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.

Why are you happy? and does it work with 3rd party external displays, like Flux does?

> Why are you happy [to uninstall f.lux]?

(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.

I really hope they release it for the watch at some point, since I use it to track my sleep.

I'll stick with f.lux just because I'm growing tired of Apple stealing ideas for software features, instead of coming up with them.

Since when does making a competitive software become an instance of 'stealing'?

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'.

Apple forcibly prevented flux from working on iOS. [1]

It worked fine on my iPad 2. Apple killed it, and then withheld the feature from me until I brought a new iPad.

It would be like if they reached into your computer and locked the sound output to a certain volume, and told you to fix it by buying a new macbook.

[1] https://9to5mac.com/2015/11/12/flux-iphone-sideloading-shut-...

“Apple has, for decades, incorporated OS-level feature apps into its OS”

As the lower layers get commodified, every OS vendor does that. Examples of features that, at one time, used to be third-party:

- graphics libraries

- font technologies

- audio synthesis

- MP3 encoding

- video playback

- text-to-speech

- speech-to-text

- TCP/IP support

- printer drivers

- antivirus

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)

You can't even set up the hours you want f.lux to run. And the reason given by the developers is insane. Just for that I say good ridance.

Reply on news.ycombinator.com