Apple Forbids Sideloading f.lux

It never ceases to amaze me how much resources Apple wastes on enforcing ridiculous policies.

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 […]