Apple Forbids Sideloading f.lux
Apple has contacted us to say that the f.lux for iOS download (previously available on this page) is in violation of the Developer Program Agreement, so this method of install is no longer available.
We understood that the new Xcode signing was designed to allow such use, but Apple has indicated that this should not continue.
[…]
It is proven that screens can negatively influence sleep, and we believe that f.lux makes a significant improvement, as it mirrors very closely the research on blocking blue light before bed. But as we’ve discovered, it is even difficult to conduct basic research in this area, because so many people today use mobile devices (with closed APIs) right before bed.
[…]
Technology and devices that know more about our bodies could make a major impact on health and wellness, and these are the reasons why we work on it every day.
For years, f.lux has been the app I most wanted to see on iOS. It really does make my life better and help me to sleep.
F.lux is a popular Mac app that’s been downloaded 15 million times, but with side-loading no longer available, f.lux for iOS is non-existant. F.lux’s developers are urging customers who want f.lux for iOS to send feedback to Apple, as the company would need new documented APIs to introduce the app through official channels.
Come on, Apple, at least allow f.lux’s developers to make available a regular f.lux iOS app. It really helps against eye strain.
iOS Developer Program License Agreement, 3.2(g) (via Jay Tamboli):
Applications developed using the Apple Software may only be distributed if selected by Apple (in its sole discretion) for distribution via the App Store, VPP/B2B Program Site, for beta distribution through Apple’s TestFlight Program, or for limited distribution on Registered Devices (ad hoc distribution) as contemplated in this Agreement
So every open source iOS app violates the rules? If so, the rules are insane.
Previously: Sideloading f.lux on iOS.
Update (2015-11-14): f.lux’s author:
If this were only about reverse-engineering or using LLVM to compile code I wrote, it would be reasonable to fight it. The remarkable thing about their agreement is that it concerns using information that is not provided under the agreement. This is a reasonable term for app store distribution, but it seems unprecedented and heavy-handed for unsigned binaries.
Ultimately, we pulled the app both to show good faith, and also because we were asking hundreds of thousands of people to use Xcode to make accounts and sign our software. When Apple calls up and says they don’t want that to happen, it is not really a thing you can fight. It’s their infrastructure, and they can decide how it is used.
We were feeling pretty good about introducing “building stuff in Xcode” to people who’ve never tried it before.
We have been as polite as we can to Apple in hopes that they will open up the platform to developers like us. The demand for f.lux is certainly incredible.
This isn’t hype — f.lux works. It works as advertised, and it’s great. I’m a night owl, I write a lot at night because it’s peaceful and I can concentrate better. Before using f.lux on my Macs, I always went to bed with red, teary, sore eyes. The strain was perceivable, and I had to take frequent breaks and turn the desk lamp off for a bit. And when I had to stay up until the wee hours of the morning, I never ended up sleeping very well, either. After installing f.lux, everything changed instantly. At first it was strange to look at the altered colour temperature of the Mac’s screen, but I adjusted quickly, and the eye strain disappeared right away. As I’ve often said, f.lux saved my eyes.
[…]
Well, I urge Apple to reconsider and look the other way, or to work with f.lux’s developers to find a way to allow them to ship a regular iOS app. It saddens me that something this useful is not allowed on the App Store, while a generous quantity of utter, useless crap is.
Update (2015-11-22): Noah Kulwin:
“The last six months of ‘sideload’ press — which Apple didn’t try to stop — had convinced us that Apple would be receptive to an approach like this, but they seem to disagree,” Michael Herf said. “I asked him about open source used in a similar way, and he did not answer clearly, but he kept repeating the party line that we should make apps that could use Public APIs.”
12 Comments RSS · Twitter
Jeez. And there I was, thinking that Apple was slowly starting to relax some of the dumber restrictions on iOS... I guess I was too quick to give them credit for this.
No iPad Pro for me after all.
"Jeez. And there I was, thinking that Apple was slowly starting to relax some of the dumber restrictions on iOS... I guess I was too quick to give them credit for this."
Money keeps rolling in. UX keeps degrading. Supply chain expert and incompetent design "expert" in complete control. No competition in sight. If it ain't broke in the next financial quarter or two, why fix it?
I believe the word that applies here is "hubris".
The comparison to open source is silly. They distributed compiled and signed code with explicit intent to circumvent. If they released it open source, there wouldn't be a problem. What's so secret in their app, anyway? If Apple can't audit the app for inclusion in their store, and I can't audit the source of the app, then why should you trust it?
@Zachary I don’t think it’s so much a comparison to open source as a literal reading of the license agreement. It seems to say that applications cannot be distributed except via Apple’s programs. That Apple does not enforce this for open source apps does not mean that it couldn’t. As has been shown so many times, Apple can’t reliably audit apps, anyway, so it comes down to whether you think the developer is reputable and/or whether you trust the iOS sandbox protections.
@Michael: "applications cannot be distributed except via [Apple-controlled channels]" is the key phrase here. As Zachary says, this was a blazingly obvious attempt to circumvent AppStore with a [re]packaged product targeted at ordinary end users. The f.lux developers' motives are understandable here; but Apple's pram, Apple's rules.
Teaching users how to circumvent Apple's gatekeeping is not something Apple wants, for two reasons: 1. Half of the reason for AppStore-only distribution is so that ordinary users never have to think (or worry) about security or legitimacy of the source, which is a major selling point for general consumers. 2. The other half of the reason is that Apple has established carefully placed toolbooths like AppStore and iTunes to ensure the platform generates multiple streams of revenue for itself (something that becomes increasingly important as the hardware itself grows ever more commoditized).
It's a completely different scenario to some geek pulling some random source off the interwebs and building their own app in Xcode and deploying it for their own use in iOS. Apple couldn't ban that process even if they wanted to as it's completely a valid part of the app development process. Choking their free supply of shiny new third-party apps for users to purchase would do unhealthy things to one those aforementioned revenue streams.
Similarly, trying to define in absolute precision every single last detail of what developers may and may not do would would result in a developer agreement so enormous and intricate every third-party developer would need their own corporate law department just to interpret the damn thing, never mind implement products that fully adhere to it. The way the developer agreement is phrased sounds like overreach, and it is, but it's still by far the lesser of evils, providing a workable framework for the majority of developer use cases, while guaranteeing that discretion around the edges is all Apple's.
@has I think we agree here. What f.lux was doing was clearly in violation of the agreement. Except that I don’t necessarily think the overreach in the agreement is good for anyone but Apple.
Apple's decision here is unambiguously correct. The f.lux developers are being extremely disingenuous when they say their distribution was not against the agreement and was surprising. And no, despite what Mike Ash says, this decision has no consequences whatsoever for open source apps.
The reason for all this is because f.lux wasn't distributing source. It was distributing a pre-built binary, with a tiny Xcode project wrapper that simply re-signed the binary. It should be immediately apparent that this is not the intent of the new Xcode signing functionality, and that it violates the spirit of the developer agreement, if not the actual letter (I haven't actually checked to see whether it does violate the letter).
Apple has made it very clear that any binary distribution must happen through the App Store (or through enterprise distribution, where applicable). This has been the hard-and-fast rule since day 1, and f.lux was very blatantly violating this rule. Apple absolutely has to crack down on this immediately, because they can't let it go unchallenged or other people will do it too. The only world in which Apple should let this slide is one in which they go ahead and open up true side-loading of apps to everybody. But they aren't going to do that (for various reasons which you may or may not agree with, but many people, myself included, do), which means they can't allow f.lux to continue doing this.
@Kevin Yes, it’s totally clear why Apple is cracking down on f.lux. But I’m curious why you think open source is allowed (rather than tolerated by not enforcing the agreement). The agreement says how applications can be distributed (as I quoted). As far as I can tell, it does not say that “application” means binary rather than source. In fact, it doesn’t talk about “binary” or “compilation” except to say that you’re not allowed to “decompile, reverse engineer, disassemble” (which pretty much everyone does when debugging) or “enable others to” (which Hopper does, and it’s in the store). I don’t think that Apple would be happy with f.lux if it were distributed as source. And, more generally, I think Ash is right that there are probably a lot of reasonable things that do violate the rules, only Apple is choosing to look the other way. There are well documented problems with rule systems that work like this.
@Michael: I think we agree in our agreeing here. The overreach exists for Apple's direct benefit (just like everything else Apple does, natch).
Its benefit to third-party devs is indirect, in that it keeps the developer agreement short enough to read through and sign on this side of the next century. For the vast majority of devs - who have no interest in poking at the boundaries to see just how far they really reach - this is preferable to the alternative, so it suits them too.
...
The real point that needs made is that other devs going off on Apple over this are really being disingenuous, and not a little dishonest - to themselves.
As I've said before, it's Apple's playpen and Apple's toys, and we're just guests in it entirely at their discretion. It's foolish to sink significant amounts of your own time and resources into decorating their home on your own initiative, and then believe they owe you in return. They do not. And what's more, if they don't like what you've done then the cost of undoing it all is entirely on you too.
The f.lux devs' hearts may have been in a good place, but their brains very clearly stepped out for lunch, and an extended liquid one at that. As in playing the stockmarket, when writing software for someone else's platform, never invest more than you're willing to lose. (And definitely don't whine when you do lose that shirt, because now you're just advertising to the world how you've been a fool.)
@Michael: "There are well documented problems with rule systems that work like this."
There are well documented problems with systems, period.
Honestly, the only way anything ever gets done at all is by NOT thinking on the details, cos soon as you do you're screwed. :p
[…] Apple Forbids Sideloading f.lux, Night Shift in iOS […]
It never ceases to amaze me how much resources Apple wastes on enforcing ridiculous policies.