Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
As others have said, this is such an incredibly off-putting attitude of Apple. It is insulting and belittling, as if I am not capable of deciding what is useful and "safe" on my own phone. It is also harming me as a user - I absolutely in no way benefit from Apple's refusal to admit this in the Appstore. And finally, now they even try to interfere with side-loading - in other words, if someone had written this themselves, it would be fine, but distributing the code is not? Talk about heavy-handedness. Instances like this remind that, no matter all the smooth talk about "open-mindedness", etc., this is simply a big company with a highly controlling attitude.
 
As others have said, this is such an incredibly off-putting attitude of Apple. It is insulting and belittling, as if I am not capable of deciding what is useful and "safe" on my own phone. It is also harming me as a user - I absolutely in no way benefit from Apple's refusal to admit this in the Appstore. And finally, now they even try to interfere with side-loading - in other words, if someone had written this themselves, it would be fine, but distributing the code is not? Talk about heavy-handedness. Instances like this remind that, no matter all the smooth talk about "open-mindedness", etc., this is simply a big company with a highly controlling attitude.
Almost a decade later, is any of this still somehow new or surprising in some way?
 
Some of you aren't getting the point. Apple isn't preventing them from releasing the source. I think the main issue is that the "source" you download has a pre-compiled binary in it. A binary that can be f.lux, or can be malware that sends all of your data to a remote server. There's no way of you knowing. They won't release the actual source code because what they do is patent pending. If the released full source code to github as a proof of concept or something, there's nothing Apple could do to them.
 
  • Like
Reactions: ErikGrim
This story is gaining momentum. Apple won't backtrack on the blocking via sideloading issue but this may result in more public APIs to legitimately release such a feature in future versions of iOS. This is the best case scenario as it allows for other app research into colour and accessibility such as a specific app for those colour-blind to make the temperatures more bearable..

WWDC is easily 6+ months away though, have Apple ever released a +0.1 update with added APIs before?
 
Some of you aren't getting the point. Apple isn't preventing them from releasing the source. I think the main issue is that the "source" you download has a pre-compiled binary in it. A binary that can be f.lux, or can be malware that sends all of your data to a remote server. There's no way of you knowing. They won't release the actual source code because what they do is patent pending. If the released full source code to github as a proof of concept or something, there's nothing Apple could do to them.
I'm not convinced the reason for not releasing the source code is to protect their patents. A patent for this (if approved) would prevent competitors from making a clone of this app even using their own code. Likewise they can open source the software and still hold copyright over it to prevent anyone else passing it off as their own or trying to sell it on. It's not likely to be for nefarious purposes but it's probably because they don't want anyone to know what private APIs they've used.
 
in other words, if someone had written this themselves, it would be fine, but distributing the code is not?
I don't think that's quite correct.

I thought the issue was that F.lux was being distributed with pre-compiled binaries in lieu of the actual code.

If don't think there'd be any issues with "side-loading" if it went like this: I (1) write code that results in an app, I (2) send you that code, and you (3) review the code to make sure it's not doing something that you didn't expect. You (4) compile the code into binaries and (5) side-load those binaries on your iOS devices.

It seems like with F.lux, they skipped step 2 and jumped straight to step 5, which means you couldn't have done step 3, which IMO is a pretty important step.

Interestingly on the article comments mentioned a few posts above, "other people" are now hosting the F.lux binaries, which has already resulted in a conversation of trust that went like this (names/download links removed):

User 1 • 4 days ago
Here ya go: [download link]
  • User 2 • 4 days ago
    Please don't download this copy, not the original version!!

    Should be:
    MD5 = 5245665a6d745cda946f6a09afefefa5
    SHA1 = f1ee4e38eddc467e7fbfe5708841bbc84f520d7e
    • User 1 • 4 days ago
      It's the original copy. I have re-zipped the folder.
  • User 2 • 4 days ago
    Well, that explains the checksum difference. Sorry mate.
 
So good that we are forced to continue burning our retinas every evening and morning. Probably they will come out with a new health device in a couple of year that will heal our sore eyes.

Doesn't the easy access dimmer control already accomplish this.
 
Nobody cares because this is for tech users and not iOS users.
You do realize this makes no sense ... yes? If this wasn't for iOS users ... Apple wouldn't have made a flux clone with Night Shift built into iOS.
 
Apple "Sherlocked" f.lux. Plain and simple.

Not so simple. Sherlock was an app already available for Mac OS users to install using the standard and recommended app installation procedure.

f.lux, for iOS, never was.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.