A couple thoughts, as someone who has used f.lux for years and loves what it does:
1. It's a feature, not a product. And a simple one, conceptually. As much as I'd love to have competition in apps offering this functionality (like keyboards), "make my screen more red" isn't exactly rocket-science.
2. It's not well-designed. Their messaging mixes up two very different use-cases: matching the color of your room and aiding your sleep. That's ok - I use it for both - but there's no way to customize it. Even a super-simple option would let me communicate that I only want it on after 10:30 pm, a couple hours before I go to sleep, when I darken my room. Instead I need to deal with it automatically turning on every day at 4:30 pm, which makes something that should be simple very cumbersome (I have to manually turn it on and off every day in the winter).
If you feel flux is bad designed, lacks options that you need, and needs to evolve into something that behaves smarter; perhaps we can agree the problem is not just 'make my screen more red'
You present your case as a simple tweak, there will definitely be thousands of people who also need a 'super-simple option' (I read it in my mind as "Just add a setting!"), so I guess finding good defaults and packing enough flexibility without a twelve pages setting screen would also be non trivial but appreciated.
I'm saying, recognizing that what we want from something like flux can be as complex as we want it to be, and developing an ecosystem of those would be interesting and hopefully very beneficial to everyone.
It's not that I want more features per se, but I want sensible ones. The way f.lux works is worse than a featureless alternative in many ways; it's like an alarm that's hardcoded to go off at sunrise every morning. Flux.s' stated purpose doesn't match up with its functionality, and there's no flexibility to get around that.
Offering up a loaf of bread pre-sliced isn't rocket science either, but someone has to have the idea first, and executed it in a way that other people say "Wow why didn't I think of that before." or "Huh, I could really find this useful."
At the very least Apple could offer acknowledgement.
Tweaking color temperature has been done in Hollywood since... well, color. You won't see a window on a set that hasn't been treated to balance indoor and outdoor light. Tinting flashbulbs is common. Film editors select different bulbs and gels in tiny cubicles during late night razor-and-tape editing sessions. When video got popular in the 70s, they nudged the tint control. Mid-80s Amiga video games shifted from day to night -- shadows too! TVs ship with day/night/game modes. 10 year old car navigation systems automatically switch colors at night. There's literally nothing new under the sun.
My grandparents had a TV from the 1970s, possibly 1960s, that would automatically adjust the color balance to match the room lighting. It really is an old idea.
Shipped on LCD TVs from multiple manufacturers in 2008, too: "new TVs automatically tweak their on-screen colors to complement say, the orange glow of incandescent lights in the evening or the bluish tint of midday sunshine." Six months before F.lux shipped.
>Tweaking color temperature has been done in Hollywood for nearly 100 years
Then why was it impossible to do on iOS (iPhones and iPads) since 2007?
I find it alarming that so many folks are supporting the actions of a company to control and inhibit innovation, literally hurting consumers' health in the process, in order to control and maintain their forced 30% cut of third party program revenues.
They have literally implemented Palladium and Trusted Computing and it looks like people cannot get more of it.
No they haven't. There's no TPM in modern Apple computers of any brand. And there's certainly nothing like the NGSCB Nexus, which I'd think essential to calling something "literally Palladium."
Offering up a loaf of bread pre-sliced isn't rocket science either
True, and trying to sell a "bread slicing" service, as a separate product to selling bread, is very obviously going to fail as soon as bakers buy bread slicing equipment. f.lux are trying to sell bread slicing, not bread.
And open themselves up to a lawsuit? Nope. Just keep pretending like it's obvious. Even though we've had blue-tinted screens for decades and no one came up with a similar feature.
They had. In the 1990's I worked frequently into the night and owned a CRT with color profiles. After the sun went down, I switched to a more warm profile.
Well, you can take it to ridiculous levels calling everything "just a feature".
But that doesn't change the fact that some things, like word count or auto-adjusting color temperature, are at the end of the feature-product spectrum, and are better off as "just features".
That doesn't mean someone can't try to sell a dedicated program based on just those things.
But nobody should be surprised if other programs or OSes incorporate the same stuff as merely a feature they offer.
You can set f.lux to start dimming 10 hours before you wake up by selecting 'working late' from the dropdown menu in preferences and by setting the time in '7:00 is when I wake up'. I think the option has been there since 2014. Very useful currently when the sun sets before 4 p.m. :)
Classy response. I was cringing before I even opened the link expecting whining but I am pleasantly surprised. I use f.lux on my Mac and find it has really improved my sleep. I hope Apple brings Night Shift to Mac as having the feature built-in will help more people. Personally I don't see them changing their policy towards f.lux on iOS until at least iOS 10 as the API's it requires to function are currently private. Maybe with the introduction of Night Shift they'll start to stabilise those and open it up.
I don't see it as classy, because they call to be allowed to do the thing they knew they weren't allowed to do.
And now that it's integrated, what's the benefit of letting a 3rd party do it given how integral it is to the system? That's a lot of risk (wasted battery, making it hard to read, etc.) for little reward.
I think if they had stopped at the "We call for Apple to..." it would have been a great statement. Use it to say "See this is important, so on Android go here and Windows go here and...".
I see it as an attempt to involve themselves with the platform implementors or become acquired by them. Apple, Google and Microsoft will all implement their own version of this in the next few months and f.lux will become irrelevant. Whether or not one of them partners with f.lux or not is what they hope for, I believe.
There is room for third party alternatives to system features.
e.g. spotlight search / watson, iCloud Drive / Dropbox, 1password / iCloud keychain, Instapaper / Pocket / Reading List
Apple's going to go for lowest common denominator, while third parties can go for a smaller slice of that market.
I would love to see both a system feature and enabling 3rd parties to offer this functionality. Don't expect to see it on iOS... it's too small an app class to expect a custom extension point for it.
It's not terrible or rude, but it sounds like they haven't learned anything.
They built an app they knew was against ToS, so they didn't even try to sell it. They then got mad they were told not to do that and called for Apple to let them do it anyway. Then a few months later they called for Apple to let them do it anyway.
Once I read that it was more like hearing a kid say "but mom PLEASE".
It could easily be handled in a seamless way. Have a system default, but also let third-party developers build configuration screens to let users choose when, how, etc. they want to adjustments made. Configuration aside, the only time the third-party code is called is every n minutes where iOS requests "what are the new color settings?" and the app responds. iOS takes those settings and applies them system-wide when appropriate, so (for example) the code is never called when the screen is off, and this would also let Apple provide features such as app-specific exceptions, which the third-party code would have no visibility into. Very similar to how content blockers work for Safari.
In general that's not "the Apple way". When they provide customization points like that (keyboards, notification widgets, share sheet icons) it tends to be after the 'reference implementation' has been in iOS for a few years and the problem has been well studied. Examples where it works very successfully (Android usually) help.
Content blockers are the only thing I can think of off the top of my head that haven't followed this pattern. That may be because it was a feature Apple wanted to improve the experience but didn't want the legal fight that would come with shipping their own blocker.
Thinking of it from Apple's perspective what do they gain from opening up these private APIs? They now have a new set of APIs that they have to maintain, document, and support. Where does the financial justification come from? I honestly don't see "f.lux runs on iOS" being a selling point for most buyers.
What's the benefit? They can do it better perhaps? That they will be able to do things that benefit the customer that Apple can't or won't. Just because Apple releases a feature doesn't mean it's the best in the category (more often it's not).
So bizarre how app developers are always so polite and gracious when it comes to Apple. It's like even everyone is deathly afraid of saying anything that puts Apple in a negative light.
I can only imagine what this post would have looked like had it been say, Google in question.
Protection of investment. The developers have invested time and effort into their IOS software. The developers probably have the full suite of Apple hardware, phone, ipad, mbp, tv and all the software, configs, etc. They love using Apple. They love Apple the brand.
To say bad things about the brand that one has invested so much in actually would cause physical pain. To even consider leaving the brand and dumping such an investment puts many people off. They would rather protect themselves psychologically, and protect their investment. Thus we witness a polite and gracious love letter. It makes psychological sense.
It's weird how you assume that the only possible reason for a person to stay polite and classy in the face of adversity is that they're cringing suck-ups.
There is no negative light here... this is a capability/feature that makes sense at the OS level. On desktops you have access to the deepest parts of the system, but on mobile, things need to be more secure.
Apple's done nothing wrong, and given Apple's history of implementing these kinds of features, then opening them up to developers in the next release, being polite when asking them to open them up is appropriate.
For instance, it used to be that only Apple apps could control the brightness of the screen. Apple opened that up to all apps several years ago, and now many apps use it.
Apple's just introduced new technology that would be useful for this app developer, and in a way, they are effectively enabling this kind of app-- and when they open it up in the next release (possibly iOS 10, since this is a feature introduced in the iOS 9.3 interim release) it will be stable and usable more broadly.
The combative attitude many on HN have towards apple is more about being in the Google camp and seeing them as the enemy, than about Apple doing wrong by anyone (Yeas yeas, I know they take %30 of transactions, but that's an improvement over the %80 that previous generations of mobile software developers had to give up.. and other stores take a similar cut. etc.)
Not a good example, if you actually read the article, though. The app dev was clearly trying to provoke Apple in any way he could; for instance, by raising the price of his game to $400.
You mean "persecuting", btw, and not "prosecuting".
I have several friends now who don't have a laptop or don't use it - they exclusively use a tablet/phone outside of work. They'd definitely be impacted by malware with access to all their data and communications, not to mention the ability to rack up massive monthly bills.
I know the grugq says not to root Android for maximum security, but I prefer to have the toggle. I don't like this continual removal of features from phones and I strive to have the same level of access that I had on my Nokia N900 - but it has to be an informed choice.
There has to be a middle ground somewhere between Android's "Cryptolocker.apk was successfully installed!" and Apple's "thou shalt not covet thine neighbour's underground app store on penalty of death".
I use f.lux on my Mac and it has made a real difference in my sleep. On my iPad when I am reading late I use the inverted colors mode which can be triggered by pressing three times on the home button (if you activate the shortcut). I would say this is even more a relief for the eyes, as not only blue colors become warm but all the white that is the background color for most everything becomes just dark. Of course you can't watch movies in these conditions but I highly recommend this for readers.
This. When I'm working at night on my desktop or laptop, I'm using f.lux. When I'm browsing the web late at night, I have my brightness set as low as it can go, and invert colors. Unfortunately the flickering of changing pages, images, etc. and going from a page that has a white background to one that is black (which shows up as white inverted) still wakes my wife up, so when I anticipate flickering, I have to hide under the sheets to read like a little kid reading past his bedtime.
Further, the minimum brightness on iPads is still blinding. You have to download a specific "night browsing" browser just to get it to go lower, and if you are in an ebook reader, you are reliant on them having something to help.
Ultimately, I found that for ebooks I'm just way better off with one of the new Kindle Paperwhites, which I'm absolutely in love with. However I still find myself wishing that they had a native way to invert the colors of text. This is trivial to do with common ebook/text doc formats, and I really wish they'd make it an easy "night reading" feature. Having the entire screen with a white background causes unnecessary eye strain and brightness when reading at night. Reading white text on a black background is SOOO much easier on the eyes in a low-light situation.
Taking it a step further, while I hate backlit screens for night reading, one of my favorite reading setups is using a "terminal green" on black in Stanza on my iPad. Now if only the Kindle Paperwhite could do color...
I see this exact statement repeatedly and it concerns me. F.lux isn't designed to make things "easy on the eyes." If you're having that reaction, and you feel it as strongly as your post implies, it may indicate a different health problem.
You should consider getting glasses or altering your prescription. And if you're suffering eye fatigue it's probably not a great idea to be reading on a screen late at night regardless of the colors. Research "eye strain" for other suggestions that may help you.
If memory serves, f.lux was banned for the "private" API's they used, which was necessary to control the the screen warmth.
So now that Apple has released their own screen dimming app, is Apple's implementation any different than flux's? Or did Apple effectively just abuse their app policy so that they could proactively kill a competitor to their "new" feature?
Apple has not released a screen dimming app, they will be building it into the OS.
This isn't a case where Apple did something incredibly arbitrary and capricious and then immediately ripped someone off (such as if they kicked all poker games out of the store and then included their own poker app). Apple enforced long standing app store rules.
F.lux legitimately deserved to get yelled at, they used private APIs and attempted to circumvent the app distribution system. Both were against the license agreements you have to agree to if you want to use Xcode.
Obviously you can argue about whether the rules should exist, etc. But there was no question that what they were doing would be 100% shot down.
While you are correct, the concern to which you have responded to is by no means the community's primary one.
Yes, it is true Apple rejected the app due to private API's. It was against the rules to use those API's, and Apple was within their right to reject them. Just as it is within the communities right to petition Apple afterwards and ask them to open up those API's.
The concern now is that without any form of communication, Apple has gone and released an alternative. It is a "ripoff", and there's no two ways about it. The people from f.lux were very diplomatic in their response.
(You can call it an inbuilt feature instead of an "App" all you want, but the US Department of Justice and EU Regulators have had long-standing concerns against OS vendors bundling in features in an effort to stem competition. To say nothing of the irrelevance of how the feature is distributed.)
I do wonder if it's a ripoff. I'd heard of this idea before flux, and I wonder if Apple is nimble enough to be able to 'respond' that quick. Frankly I doubt it, especially if they put lots of thought into it.
I mentioned 'app' because if it WAS an app (which isn't their style, even their apps are often bundled with the OS it would be especially egregious since they'd be doing the exact thing they told flux not to (and as we all know Apple is happy to break their own rules).
I completely agree that in the anti-trust sense (like what happened to MS) the app/built in this is irrelevant.
Respond "that quick"? Flux has been around for years on all major operating systems. It's even been around for years on the iPhone, and is commonly cited as one of the main reasons that people jailbreak.
It's not really the case that they attempted to evade the distribution system and then play the victim card. They've had no illusions that it would likely remain exclusive to the jailbreak community due to the nature of the platform and Apple's rules.
When Apple surprised everyone by saying they would allow sideloading in Xcode 7/iOS 8, f.lux thought great, we'll post it so non-jailbreakers can have it as well. Apple asked them to remove the sideloading variant shortly after, not because it uses private APIs, but because they were not distributing the source. It's always remained available to jailbroken devices (see https://justgetflux.com/cydia/).
It's so odd to read posts like this. The whole hacker mentality we see for start ups is to break the rules, ask for forgiveness later, be a disruptor... But then when it comes the Apple sacred ground ban hammer so many people become apologists. f.lux has been around forever and is a good app with well-intentioned people behind, Apple is clearly ripping them off in this instance.
As I said elsewhere, frankly I doubt Apple can move fast enough to rip them off based on the popularity shown in November. Perhaps this was already in the pipeline.
I don't entirely buy into some of that philosophy, but to me Apple is different here for one reason: every KNOWS they act like this. It's not like this is some out of the blue thing. I don't have much respect for someone purposely running into a wall and then loudly complaining about it in public.
The first few times some of this stuff happened in the App Store or it was an unwritten rule that was 'violated' yelling was TOTALLY fair.
But violating an obvious and published rule that has gotten numerous others kicked out of the store? Why are you complaining? You knew what would happen.
I know. My point was Apple is known for tightly enforcing their rules, especially when an app does something they didn't plan on people doing (using system APIs or not). Figured out an alternate use for the volume switch? Put a calculator in Notification Center? Smack down.
I find it odd that people develop the kind of things that Apple is very likely to dislike and then act surprised when Apple acts totally in character.
I'm not arguing what Apple did is good/ok/legal/fun, but it was totally predictable. Even if the app wasn't submitted.
f.lux is a screen app. You don't need to build it in OS as it works on screen for everything. Its like, tomorrow building an email app or a browser into an OS. f.lux is an application thing, not a system thing.
No, f.lux only tweens the color profiles of the OS in realtime to shift the white point. It's basically a wrapper around a function already in the OS together with a tween library. The only thing f.lux does is control a hidden API /9 it's not comparable to email or a browser.
Or are you suggesting f.lux passes the entire framebuffer at any given point through their code and adjust the color temperature using a shader on the GPU? (No.)
F.lux has nothing to do with GPU or shader. Its an application which tweeks display temperature controls. All modern OS provides such interface, on Linux, its x server extension, on Windows its GDI interface. So, its an application that uses the OS interface, that doesn't mean that it has to be made part of OS. At OS level, you provide functionality of underlying hardware but don't decide policies or features. f.lux is a feature not a functionality to display.
But by going against the rules they have forced apple's hand, and we are better off for it... if their medical claims are correct, they've actually prevented some number of DEATHS by breaking an app developer license agreement.
I find it hard to fault them when I look at it like that.
We don't know if Apple was already developing this before the November kerfuffle. It doesn't look good, even if Apple has been working on it for 3 years.
But again, because for some reason I had to say this last time too:
DEATHS?
Can we avoid obviously hyperbolic statements? I seriously doubt they could ever prove that.
Did you read the article? Link between sleep / blue light and cancer rates. When dealing with billions of people, small forces can cause big numbers...
Clearly the HN hive-mind agrees with you that I'm being to hyperbolic, but downvotes aside I think there's a strong argument that this is so easy that even a very minor health benefit would mandate adding it to every device everywhere.
It doesn't matter if the implementation is the same. Apple has access to API's that the rest of us don't and it's not so they can have more power than us. They can't be expected to make public API's for everything and maintain them for every release. Not to mention I'm sure Apple has been working on this for a while. The whole f.lux thing didn't occur too long ago.
That's correct. Way back in the 90's I was tweaking the VGA color palette registers of my MSDOS computer to make the colors more easy on my eyes at night. I never released that small program...
Apple has access to API's that the rest of us don't and it's not so they can have more power than us.
Sometimes I wonder. It sounds like if an API change breaks your app, then your app is broken and should simply get pulled for that.
Furthermore, they tapped the flux guys on the shoulder and told them hosting their code with the instructions for people to sideload it themselves isn't allowed. https://justgetflux.com/sideload/
Don't confused Apple's infamously controlling nature with some desire to adhere to good development practices. It's just Apple being Apple.
>> "It sounds like if an API change breaks your app, then your app is broken and should simply get pulled for that."
A simple solution but a terrible one for users. Imagine apps on your device regularly breaking and having to wait several weeks for developers to update them. If they update them at all. Apple would also have to monitor user reports, test supposedly broken apps, then make a decision to pull them. And if they got the decision wrong they would be killed for it in the press.
Even though I really appreciate the idea behind it, I was never all that comfortable running f.lux on my Macbook. I never understood why it was free yet closed-source. It made me suspicious in a way, if that makes sense.
After a while I just gave up and uninstalled f.lux. Instead, I created a 4500K white point copy of the default color profile and manually switched to it at night, which seemed to have the same effect. It also prevented those big flashes whenever switching to and from full-screen apps.
I'm grateful that f.lux has pushed this issue to the point of getting traction as a built-in feature from Apple (and I do hope Apple brings it to OS X at some point), however unless f.lux becomes open-source, I don't plan to reinstall it.
You support (via hardware purchases) a powerful company that demonstrates overt hostility towards openness whenever it suits them, but won't use close source f.lux?
>I never understood why it was free yet closed-source. It made me suspicious in a way, if that makes sense.
Unless binary builds are verified against the source code (or the code is reviewed and compiled locally), security is not a criteria that's benefited. The gitian process in bitcoin is an interesting solution on how to verify builds.
For context (and correct me if I have this wrong), f.lux was using a non-standard way to allow people to install the app on their phones (allowing them to install it using Xcode) and Apple banned that method. A few months later, Apple announced an iOS feature that does exactly what f.lux does.
Apple allows sideloading apps so that devs can work without the whole Apple deployment shenanigans. You write your app, sign it in Xcode, and load it onto your device.
This is allowed and encouraged.
F.lux did this to sign a compiled binary for their app. All good! Totally fine. The problem is that that they then distributed that compiled binary to people to sideload.
You're allowed to distribute source code and let people compile and sign it on their own Xcode – you are not allowed to distribute compiled code to sideload onto people's devices.
There are open source alternatives that now both predate and outlive flux on iOS, such as Gammathingy.
I don't like this characterization that you're "not allowed" to distribute compiled code to sideload. That act involves two parties: the people who made the app, and the person who installs it.
Apple decided to butt into this simple transaction and shut it down, despite the fact that they are not involved. But that's not so much "not allowed" as it is "displeases a big company that throws their weight around a bit too much."
They absolutely are involved. Apple views distribution of unknown compiled binaries as a serious security vulnerability, both because they can access private APIs that the App Store would otherwise block, and because Apple has no way to shut down an app distributed this way that turns out to be malware.
If the app is open source, you're free to compile it with Xcode and install it on your device. That's fine, because the open source nature means you can see everything the app is doing and verify that it isn't malware (and if not you personally, then someone can do it).
But for closed source distribution, barring enterprise distribution, it has to go through the App Store. Allowing anything else opens up Apple's customer base to malware.
> That's fine, because the open source nature means you can see everything the app is doing and verify that it isn't malware (and if not you personally, then someone can do it).
Closed source isn't a barrier to reverse engineering in any practical sense anymore. It's a post-IDA world.
IDA has been mainstream among reverse engineers for at least 15 years, and equivalents such as win32dasm existed before that, so there is not really a notion of a post-IDA world.
Closed source is very much a huge barrier in verifying what software is doing, just as much as it always has been. I say that as someone who has been reversing engineering professionally for much of that time.
The number of people with the expertise and access to IDA is a tiny subset of those who can just skim source code. And those who are competent reverse engineers take 10x-100x longer going that route. An even smaller subset of those have the inclination to even bother doing this for free in their spare time.
Apple doesn't become involved just because they're interested. It's a straightforward interaction between two parties, until Apple butts in.
Private APIs are a security vulnerability? Come on, you know
better than that. It's not like a malware author can't take five minutes to come up with a way to bypass the private API checker they run on App Store submissions. The prohibition on private API is purely about not breaking apps when Apple releases OS updates, or forcing Apple to maintain a private API they want to change or delete but can't because too many popular apps use it.
The Mac App Store has basically the same restrictions as the iOS App Store, but unlike iOS, OS X does not require that apps be installed via the Mac App Store.
I think the issue was that that app was using private API's, users may not be fully aware of the implications of this, install via the Xcode method and then end up with issues when/if Apple messes with the API. So although it might look like Apple preventing holding down competition there are very valid reasons for the original response. (Not 100% sure that's what you were implying).
More than that, they were distributing an Xcode project that was little more than a binary, using the recent changes to developer code signing in Xcode to get that binary on to user devices. I can see how that alone would provoke a reaction from Apple, private APIs or not.
After all, there are plenty of open source projects on Github that merely use private APIs, the browser for tvOS[0] for example.
I think it's more accurate to say that Apple asked them not to use that method, and they complied. Apple didn't employ any technical measures to prevent the method f.lux was using, you can still sideload apps. f.lux apparently decided it was more in their interest to comply than not to comply.
Personally, I use Redshift which is an open-source f.lux clone.
Ideally, I'd like to be able to watch TV/use a computer in a dark room and not have to worry about it being so bright it gives me a headache, but also have good color quality. Software color temperature apps handle the headaches pretty well, but they don't save power and they don't let me see true colors.
It would be really nice to see some more hardware effort put into low-intensity backlights, especially color reproduction at lower brightness settings.
I hope f.lux gets their chance with Apple. Their application is great and helps so many people. Btw, Michael Herf is the guy who built Picassa. He is a brilliant programmer and be sure knows a lot about graphics and colors.
This statement is a great example of professional writing in action.
> Apple announced this week that they’ve joined our fight to use technology to improve sleep.
Right from the opening sentence, this piece begins on a positive note. It isn't f.lux vs apple. It's flux and apple versus the overarching problem, and that's a much more effective statement than the bitter fight that all of us were probably expecting. I'm very impressed by the f.lux team's maturity.
If I were to teach a professional writing course, I would show this piece to my students as an outstanding example of how spin can affect the reader's perception.
Well, how could they have written their statement? Maybe this is a bit closer to what I was expecting:
> We're appalled. Apple has stolen our
> wonderful idea, just like they always do,
> so we're calling on the f.lux community
> to boycot apple products. We are also
> in the process of finding a lawyer
> to defend our patent, which Apple
> has blatantly etc etc ...
But what purpose would that serve? It would definitely make some enemies. If the project really is so small, a bitter statement like that probably isn't going to matter much.
Maybe the f.lux folks are hurting inside. Even so, they've decided to put aside their disappointment for a moment. They're calling us not to fight, but to celebrate the fact that millions of people are going to get a good night's sleep, in part because of the research they pioneered, even though they might not reap the spoils of their work. I think it takes a big heart to write it that way.
It's not the vendetta I expected, it's spreading the awareness that Apple is stealing ideas from small companies using its muscles and killing the desire to innovate! The public needs to know and tell Apple: "Don't do this anymore!" This is not stealing ideas, this is a daylight robbery! Blocking an app from App Store just to bake in its features shortly - this is immoral and possibly criminal!
> It's flux and apple versus the overarching problem
Not in the way they wrote it. They're claiming it's their fight. It's not "their" fight. They didn't discover the problem or invent the solution, they just happen to make the most popularly deployed implementation. It would be more accurate and less self-congratulatory if they had instead said "joined the fight".
It's not the first time apple is acting in such an unfavorable way towards inventors/developers.
It was exactly the same story regarding the use of the voluem button for taking pictures. 1st banned by apple and the later on integrated by apple. Not the best attitude imho.
That was a shrewd marketing move by a developer to get his app blocked by Apple so he could make hay on it. Unfortunately, it paid off. The app shot up the charts after they manufactured that controversy for all the free publicity.
Maybe more constructive than just banning would be to approach a solution together with the initial developer. Honoring his innovative approach and eventually granting him temporarily a slight advantage in exchange for bringing his innovative idea to the ecosystem instead of just playing copycat...
F.lux is great but the root of the problem is the type of backlight that monitors use. A hardware company ought to come out with a monitor armed with multiple backlight bulbs.
I mean, look at the difference in abrasiveness of spectrum between these bulb technologies:
Maybe they were referring to something along the lines of this? (Note: I have not seen the study referenced in my linked article, and cannot vouch for the accuracy of Flux's statement)
"But we do know that exposure to light suppresses the secretion of melatonin, a hormone that influences circadian rhythms, and there’s some experimental evidence (it’s very preliminary) that lower melatonin levels might explain the association with cancer."
This has been known for quite some time, amongst the contributing factors considered there's also light exposure during "dark hours", especially when it comes to cold (blue) lighting.
Although Apple are perfectly within their rights to do what they've done I hope they'd reach out to the f.lux authors and do something for them. It's not like they're destroying a business - f.lux being free - but it would reward the authors for proving the value of the improvement to the platform. You want to encourage developers like that. And it's not like Apple are short of cash.
Their web page still says "f.lux is patent pending."
Apple's "Night Shift" is great news for f.lux. If f.lux can get their patent then the billion dollar target is square in their sights.
I haven't seen anything on what exactly they are trying to patent to guess if Apple is infringing, but it does appear the f.lux business model is to get users hooked on white point shifting then profit from the patent.
The fact that f.lux is free does not mean it is not a business. Even though it is free they would be a multi million dollar business from my estimate. And Apple are indeed trampling on it by doing what they did. I'm not commenting on the morals of the whole situation, but it does seem necessary to clarify that it IS a business. Just because something is free doesn't mean you can't make money out of it in other ways.
The reality is that Apple doesn't need them and their company was built on a single feature. It sucks, but the harsh reality is that most startups today are just that—features. They aren't companies. They aren't businesses. They are a missing feature to another product.
Even companies like Spotify become redundant once someone like Apple decides to get into the game. They can hang on for a while because of their service, loyal fanbase, or particular implementation–but they can no longer grow. All of the growth as a result of new users and population growth just ends up going to the Apple product.
Companies are about growth, and if someone like Apple can throw their hat into the ring and completely freeze your growth then chances are you weren't really a company to begin with.
Much of the startup world is based on selling before people figure this out.
It's a closed-source color temperature changer on a timer. I don't think it's gotten any new features in years, and they didn't patent this feature so sucks to be them.
> f.lux is patent pending. Do you make a cell phone, display, lighting system, or other cool sleep tech, and want to talk about collaboration? Email us: support@justgetflux.com
How did Apple "fuck them"? f.lux depends on APIs that are not public, and probably never will be. There is no legal way for f.lux to operate on iOS short of being distributed as open source and compiled by every customer (the same mechanism they tried to abuse a few months ago to distribute a precompiled binary). Since f.lux cannot be distributed for iOS to begin with, Apple's not doing anything wrong by building the feature into the OS.
Am I wrong? I don't think I am. If I were a f.lux developer, given the reality that f.lux will almost certainly never be allowed to distribute on the iOS App Store, I'd be happy that Apple decided the functionality was useful enough to put into the OS. It's not like they're charging money for f.lux anyway, so there's no lost revenue here.
It's completely legal to operate on iOS, it's just against the App Store rules. They made it available to jailbroken users starting with the 3G iPhone and have a pretty strong following.
Why is f.lux struggling so hard to get on iOS, a platform that clearly doesn't want them, when they still haven't released a version for Android, which is significantly more friendly and, IIRC, has a larger user base?
My understanding is that an Android version would have to require a rooted phone to really do everything properly, which is a significant limitation, but rooting your phone is completely Google-approved and there are plenty of apps in the Android app store that openly require it. If (not unreasonably) f.lux is really concerned about reaching users who aren't savvy or interested enough to root their phones, then a root-only version would be an ideal test case to encourage Google to open up the API.
Maybe this is a sidetrack, but is there real peer-reviewed science behind the stuff f.lux claims? I tried it for a while and noticed no difference whatsoever (except that photos look like crap when the color balance is so skewed).
What makes a private api private? Is it merely undocumented, but still usable in the exact same way as a "public" api? I.e., in my code I invoke it like normal, but I just need to know the name?
Or do I have to fiddle with the compiled code of my app to get it to call the instruction location of the otherwise invisible function?
If they were meant to be private, why can't the app, which surely runs in some underpriviledged mode, be blocked from calling the function, which knows it itself is privileged?
They are usually undocumented/internal calls, not necessarily privileged.
They can't be blocked that easily because the public APIs will necessarily call the private APIs at some point internally in order to implement their functionality.
The main reason private API calls are not allowed by Apple is that it would introduce a lot of app breakage when updating iOS versions. Either that or Apple would need to manually add hacks to account for specific apps that are misbehaved. (What Microsoft usually does for important/popular apps)
Security-sensitive calls do require special permissions from the Operating System, which is usually granted on a process-per-process basis. (Which is why we only got JIT compilation in WebViews recently, once the WebView process was separated from the App process thanks to WebKit2)
During the review phase of the App Store submission, Apple will use static analysis tools to figure out if the App is calling the private APIs. Some people have successfully used dynamic execution techniques to game that, to some extent. F.lux attempted to bypass the review issue entirely by shipping their app as an Xcode project, so you could manually compile it and install on your iOS device, but got a Cease and Desist from Apple IIRC.
I've read somewhere that Apple has started to take extra measures to further disallow calling private APIs starting on 9.3, but I'm not sure on the details.
For objective c on osx generally "private" means: we didn't put it in the header file, but you can obviously dump out that information and glean what functions do what.
Then because objective c function calls are just message passing, you can send that off.
It is no real different than C in this regard, private means just that it isn't publicly exported. It also generally means it could go away or change with an os update. So they tend to break often as they're generally ending up as public apis that apple doesn't yet want to commit to.
To block things from using the api means you would be checking every call site invocation. Not really possible with the message passing style of objective c.
Even if it is running as a user you would have to do something like:
function () {
if !allowed_uid()
dunno segfault
else
ok cool do things
}
That whole process would use up needless energy or ram which on a mobile why bother, just tell people to stop using private apis and kick them out if they do.
Strictly speaking, a private API is a callable function which is not documented as a public API. If you expose an API to the user/customer, you have to decide which functions are supposed to be called and for those public functions document them. As soon as you declare a function "public" you also have to make certain guarantees about them working, and ensure they continue to work as intended into the future.
Private functions are residing in the same libraries as the public ones, so depending on the language used, it takes a little bit more or less effort to find out about them and call them, but they are not intended to be used from the outside. Often enough, it is just because no one wants to document them or guarantee for future compatibility. But private functions are not as rigorously tested as public ones, or not for all use cases. Also, the caller can only guess how they are supposed to work, this directly leads to security implications, the call could screw up or just crash the device. So it is quite understandable, that calling private functions is discouraged by software companies.
Apple forbids the usage of private APIs in their app store guidelines. f.lux worked around this "limitation" by loading the binary code which did the private calls after being installed by the user - which is also against the app store guidelines. So they overstepped the rules on two accounts which caused the ban.
It's not documented or in the public headers. Meaning you do have to do a bit of fiddling in your app, but that just amounts to using reflection to use the API.
Just because an API is private doesn't mean it's privileged. Indeed, many once private APIs have later become public. Apple does scan the binaries that are uploaded for private API use, effectively banning them from the store.
One of the main reasons for banning use of private APIs is that those are usually in flux. They're not release worthy, and the last thing any platform maker, be they Apple, Google, or Microsoft, wants, is for a private change to break a bunch of 3rd party apps. These private APIs might also be doing things that they don't want just anyone to be able to do.
I recently had a need to stop and re-start f.lux (on Windows). I noticed that it was slow to start and suspected it was accessing the network. Since I had disabled automatic updates, that was strange.
Switched to process explorer and found f.lux connected to three different addresses out there on the wild internet.
Fishy, to say the least. You need permanent internet connections to do what you're ostensibly doing? Replaced it with open-source alternative "redshift".
iOS 9.3 has a feature called "Night Shift": "Night Shift uses your iOS device’s clock and geolocation to determine when it’s sunset in your location. Then it automatically shifts the colors in your display to the warmer end of the spectrum, making it easier on your eyes. In the morning, it returns the display to its regular settings."
Voted up because I had to get halfway through the comments (and even searched "apple f.lux" on Google but only turned up results from November) before finding the name "night shift" that I could then google and get the background.
Is there a better way for submitters to include a second, explanatory link for context when the linked article does not provide any?
Here's the related MacRumors article with more info on Apple's Night Shift app. It's currently available to developers but apparently only runs on iPhone 5s and iPad Air and later.
While they are spending time fighting on Apple's platform, I wish they'd spend a bit more time on Linux (Ubuntu) and android platforms. There are large number of users on those platforms. Their Ubuntu version works OK (not sure about other Linux variants), but there is no android version.
Makes sense. So many people get up in arms when a competitor starts trying to do their job. That doesn't make sense to me... There is so much to do, so many challenges out there to address. If someone wants to do exactly what you're doing, why not let them? Most people struggle to find a worthy successor. It's a gift. Take the opportunity to move on to the next phase in your life, which has a good shot at being even better. You're smarter now, after all.
I know some people feel they only have one good idea in them, but I think that results from either a) aiming too high on subsequent rounds, or b) phoning it in. But if you love to work, just start small and you'll avoid both of those things.
Part of me was hoping they'd let it go. While awareness of this issue is greater now than it was six years ago, I'm not sure if they've been pushing this wave closer to shore or merely surfing it.
If this is truly the world health issue they think it is, now that iOS is taken care of seems like they should focus on Android, TVs and Kindles instead of begging Apple to let them compete with a built-in feature.
After their last PR push and petition campaign (which landed them on various media outlets and the HN homepage twice in three days) it took them 7 weeks to land 5,000 signatures.
I appreciate their passion but talking about cancer, weight gain and acne -- while providing affiliate links to salt lamps and Swarovski crystals -- just feels weird.
What I find strange is why they developed an iOS version at all, given the restrictions. They could have provided the top-selling Android version. I had to give my money to some other clone, I would have much rather given it to the innovators.
"90 hours a week and loving it. Like the T-Shirt? I'm going to give it to my people. Some of them work even more than 90
hours a week." (Steve Jobs depiction)
Woz says it's the only accurate one about Jobs and company. So, whether those words or not, I can only assume jobs worked his people to death to achieve Apple's success. Other things are consistent with that. Then, I hear they're "joining" f.lux to help their mission of improving sleep or whatever. Haha...
F.lux is great but the root of the problem is the type of backlight that monitors use. A hardware company ought to come out that produces a decent monitor with multiple backlight bulbs.
I mean, look at the difference in abrasiveness of spectrum between these bulb technologies:
I would love to have f.lux on my un-jailbroken iPhone. Currently I use Twilight App on a Nexus by my nightstand during the night because of how harsh the iPhone screen is in the dark (even with brightness turned down all the way).
There's a similar, more flexible, open source app you can sideload via Xcode here: https://github.com/anthonya1999/GoodNight . I use it on my non-jailbroken iPhone and iPad. Does the trick for me (all orange, all the time).
Nocturne in red mode is far better for sleep conservation. I started using it over flux because many moons ago I developed an obsession for preserving night vision while standing watch on the bridges of ships, and can attest that you can pass out cold while editing a document with Nocturne in red mode.
> Today we call on Apple to allow us to release f.lux on iOS, to open up access to the features announced this week, and to support our goal of furthering research in sleep and chronobiology.
I'm confused, why do they want this? Night Shift does what f.lux does. Apple opening up the APIs to allow f.lux to run on iOS seems rather pointless, since the OS is already doing the same thing.
Would anyone care to actually answer my question, instead of just downvoting? I didn't realize this was one of those "bury anyone who's not anti-Apple" threads.
You quoted it yourself: "to support our goal of furthering research in sleep and chronobiology." F.lux isn't just trying to sell an app. Also, Apple has a history of releasing user-friendly but very bare-bones, feature-light tools; f.lux presumably wants the option of releasing a richer app that does things Night Shift doesn't.
From what I understand, Night Shift does basically the same thing as f.lux. f.lux has been out for years, and I'm not aware of any particularly innovative changes done to it in that time.
"Please acquire us"
I coded an f.lux script that runs in background, and it's 213 lines long. It control the screen brightness and colour tone trough DDC by running dccontrol once in a while. Hiring him/them would cost more in overhead then it would cost to write the application.
This, right here, is why I abandoned the Apple ecosystem. When a company has the kind of control that Apple has with the app store, they will inevitably abuse it.
It's a bit different because (outside of irrelevant Windows Phone and dead Windows RT) the MS app store is optional, just one of many mainstream, widely accepted ways of installing software. Whereas with iOS, if Apple says no App Store for you it means no access to the iOS customer base.
1. It's a feature, not a product. And a simple one, conceptually. As much as I'd love to have competition in apps offering this functionality (like keyboards), "make my screen more red" isn't exactly rocket-science.
2. It's not well-designed. Their messaging mixes up two very different use-cases: matching the color of your room and aiding your sleep. That's ok - I use it for both - but there's no way to customize it. Even a super-simple option would let me communicate that I only want it on after 10:30 pm, a couple hours before I go to sleep, when I darken my room. Instead I need to deal with it automatically turning on every day at 4:30 pm, which makes something that should be simple very cumbersome (I have to manually turn it on and off every day in the winter).