After reversing the new APIs in iOS9, it’s really really clear that Apple has added lots of great features to iOS (and the new devices) to adjust screen colors. The new models even have RGB color sensing, so they are an ideal platform to build f.lux on. (I was pretty excited about our next version!)
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.
> 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
I called this yesterday[1], and I was told Apple would never do this.
Now that they did... Gee, colour me surprised!
To be honest I'm a little bit surprised. I assumed it would take more than 24 hours. Good job being the tech kill-joys you always are, Apple.
When it breaks they have to deal with it, not the f.lux team.
It's the same reason they don't want apps that ask you to throw your phone in the air, or put a bag full of sugar on the screen for weighing purposes.
Not justifying anything just explaining their PoV.
This is a bit of a strawman argument, F.lux is not in this category of silly apps. F.lux is a reasonable app it has a good track record respecting its users and is requested by many many users. It is about control.
Think about the cost to Apple's support teams after grandma is having problems with her phone being yellow. Her grandson definitely was not messing with her phone, at all...
I'm rather confused as to why you thought the following:
> We understood that the new Xcode signing was designed to allow such use, but Apple has indicated that this should not continue.
Where has Apple ever indicated that the new Xcode signing was intended for your use-case? I never saw the download you provided, but I'm assuming you didn't actually release f.lux as open source, but instead just provided essentially a prebuilt download and had Xcode re-sign it. Is that assumption correct? Because that seems to be a pretty blatant violation of the spirit of the developer program, even if it's not explicitly spelled out in the agreement. The new Xcode signing model is intended to allow people to get started with iOS development without paying any money, so they can build and run their own projects on their own devices, and only have to pay for the dev program when they want to start distributing to other people. If you did in fact release f.lux as an open-source project, that would be within both the spirit and the letter of the agreement (I doubt Apple has any problems with people installing open-source apps on their personal devices). But it should be obvious that Apple wants all binary distribution to be done through the app store (or enterprise distribution where applicable).
Speaking of enterprise distribution, did you ever investigate that approach? I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement. But I've never actually looked into it myself so I don't know.
I gotta say I was infuriated until I read your comment, you totally nailed it.
Distributing binary code to thousands of iOS users is dangerous, if nothing else. So Apple clearly has a point trying to control distribution through the app store.
And if the author truly does believe in curing sleep issues, as they state, then they should have released the source code and let people install the app themselves.
In fact, with 176000 page views, and 15 million downloads of their desktop app (I myself have been a long time user) I don't see why he didn't just pay the 99 USD and distribute it via the app store. I certainly would have payed for it because it pains me to see my SO in bed solving sudoku with a flipping 50W lamp in her face.
That's correct. Additionally, although there are many ways to work around these static code checks Apple performs at app review time (due to Objective C's runtime capabilities), you can bet an app as popular as f.lux would get pulled very quickly with potentially long-term damage to their relationship with Apple*
> "I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement."
There are. Using enterprise distribution to distribute to the general public is explicitly disallowed for some IMO really good reasons (the ability to call private APIs being a big one).
There's some gray area when it comes to using enterprise distribution (e.g., to external testers not otherwise affiliated with your company) and Apple generally doesn't police these, but allowing the general public to install is very, very much against the rules and will get you banned.
So that's how it is nowadays, pay the Apple extortion fee it's good for you . As an app developer with principles I will never endorse Apple's business model as it is toxic and destroying the open internet. That users will not find the app is actually good as it might make them consider switching provider for their mobile OS and one less iOS user is a victory for anyone carring about the health of the internet market and mobile ecosystem at large.
> So that's how it is nowadays, pay the Apple extortion fee it's good for you .
That's not what OP is saying, though. The f.lux folks were leveraging private APIs, that are unpublished and not part of the set of tools you're authorized to build commercial apps on for iOS. Apple doesn't want to support those APIs for whatever reason, so they're not included in the toolset. Just because you can find a way to do something (like distributing binaries to have users compile into their own version of an app, trusting that the distributor is trustworthy, that the distribution hasn't been corrupted somehow, that...) doesn't mean it should be allowed willy nilly.
Strong requirements like this at some level have kept quality in the average iOS app high.
I recently dumped Android for iOS again because I got sick after 4 years of my devices never quite working right. If I don't have to spend so much time on my iPhone policing apps from randomly deciding to go off the reserve (like happened even with quite popular apps on Android), I'll take that over complete unfettered license to muck about in the operating system.
Cause that as a practice just doesn't turn out well. For every f.lux there's 100 development operations who are gonna screw something up.
I've been an Android user ever since 2011 and I also own iOS devices. Care to name "popular apps on Android" deciding to "go off the reserve" and that don't work?
My first smartphone was actually an iPhone 3GS. Because of Apple's walled garden, it couldn't help me with a really simple and downright obvious task for a smartphone - blocking unwanted phone numbers from calling or texting me. People had to jailbreak their phones and install Cydia in order to do that. And because Apple caters to users instead of mobile careers, my iPhone could not tether my 3G connection either because Orange wasn't allowing it without an extra $5 per month. Oh wait, I think I got that backwards. So another use-case for which my smartphone was completely unsuitable for.
Now I've got an iPhone 6s that I received as a gift (well, I'm blessed with friends that think I want Apple stuff just because I use a MacBook for work). And I find the restrictions to be as annoying as ever. Yesterday's Firefox release for iOS reminded me of this very fact. On Android I've got the real Firefox and it can do extensions and it can innovate. For example I was blocking ads long before iOS 9, the very concept of ad blocking happening for Firefox first. Plus I use Firefox on my desktop so syncing is nice and I hate monocultures, like what WebKit has become. You see, I couldn't give a crap about F.lux, but I do care about having Firefox, as it's the open-source browser that saved the web and the browser that now keeps WebKit from taking over the whole market, like IExplorer 5 and 6 once did.
> I'll take that over complete unfettered license to muck about in the operating system
I understand that, but this is were we disagree the most. In society people can be very evil, people can steal from you, can leave you without your job, people can hurt you and your family in myriads of ways. Yet we can cope with this uncertainty, as we've invented institutions that protect us in times of need, we came up with rules for interacting with society (e.g. the concept of trust), we do our part in educating our children to not be complete assholes and all of this usually works, in spite of having certain rights and freedoms, like the freedom of expression, the right to having property, or the right for privacy. People often forget about that last one of course, as we increasingly prefer to police our peers in the name of security, in spite of a lack of evidence that it leads to a more secure environment and often forgetting what it is like to live in a police state, though as somebody that grew up in an Eastern Europe country that was once a police state, trust me when I say that's not nice.
But back to the point - personally, I consider any platform that rejects useful apps to be completely inappropriate, no matter the reasoning. And of course, Apple can do whatever they wish with their property, which is a fundamental right after all, but that doesn't mean I can't exercise my freedom of expression to bitch and moan about how much that sucks.
As is the expected answer to your softball there, no, I don't keep a list of apps I had issues with in my back pocket. You can choose to disregard my previous post if you'd like given this shocking revelation, that's kind of the point right?
I suspect there's a solution for every trouble I had, but the point is that after 4 years I don't want managing a phone to require that much of my life.
> I understand that, but this is were we disagree the most.
Apple isn't the USSR, nor a post-USSR bloc state. It's in a sense an agreed-upon model for the social structures you're discussing here.
Many, many consumers have chosen the ethos of Apple-as-institution.
Not sure what your point is with the right to privacy stuff. I'm not sure I've seen compelling evidence that Google of all companies protects your privacy any better than Apple.
Edit: Here's one[1] comment at least on the different approaches the two companies have taken, and the advantage Google may have with it's softer stance on protecting your privacy. (Though, I'm sure the source is biased in some way, it's just one article.)
But back to the point -
It's good that your personal definitions disagree with the line Apple draws between "useful" and "potentially dangerous to the experience or stability of the phone." You should absolutely have your own opinion and make choices based on it, I've nothing to say in the contrary.
I can name everything that frustrated me over time on both Android and iOS. And I can certainly name ways in which the apps I use have failed. I also have a pretty bad memory in general, the only reason for why I can remember such things is because we humans have a pretty good memory for things that cause us grievance.
This is why I was curious, as I certainly want to learn from the experience of others. You not being able to name apps that you claim have been going "off the reserve" and "muck about in the operating system" is a pretty strong indicator that you're probably lying. Again, this is how trust works.
And I wasn't talking about who is providing better privacy, but about policing your peers in the name of some bullshit security claims and other nonsense. Practices which have been agreed upon, embraced actually in the former USSR by its people. Or maybe you've got the impression that the "social structures" in the former USSR weren't "agreed upon", but that would be odd.
Even more so, you seem to think that iOS apps don't go "off the reserve". Remember that time when it was discovered that Twitter on iOS is tracking installed third-party apps from last year? As if everybody else wasn't doing it - I know because I participated in the development of such an app a year earlier. And do you know how Dropbox detects movement to wake up its app in order to backup your pictures? It must do that because otherwise iOS doesn't leave background processes running, so instead Dropbox is asking for (and has the potential to track) your location. And do you remember when VLC was pulled from the iTunes Store (not sure why), with the iTunes Store being then filled with knockoffs guilty of using VLC's name and logo, and probably spyware (since that's what knockoffs usually are) with Apple not lifting a finger to clean that up?
There, I just named 3 instances for iOS without being a heavy iOS user.
> This is why I was curious, [...] is a pretty strong indicator that you're probably lying.
Like I said above, discount all of my comments if you'd like, that was your goal in the first place.
It's an indicator that I didn't keep a list, and that, as I said, I don't want a phone to be such an important part of my conscious experience that I could do so. I doubt any list I gave you would actually lend credibility here, as your position seems to be to discredit vs discuss.
> Again, this is how trust works.
Not really, no. Trust is established through a set of conditions two or more parties agrees establishes authenticity. You've just made demands, I'm pretty sure.
> And I wasn't talking about [...]
Neither of these products is "policing your peers in the name of some batshit security claims." Apple, Google and Microsoft have published ground rules for playing in their playground. You said above that you don't want to play in Apple's.
So don't play in Apple's. That's totally cool. I just got sick of playing in Google's. It's counter to your message to attempt to force someone else's compliance with your set of values, isn't it?
I think Apple may have been a bit too generous with this offering. How long does the code signing stay valid this way? Forever?
I think it would have been sufficient for the majority of use cases if an app sideloaded like this would only be valid for like 12 - 24 hours. I mean, as you wrote, this system is supposed to be for devs who want to test their apps on devices without having to pay for the dev program.
I think 12 hours would be enough time to judge you progress on device. Since you are going to test many iterations of that app, you are going to deploy it often anyway. Why would there be a need to have those apps work forever?
I realize there are edge cases where some people would want a longer, broad beta test for their app but is that really necessary for such a "free" option? Surely if you plan out your app of such scale and you arrive at that point in time to warrant a week long beta test you will very likely deploy on the app store anyway so you might as well buy into the 99 bucks a year program to correctly sign your apps.
Had Apple directly limited the time sideloaded apps like that work and made it public that this is "just" a feature aimed at developers to become interested in iOS development, this whole thing could have been avoided.
Why time-limit it? There's no rule that says you must publish every app you make to the app store. What if you're making an app that's intended precisely for your own personal use and nobody else's?
> 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 doesn't seem to be a winning strategy with Apple -- they move at whatever pace they want. A better move might be to continue to offer the download and show overwhelming interest in the product, enough that when they shut down the taps the users revolt and force Apple's hand.
Have you considered open-sourcing your code with a license you're comfortable with? http://choosealicense.com/
As a developer who suffers from sleep disorders (both sleep apnea as well as general restlessness which is fortunately aided by f.lux!), how do I donate to your project (ideally in bitcoin)?
> We have a version internally (it looks beautiful!)
> but it requires a very complicated installation
> process. We are working to simplify this and ship
> f.lux to the Android OS as soon as possible.
I'd have thought Android users would generally be more willing to do this "very complicated installation" than iOS users would be to sideload with XCode, but there you go.
Twilight and Lux both contain naive implementations using a semitransparent overlay. The result of this that blacks and dark colors end up being brightened instead of left alone, as a proper color-temperature change would do. This looks bad on all screens, but especially so on AMOLED displays that support a true black.
Cf.lumen[1] is, I believe, the only Android app that can actually change the color temperature of the screen like f.lux can, but it requires root as well as installation of a special "driver" in order to do so. My guess would be that the "complicated install process" referenced by the f.lux devs is probably similar.
> And Cyanogenmod has a built-in color temperature changer anyway.
Really? Cool! Where is it though? I just went through the settings and couldn't find anything but Display & Lights > Colour calibration, which just gives some R/G/B sliders (that don't even seem to do anything?) no colour temp, that I could find.
I have no idea. But the developers (of f.lux) seem to claim elsewhere that the existing solutions aren't 'solutions' at all; don't do it properly.
I can't speak for the truth of that though. I've used the aptly named "Blue Light Filter" which seems to work fine. CyanogenMod OS bundles something which seems okay too.
CyanogenMod also has a very nice feature which adjusts the colour cast of the screen based on both time of day and the colour of the light hitting the RGB sensor.
It's integrated in CM. Not flux, but something that works very well (as opposed to twilight for example). Too bad I had to switch to 11. Anyone know of a solution that would work for me?
Well, Redshift is a lightweight program that also works, and has a simple-to-use shell command. That's attractive to some Linux-users :)
And it goes all the way down to 1000K, leaving only the red channel :) Which is not particularly useful, but it does make Redshift literally cooler than F.lux.
Thanks for the awesome software! f.lux was the only reason I jailbroke my phone, over a year ago.... glad to see its possible to install on an iOS device without jailbreak now...even if the install process is circuitous
After reversing the new APIs in iOS9, it’s really really clear that Apple has added lots of great features to iOS (and the new devices) to adjust screen colors. The new models even have RGB color sensing, so they are an ideal platform to build f.lux on. (I was pretty excited about our next version!)
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.