Not only that, but the private APIs f.lux was using led to a really awkward implementation, complete with huge gotchas like the phone waking up every time the color profile changed.
It is odd that it is a binary blob, but it isn't dangerous in the same way as binary driver blobs on Linux. Everything you install via Xcode is sandboxed in exactly the same way as the binary blobs you download from the App Store.
Well, Apple didn't treat Flux any differently than other developers who used private APIs or tried to distribute binary blobs to iOS users.
Software running in the background is something Apple tightly controls in iOS (battery life and security being major concerns). They also don't let apps make changes to the OS appearance. That may be the wrong approach, but Apple is at least consistent in it. This was either an OS level feature or a no go from Apple's perspective. As a user I'm happy it's a feature!
Yes, that's the whole point of private APIs - they're not supported, and they can be changed or removed whenever.
It's just access control at the framework level. Apple could embed a copy in each application using the framework, but that's inefficient, so they install it at the system level.
It totally sucks that Apple prohibits third-party apps from offering useful functionality that requires deep integration with the system. So no, it is not exactly "OK."
However, it has nothing to do with rejecting apps because of it, and offering their own version of the functionality. Apple has always reserved this domain for themselves from day one, and f.lux would have had the exact same problems even if Apple hadn't been doing their own version of it.
Apple didn't have an API ready for that for external devs - not due to malice, but due to the lack of need. There are virtually no other use cases for such API, so no wonder they didn't release it.
Within a context of one app it's not that difficult to change the colour balance. What kind of an app would want to change the balance of colours system-wide?
It probably also means it will be built-in to Andriod next and then probably Windows itself. That could negatively impact Flux the product, which sucks for him.
F.lux is free software and they've said outright that as devices / systems implement color shifting as built-in systems, they've accomplished their goal.
> 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: [email protected]
Licensing from a fellow giant who will absolutely take you to court if you don't and repurposing the ideas of small indie developers are entirely different things.
I could be wrong, but I don't think Apple has a history of violating patents from practicing small software developers. Seems like they're pretty much only sued by patent trolls.
Yes, but it's much better that this stuff is built in natively to the OS. F.lux and equivalents I have used on Android often are gltichy given that they interact with the video system.
It's not just Android: on both Windows and Linux, F.lux seems to interact badly with certain Intel video chipsets, and often just turns on and off continuously until I reboot the system. It's great software, but having it native to the OS would be even better. I hope the other vendors follow Apple's lead here.
Hopefully then, OSX as well. I probably spend as much time (sadly) on my macbook as I do in front of my iPhone at night. F.lux is a lifesaver, but I'd prefer it builtin to the OS.
There's some annoying glitches in the Mac OS implementation. In particular, the profile gets reset to normal for a second or two when certain applications (particularly OpenGL games) start up or exit, and when the screensaver is unlocked.
While that's true, f.lux handles edge cases in important ways -- letting you disable it for certain apps or time periods, as well as "movie mode." As much as I'd like to see this feature be built into the OS, Apple tends to simplify away a lot of fiddly preferences by choosing what they hope are sensible defaults, and as much as I appreciate that in theory, in practice this might be one of those areas where fiddly preferences are superior.
You can compile and sideload any software yourself using XCode and an AppleID. I run Gamma Thingy (a f.lux alternative) on my non-jailbroken iPhone. You can compile and run emulators, use any private API, whatever. Those apps will just never be in the App Store.
It is a good point. I recently got a company provided phone and I strongly considered getting an iPhone, especially since it's the dominant platform at my company and most internal apps are developed for it exclusively. However, I started tallying up what functionalities I would have to give up and decided against it, a flux like program being one of them.
