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.
I called this yesterday, 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.
"Please stop doing whatever you want with your device, we like to determine what you can do." Ok, bye.
Not justifying anything just explaining their PoV.
How does f.lux cause any breaks? What has Apple ever had to fix with f.lux sideload installed iPhones?
And what if I, the owner of the device, sign-off on the risks? If they have an EULA that covers such things, then why worry?
> 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.
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.
If I understand correctly, they can't do so since they are using undocumented APIs that they are not allowed to use in store apps.
(* See https://ifixit.org/blog/7401/ifixit-app-pulled/ )
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.
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.
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.
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 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.
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.
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?
Apple never officially explained the decision, but from what I've heard it was to encourage Swift adoption.
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.
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.
I'll go one further, it (being polite as possible) is not even what happened. They weren't polite at all, they took a dump in the pool:
also because we were asking hundreds of thousands of people to use Xcode to make accounts and sign our software
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.
Cf.lumen 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.
- Lux (free/$3.80): https://play.google.com/store/apps/details?id=com.vito.lux
- Twilight (free/$2.99): https://play.google.com/store/apps/details?id=com.urbandroid...
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.
I think you can pay to remove the spammy ads, but it's otherwise free.
I've run it on my Ubuntu install for quite a while, at least a year I think? Am I missing something?
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.
I'll say! Is it really hundreds of thousands of people? That's fantastic.
It's a great app, keep pushing and apple will see sense.