A statement from f.lux about Apple's recent announcement
justgetflux.com
justgetflux.com
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).
At the very least Apple could offer acknowledgement.
EDIT: yes, you can convert light to orange. http://www.hurlbutvisuals.com/blog/wp-content/uploads/2013/0...
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.
Just because nobody had baked the feature in.
It was also impossible to have a screensaver on iOS, but this doesn't mean screensavers are a new thing.
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.
Browsers are just a feature, not a product.
Applications are just a feature, not a product.
Operating systems are just a feature, not a product.
Depending upon your POV, just about everything can be dismissed as "just" a feature.
No one is writing stuff for f.lux.
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.
Dimming with the sun just contributes even more to SAD 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.
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...".
What's non-classy about that?
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".
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.
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.
I can only imagine what this post would have looked like had it been say, Google in question.
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.)
Nothing related to Google at all(which is probably why you're getting downvoted).
For example?
You can find other examples if you look. I remember there being a big kerfluffle about it ~2 years ago or so.
You mean "persecuting", btw, and not "prosecuting".
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".
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.
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.
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...
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?
"Huh, how is f.lux doing that? The API looks like it's private."
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.
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.
You mean like we get right now whenever there's an iOS update?
And if they got the decision wrong they would be killed for it in the press.
You mean like they already are when they make an arbitrary, asinine, illogical decision about pulling someone's app?
Apple's approach to developer relations can be charitably described as that of the honey badger.
Just for reference: f.lux first released an app for iOS in 2011. So there's been four years, half of the entire lifespan of iOS.
https://github.com/jonls/redshift/commit/4818f331cedeba94bb7...
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.
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 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.
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/).
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 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.
I find it hard to fault them when I look at it like that.
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.
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.
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.
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.)
PS: I'm not very familiar with this expression, but isn't it like.. "co*k blocking"?
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.
e.g. Risk of Apple deploying a malicious binary: low [0]
Risk of J Random Dev deploying a malicious binary: higher, after they plug in a Thunderbolt adapter they found laying around at 32C3 [1].
So you might be willing to accept the risk of using a closed source OS, but an app doing interesting low level (?) things to the OS? Maybe not.
[0]: Yeah yeah, the NSA is going to force them to deploy a bad copy of XCode, I know.
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.
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.
edit: formating & clarity
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.
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."
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.
Closed source isn't a barrier to reverse engineering in any practical sense anymore. It's 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.
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.
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.
> 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.
> 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 ...
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.
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".
The brightness control that apps have now is a result of exactly this kind of process.
Only thing "unfavorable" about the way Apple acts exists in the perception of people who already have an axe to grind.
I mean, look at the difference in abrasiveness of spectrum between these bulb technologies:
http://housecraft.ca/wp-content/uploads/2012/09/spectral_res...
F.lux is great and helps but what we really need is an ergonomic monitor. That will truly give us healthier eyes and improved circadian rhythm.
Monitor tech is hard but this sounds like a great goal for a startup. :-)
http://www.health.harvard.edu/staying-healthy/blue-light-has...
"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."
http://jnci.oxfordjournals.org/content/93/20/1563.full
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.
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.
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.
> 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
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.
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?
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.
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.
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.
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.
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".
Discussed on HN here: https://news.ycombinator.com/item?id=10882261
Is there a better way for submitters to include a second, explanatory link for context when the linked article does not provide any?
http://www.macrumors.com/2016/01/11/apple-ios-9-3-night-shif...
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.
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.
https://www.youtube.com/watch?v=yG4DvM0wxdk
"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...
I mean, look at the difference in abrasiveness of spectrum between these bulb technologies:
http://housecraft.ca/wp-content/uploads/2012/09/spectral_res...
Tinting the color using F.lux is helpful but doesn't supplant the boon that a proper ergonomic monitor would for eye and circadian rhythm health.
how it updates the screen with notifications is a little hacky though so I'm glad they are bringing a native implementation.
hopefully this comes to OS X as well.
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.
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.
This isn't like Apple saying "No one can make lottery apps", they C&Ded someone to stop using private APIs and bypassing the app store.