f.lux for iOS is no longer available
justgetflux.com
justgetflux.com
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.
> 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.
- 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.
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.
[1] https://play.google.com/store/apps/details?id=eu.chainfire.l...
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 think you can pay to remove the spammy ads, but it's otherwise free.
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
I'll say! Is it really hundreds of thousands of people? That's fantastic.
> 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.
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[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.
1: http://www.cio.com/article/2938766/privacy/how-apples-privac...
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.
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.
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)?
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 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.
"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?
It's a great app, keep pushing and apple will see sense.
P.S. I say all of this as someone who has recently converted to iOS from Android after many years of loving Google Nexus devices, and wanted to see what the integrated design of the iPhone 6s Plus was like. I absolutely don't support ANY of the major technology companies as people who won't do the wrong thing so that they can make more money. They're all self-interested actors! We should never forget that. They can be just as evil as big oil or the textile industry.
EDIT: to fix phrasing and the omission of a couple words
In this case, the fans are literally not being allowed to wear their rose-tinted glasses...
You never come close to owning the device, and you don't own your software for it.
The greatest irony is how many walked into this with open arms, and how many continue to praise this. iOS only thrives on the developers who sacrifice their power to Apple's will. Apple stands atop a glass house built on lock in and memes about how good their products are. Its the users that pledge allegiance to that manipulation that hold it together.
Every human is innately free whether or not a governmental entity likes it or not. Whether or not those rights are oppressed or not is another story.
As humans, we routinely violate those rights.
You did ask :-)
Secondly, a "right" is a human concept, born of human logic. It is not natural, the Universe & Reality doesn't care one way or another what "rights" humans have.
To engage in a little snark, I wonder how long it will be before Apple adds a feature to the next version of iOS that allows f.lux-like functionality, and then claim they invented it.
Ironically when people starting creating actual apps using HTML via PhoneGap and the like, Apple was resistant to that too!
The platform is just another package manager under the hood. No doubt based off of the hard work from the unix community on which iOS is based.
Apple fanboys have a long history of taking credit for the whole cake when all Apple tend to do is put on the icing.
It is delicious icing no doubt, but credit where it is due.
Parent comment is mostly rubbish, but I'll concede that he has a point about programming for Android.
Compared to most other systems I've touched, programming for Android feels incredibly heavy and tooling reliant.
Android Studio and an updated toolchain has made it less painful than it used to be with Eclipse, but it's still nowhere as nice as making a standard Web-app, or WinForms app or something like that.
I'd love to just blame Java, but really... The Android API could take some sweetening up too.
I can take a bunch of OSes and run them on standard x86 hardware and peripherals more or less, build my own OS if I want to and run my own apps with the compilers, linkers and frameworks of my choice. Skip forward a few years and there's a good chance that will all be gone.
x86 is also a less than ideal proposition with Intel the only game in town - sure they are Open Source friendly for now but still it would've been a better world where the likes of AMD and VIA were flourishing in x86 land.
I've long thought that Apple would have been a way, way worse monopoly than Microsoft ever was.
I'm so glad Android saved us from that.
I don't agree. I grew up with Microsoft ruling the world. The biggest problem wasn't the dictatorship, is was the poor quality of the experience in the face of the dictatorship.
Apple has major flaws in its experience, but they're nowhere near as bad as the dog days of Windows 98.
It's disingenuous to claim user experience requires a closed and non standard system. And besides that Microsoft and Linux distros have made steady progress towards improving the quality and experience while still keeping the PC ecosystem open.
For the PC, things started taking a turn for the worse with EFI and SecureBoot, but before that it was quite open.
However EFI and Secure boot have not changed anything at all. UEFI is a standard and most vendors use the reference implementation from Intel and its all at least as good as BIOS in terms of being documented.
It's remarkable that I could easily dust off my 2002 era desktop and boot a modern Linux distro, but that trying to get my 2013 era tablet to boot anything other than the Android 4.4 that it shipped with would be a huge struggle. It's such a shame things are going this way.
Almost none of this is actually true, just to clarify a few points:
- Apps (for the App Store or otherwise) do not have to be written in Objective-C or Swift (see: RubyMotion, Xamarin, PhoneGap/Cordova, React Native, J2ObjC, RoboVM, that thing Microsoft is working on, probably others I don't know about or have forgotten)
- You don't have to buy anything to put an app on your personal iOS device, you just download Xcode and work from there (more on this later)
I'll concede that you can't access the hardware directly from iOS, meaning yes, it does have to be accessed through APIs, however allowing direct hardware access is a massive legitimate security risk. However, you absolutely do own the device as it exists as hardware. You don't own the software on it, but that's the same for every proprietary software product in existence. What you own is a license to run the software for certain purposes. Whether or not this is a bad thing is for you to decide, but this is not a problem unique to iOS. Furthermore, if you write an app using your free copy of Xcode and put it on your iOS device, you absolutely own the copyright for that app.
Now, as for what is true in your comment, yes, you do have to pay $99 a year to distribute apps using the App Store. More than anything else, I believe this is why Apple could not allow this to continue. If this became a trend among iOS app developers, it stands to reason that they would lose a lot of money from developers distributing this way instead of using the App Store. Yes, f.lux is free, but they don't want a trend starting and even with free apps you can still sell advertisements. Again, I'm making no judgment on whether or not it's morally just for Apple to do this, I'm just explaining why it happened in more specific terms. Second, doing this completely subverts Apple's security features. The ability for users to load arbitrary apps onto their devices was to allow people without $99 to run apps that they made on their own devices.
This was a privilege originally only afforded to registered developers, and this was intended to lower the barrier to entry for iOS app development. When it's one person writing apps for fun and loading them on their phone to test and show their friends or whatever, the security risk is low. When it's groups of programmers telling people to download a precompiled binary that can't be inspected to ensure its safety and load it onto their devices, it becomes a massive security risk. (as a free software person, you should know that even for us that chose to load it, we don't know what the fuck it contains. f.lux is not open source. for all we know, we just loaded a ton of malware onto our iOS devices.)
It should be noted that there are shit tons of open source iOS apps, and so far Apple has not told them to stop providing the source for people to download, compile, and sideload.
https://github.com/dkhamsing/open-source-ios-apps
There are so many reasons aside from locking down iOS that Apple could have locked this down for. You can't read the source, it's a proprietary app, it subverts their developer agreement, and it's actively encouraging people (176,000 by their count) to load a binary onto their phone the source of which they can't read and that by the developer's own admission is using undocumented APIs.
Now, if Apple said that you were no longer allowed to load apps onto your devices without a developer license period, as used to be the case, then that would be a different story and saddening to boot. However, as it stands, f.lux is the only app I know of that this has happened to and there is ample reason for it having happened.
Of course they're making a ton of money on the App Store as well, but I still think it's more about protecting the device. Otherwise they'd just approve every app and collect their commissions.
Some of us don't have an issue with this model.
I started coding on a Timex 2068.
So buying tools was the only legal option. Well, we could also type them from books and magazines.
Eventually I became a bit of FOSS zealot with the rise of GNU/Linux.
However, after a few years and head bumps, I came to realise that I care more about cool technology than being religious about FOSS.
I truly hope that OSX does not become the crippled/locked-down OS that iOS is. I know the new rootless feature is a warning sign, as is only allowing signed applications to run.
The hard part for us as developers is that we have to eat and pay bills, so all fleeing to Linux to write desktop software there won't pay our bills. The wide adoption of these Internet appliances (eg. iPad) means we railroaded into writing for them, or find another occupation.
Show me an alternative that allows me the same level of Just Works as an iPhone. Because Android ain't it. I don't need a reason to spend hours every week having to tweak, poke at, marshal and police the various apps on my phone to make sure normal behavior isn't messing something up. I put up with that for 4 years and never felt like I had a digital partner in my pocket. It was always a consciously present "thing" I had to be wary of eating a battery, crashing a workflow, failing to connect to something or transfer something or save something.
I love the linux "always be tinkering" idea but I don't need that to be something I spend part of my decision points on each day.
So if Google tightens up implementations of Android to a point where I can trust a device to get out of my way like I can this most recent iPhone, I'm all for giving it another go. But my money's not on that at the moment.
Maybe you just had a bad device?
But the work-supplied iPhone 4 and my now personal iPhone 6S haven't been issues. Never have to worry about batteries, don't hang, etc. etc.
If you don't want someone overzealously protecting you, then don't get an iPhone. If you don't want all your data sent to a server, then don't get an android or windows device. No one is ever forced to use an iPhone personally, and the flux devs knew they were breaking a set of rules which is why they were using the approach they were.
No rose coloured glasses here, I just don't get worked up over things I could have seen coming a mile away.
Apple enforcing its rules by forcing somebody to take down content hosted on a web page, content which does not infringe any copyrights or trademarks or other IP, is stepping out of bounds, in my opinion. There are a lot of things I dislike about Apple, but this crosses a line for me.
Sorry.
And the only solution is to throw out every piece of electronics I own. That's not happening.
We need laws. Some day, perhaps. Too bad the TPP didn't include EU countries (I know), maybe there would have been ONE benefit.
You think the TPP including the EU would have led to better privacy protections? To it seems obvious that the point of addressing privacy in the TPP would have been watering down the EU's existing protections, not trying to increase the privacy protections available anywhere else.
So does Google. All Nexus devices allows you to do "fastboot boot kernel.img".
Other devices with unlocked bootloaders supports/supported this too (like my old HTC One M7), using the same standard Android tools.
You realize that darkly tinted rose colored glasses would actually work better than f.lux?
(I know because I have a narrowband 470nm filter and I've looked at screens under f.lux, and there is often significant blue light coming out of very red looking screens. It doesn't take much to suppress melatonin secretion, especially with prolonged exposure.)
There's an opportunity for Apple -- just include backlighting specially designed for nighttime with no blue light. Switch it at night. That would have been Jobs' approach to the problem.
Using undocumented APIs has ALWAYS resulted in getting kicked out. They violated the letter and spirit of the program.
I'm sorry Apple doesn't expose the APIs they need, but this is cut and dry.
I wouldn't be so sure about that: http://daringfireball.net/2008/11/google_mobile_uses_private...
Surely you're joking.
History shows the average member of the population is not so skilled at discerning such signals correctly.
I think Apple offers a deal that has it's good and bad points and you are free to buy from many competitors. And yet, dozens of times per year on HN, we're told that Apple is essentially executing William Wallace and freedom itself for routine decisions that seem entirely consistent with it's longstanding policies on private API's, sideloading, end runs around enterprise deployment, etc.
> We're heading for a world where advanced users might not be allowed to interact with their devices because They (et al.) Know Best.
Presumably if this is vital and important to advanced users they can choose a device that allows them to do this.
> Protecting knowledgeable users from running arbitrary code is generally a pretty solved problem.
In strawmanville, every problem is 'generally pretty much solved'. 'Just let knowledgable users do it' is non-serious imho; anything 'knowledgable users' can do without a lot of effort/money you should assume anyone can and will do it. Jailbreaking has sometimes been associated with 'advanced users', unless you were in China and the guy who sold you the phone did it for you.
Brand loyalty is a reasonable thing.
Look, most software for most people since the dawn of the personal computer era has been about begging, cajoling, threatening, and screaming at your vendor to support your pet feature.
Apple has succeeded in part because it by and large does listen to its customers, it just usually takes far too long to do it the "Apple way" ... but not so long that one wants to switch platforms.
In this case, I filed feedback with Apple (which does get read), asking for f.lux support on iOS and/or documented APIs they can use. I'll also file this away in my "reasons Apple sucks" list. This list tends to grow and shrink over time, which means I have some faith in being patient. With Microsoft in the 90s it just grew unbounded until Windows 2000 was released.
The open source world of course allows me to tweak whatever I want, and I did own an Android Samsung GS3 once, but couldn't really stand it. The Linux desktop (ran one from 1994 - 2001) doesn't suck but it makes my eyes bleed: not my thing once I switched to OS X.
Side-loading pre-built binaries like that is a huge risk for users and never had a chance of being tolerated by Apple. Such abuse puts the new free-tier Xcode dev program in jeopardy.
Or it would force Apple to adapt similar to how they responded to the black market for developer program spots to access iOS betas by making a public beta program.
This is what they should have done. Instead, they chose to distribute a binary of their proprietary (patent pending [0]), closed source [1] product.
Not only am I not surprised that Apple shut them down the very next day, but I'm also having trouble feeling any sympathy for their cause.
[0] https://justgetflux.com/ - bottom of page
Commercial software is unlikely to be a trojan. You have much higher value as a paying customer than as a victim.
Open source software is similarly unlikely to be a trojan, especially if compiled from source.
Closed-source freeware is the perfect attack vector. Opaque and widely disseminated. Who knows what's going on inside? Freeware is responsible for a gigantic amount of malware.
There are no zero-risk activities, only risk signals. Some people choose to trust a corporation with lawyers and endless pages of EULA, some people choose to trust one authenticated developer with a proven track record of service to the community. At the moment, we are still free to make our own informed choices.
Open source is fine. If f.lux published the source code, then we could compile it ourselves, and Apple would be happy (they recently made the iOS Dev Program free of charge to allow sideloading in this manner.)
If iOS's app sandbox is inadequate, then those are all threats too, but Apple doesn't seem to mind them. If the sandbox is adequate, then apps like f.lux are safe even if intended to be malicious.
Apple's position is only really understandable if they don't understand their own technology. Which considering who is probably making these decisions could very well be true.
Apple does the same with their own products.
sending binaries you have to sign yourself.. I doubt that somewhat, they'll be signed by Apple.
For FOSS they use: http://www.opensource.apple.com
Not seeing anything about patents at that link.
And also, what in the world does "Proprietary, with free download. (with patent claim)" mean??
I remember this coming up on tech news sites a few years ago when I discovered f.lux... this article also makes mention of the patent-pending nature of the software: http://readwrite.com/2013/09/23/flux-a-hack-for-your-devices...
Seriously, this thread is making Stallman look like a reasonable majority candidate for president. It seems all it took for people to forget what caused PCs to blossom is a little bit of gold coating.
Windows makes you sign binaries with your own certificate before running them to bypass the signed code protection?
Considering how many viruses, lost work, malware and hair-tearing that model has induced, it makes sense to go beyond it, doesn't it?
If you don't have root, you don't really own the device.
But you are right: no-one has properly owned their own devices since the 80s because no-one can verify them using primary sources.
But yes, if you want to completely trust your hardware you're probably going to be using an old Thinkpad X200 with coreboot - shame about that Intel Microcode though, eh?
Modern devices are basically converging toward being enhanced VT100 terminals connected to some multitenant mainframe somewhere (a.k.a. a "cloud.") Whether that's Apple's cloud, Google's cloud, Microsoft's cloud, Canonical's cloud, etc. You could get the same effect (if a little slower) by just having the device be a dumb framebuffer connected to a VM running in said cloud.
If I've paid the full retail price for a device (often more, I'm in Australia), I expect to own, not rent a device.
Hell, my municipal (bargain-basement) phone provider here in Canada gives me ~4000ms latency at the best of times. On the other hand, my city is saturated in "free for users of my ISP" wi-fi hotspots that my phone can automatically jump onto.
It seems like the latter are going to be the true solution to low-latency mobile connectivity for most of the more "spread out" countries that can't afford to saturate the country in cell towers.
I don't know about you but I want my sysadmin to work for me so that when I tell it to shut up and get out of my way, it does exactly that.
[1] https://www.chromium.org/chromium-os/poking-around-your-chro... [2] https://github.com/dnschneid/crouton [3] https://www.chromium.org/chromium-os/developer-guide
I do actually disagree there! And this is perhaps the fundamental disagreement we have. I want my sysadmin to be a capital-E Engineer and choose their ethics over my desires. Don't let me (the capitalist) tweak the bridge I'm paying for into one that falls down; and similarly, don't let me tweak the computer I'm paying for into one that gets malware, joins a botnet and DDoSes people.
You pay your Engineers, basically, to provide you the service of "knowing what's best for you"; to be your domain-specific nanny, making sure you don't do something you'll regret out of ignorance.
And what if it's THEIR ignorance (e.g. of market opportunities) that prevents them from doing what you asked them to?
It's not like all sysadmin issues can be judged by pure technical reasons, without business needs taken into account.
You want engineers/sysadmins you discuss with you, warn you when you propose something they think is bad, but ultimately work FOR you, and do what you tell them to. They should never override you to make you "you don't do something you'll regret out of ignorance". It's your company after all.
And current Windows is quite safe. A few safe coding lessons will do wonders for a company :)
No it is not. You can do that on every single computing device out there - except those from Apple. There is some risk if you are stupid about it, but not huge right. A warning screen would be enough.
> never had a chance of being tolerated by Apple
It's my device, not Apple's. (Well, I would never actually buy an Apple device because of this, but those who do buy them should have the right to install whatever they link.)
Except when a device gets highjacked or something by a malware or whatever then user always blames the manufacturer of the OS, I guess apple knowing this just have a strict policies about it. Apple has a right to decide how to build and maintain their OS, they are the ones who created it, not device owners. If device owners don't like something about it, they have an option not to purchase it, Apple does not have an option to not sell a phone to some dumb user who will install viruses and then complain about Apple lack of security
In other words, a bad swimmer blames the producer of the bathing drawers for his bad swimming skills. I understand.
On the other hand, a bad swimmer might be pretty upset with the creators of his or her boat, if hypothetically the goal is to stay out of the water.
It's just possible that it depends on what you expect from the device when you buy it.
Separately: The DMCA needs to be dismantled, absolutely.
Let's face it: These people (rightly) buy Android and Nexus devices.
If you protect the naive from the consequence of their actions forever, then you end up with a world where those who are not naive cannot do anything because of all the 'safety' that they have to fight through first.
I'd also, on an ideological note, be inclined to be cautious about separating the consumers and the producers any more than they already are. One of the big promises of computers is that you can automate so much - granted a lot of people are cut off from that power - and I'd want to be going in the direction of making that power more accessible to people rather than less. If I'd had to, for example, buy a specialised programming computer with a programming OS when I was young... I'd probably not be a programmer today. That sort of thing seems like it would be very expensive.
But you may very well turn out to be right - maybe most people can't be allowed to have nice things. :/ Depressing, if true, but not entirely implausible.
Sadly, Apple seems to have given up on this and is now catering exclusively to the lowest common denominator. There's plenty of power left in their stuff, but it's all left over from better days, and is slowly slipping away.
I also don't understand your counterfactual. Apple didn't build OS X from scratch, they took NeXT's OS and ported it to Mac hardware and tweaked it. The result was something both powerful and easy to use. Making UNIX easy to use is not a trivial accomplishment! Yes, if Apple had done something completely different for their next-generation OS then maybe they would have ended up with something worse. But they didn't.
I suppose when I need real control I would look to, say, OpenBSD instead, which I prefer to use remotely from a very pleasant and very predictable - but not super-powerful - Apple machine. Our needs, I'm sure, are not the same.
I also like being able to get a terminal window to fiddle with the guts when I want it. Some tasks are better suited for that interface, and some powerful tools are only available there.
During those better days, Apple fully embraced the UNIX nature of their OS, without compromising the usability of their GUI layer. They got Mac OS X certified by The Open Group. They started opensource.apple.com and distributed enough of the OS's guts that you could actually get a full Darwin OS up and running entirely from source, even if the result wasn't super useful. They gave out a full suite of developer tools free of charge that you could use to build powerful apps for the system, and were in fact the exact same tools that Apple used.
Then iOS came. No more open source, except the absolute bare minimum they're required to distribute for open source licenses. (Their open source archive for iOS 9.0 contains a whole six packages, of which five are various parts of WebKit.) No more visibility into anything. Everything runs in a sandbox that you can't bypass by any means except finding a security vulnerability. The developer tools are still free, but if you want to actually use them to ship anything, or even run anything on real hardware locally, you have to pay and agree to their terms. (The "run anything on real hardware locally" bit has changed with Xcode 7, which is what f.lux was briefly taking advantage of, but this is new as of just a couple of months ago.) Apple suddenly wants to play gatekeeper to everything; if you want to ship apps to your customers, you have to first let Apple review and approve it, and they'll reject you if you don't follow their rules.
The Mac retains much of what was great about it before, but it's slowly drifting the same way.
The way I look at it is that Apple's gatekeeper role is appropriately minimal on OS X and appropriately strict on iOS, and for my part I trust the twain will never meet because of exactly that "general purpose computer" difference, but you have added some thought-provoking perspective.
1. Obtain Xcode, either as a free download, or from your OS install media. (Apple just shipped Xcode along with the OS for a while.)
2. Develop your app.
3. Distribute your app directly to customers.
With iOS, the process for shipping an app looks like:
1. Obtain Xcode as a free download.
2. Start developing app.
3. Realize you need to test on real hardware at some point. Before Xcode 7, testing on real hardware, even your own, cost $99/year. With Xcode 7 you can do it for free, as long as you get an account and have Xcode fetch the certificates for you.
4. Submit your app to Apple for distribution on the store. If you did step 3 without paying, then you need to pay your $99/year here.
5. Wait a week or so for Apple to review your app. With luck, they'll approve it. If they find something they don't like, they'll reject it and you get to go back and repeat this process until you appease them.
With the Mac today, you have a few choices. You can go through the App Store, where the process looks much like the iOS process, except you don't have to jump through any hoops to test on your own hardware. You can go through Developer ID, where the process looks like the old Mac way, except you pay $99/year to have a signing certificate. Or you can keep doing things the old way, at no cost, but most of your users will get scary, scary warnings when they try to run your software.
The thing is that it's not about the tools being paid, but the distribution being paid and restricted. I can completely understand paying for developer tools. Until they went crazy, I was happy to pay JetBrains for some of their tools, for example. Your Windows tools required payment to use them for real work, and that's fine. But if you didn't want to, you could have used mingw or something like that, and done everything for free and without restrictions. This option is simply not available on iOS, and is being slowly ratcheted down on the Mac.
Thing is, if I believed the Mac was going to be ratcheted down to iOS levels of paternalistic control, I would be upset too. My conclusion is it'll never happen. I don't think they'll ever break their general purpose computer. If they did, you'd see a massive exodus of former Mac users looking for a new UNIX desktop. Maybe a big enough exodus to finally make The Year of the UNIX desktop happen. :)
The problem is this: what part of the process I described has anything to do with security? As far as I can tell, nothing. Apple's review process is pretty superficial and is entirely geared towards stuff like making sure nobody ships a browser that doesn't use WebKit, or an app that posts information about drone strikes. Getting something malicious past the gatekeepers is completely trivial. It's building the malicious stuff in the first place that's the hard part.
It sucks, but desktop OSs technically have a similar right. While I have f.lux now on my phone, I'm happy.
I understand the challenges in the way the policies are set up, but again, this is a health issue that needs to be addressed one way or another.
That's quite an odd thing to say, isn't it? You're basically endorsing the idea that you shouldn't be allowed to run binary code of your choice on your own computer.
It's interesting to imagine the outrage if this policy was enforced by literally any other company on literally any other device or platform.
> and never had a chance of being tolerated by Apple
That's probably true.
> Such abuse
Can we perhaps find a term other than "abuse"? It seems quite inappropriate in this context. Spamming is abuse. Running non-Apple approved code on your own person device is basically the opposite of abuse.
Quite a few people have been saying for a very long time that distributing proprietary software without users being able to see the source is a Bad Thing. It's not your freedom they object to, they feel they are actually championing your freedom.
You or I may pragmatically decide to embrace opaque proprietary software, but certainly there is a reasonable school of thought opposed to the notion. It's much like arguing that we should be free to buy food that doesn't list the ingredients on the side, and drugs that aren't tested.
There're reasonable arguments to be made on both sides of that issue.
1. Whether users should be able to run any software (binary or not, proprietary or not) which they happen to have access to, on hardware that they own
and
2. Whether it is right for people to distribute, to users, software which is useful for a purpose, and therefore attractive, but where the users cannot change or even inspect the software itself (and cannot hire anyone else to do these things for them).
The issue at hand was the first one, and you answered by talking about the second one.
I believe the usual Free Software Movement arguments go like this:
For the first question, it is obvious that users should have a right to use the things they own however they wish – otherwise it can hardly be called ownership. For the manufacturer to give such restricted hardware in exchange for money, but still retain this degree of control over the hardware after the transaction, should therefore not be allowed to be referred to as “selling”, since the recipients/possessors of such hardware cannot usefully be considered the full “owners”.
For the second question, while it is obvious that it is unethical to tempt users to give up their freedom to change and inspect the software, or have it changed or inspected (since this checking and tinkering is one of the things which drives a good society), it is certainly not obvious that it should be out-and-out illegal for anyone to offer such unchangeable and uninspectable software to users.
Lazare was talking about the first issue, and braythwayt responded as if the answer to the second issue was the answer to the first one, implicitly conflating the two issues.
If you give humans the right to buy anything they want, sooner or later someone will make a health drink containing Radium.
https://en.wikipedia.org/wiki/Radithor
At that point, you either go full Libtard and say, "we're all adults here, caveat emptor" or you regulate the marketplace and make it illegal for people to do business in Radium drinks.
I'm not saying anyone should be prohibited from buying/leasing/licensing proprietary, opaque software. But I do think there are reasonable arguments for such.
So what I would say back to you is "Do not conflate saying there are reasonable arguments for X with saying X should be the case."
That's a completely separate issue. Apple cares not a jot whether you can see the source; they care that someone was distributing iOS apps outside the garden.
It's that how many viruses and pieces of malware get around? The user is tricked into installing something and then it goes bad?
Isn't that how most every exploit and virus seen on Android work?
Is that how the problem apps found in the jailbreak app stores for the iPhone work?
Isn't this exact restriction why the worst we've seen on iOS (despite MASSIVE deployment numbers) is social engineering attacks?
I know many people hate the restrictions, but the App Store on iOS has a pretty amazing track record for security (in regard to problem code). Basically the worst we've seen is apps abusing system APIs to get more information than they should and those have been closed relatively fast. No worms, no viruses.
Obviously if you prevented people from running non-Microsoft approved binary code on Windows, we'd see a staggering reduction in the amount of malware activity. Is that something you'd endorse?
I wrote that as a counter to the 'Windows / OS X does it without issue' line of argument. There are issues. They may be relatively minor (OS X) or very bad (Windows XP), but there is no free lunch.
Actually, no. Stagefright was about exploiting holes in the parsing of malformed media files (no installation required). Tons of other vulnerabilities were of the form "thing that shouldn't be accessible via JavaScript in the browser/WebView is".
Not that there isn't malware that spreads via installation, but Google's "Verify Apps" service (for sideloaded apps) has been quite effective:
http://googleonlinesecurity.blogspot.com/2015/04/android-sec...
If you're worried about malware, sideloaded apps still run in the same sandbox that app store apps run in. Apple's review process does not meaningfully impact security, so the sandbox is all that stands between you and malware either way.
Like private APIs that can screw with color output, outside of the app. And so on. The security comes from
1. Defining a set of APIs that you're allowed to use
2. Ensuring that you only use those APIs
Sideloading apps skips that important security check.
If a given private API is a security problem (and I agree that altering the screen's gamma settings system-wide may well qualify) then that private API needs to be actually secured, by taking it out of process and gating it on a sandbox entitlement.
The private API check is done to allow Apple the flexibility to change those APIs without potentially breaking a ton of apps and pissing off their users. It does nothing whatsoever for security, unless your threat model is programmers capable of writing malware but incapable of obfuscating function calls.
Developing for Cydia is a violation of the developer agreement as well, that doesn't seem to stop them. Honestly, I don't get it. It's extremely disappointing, as the app works great but needs some fine tuning. Which we will now never see because they capitulated that they were violating an agreement they were never party to in the first place.
The only way this threat holds any water is if there is a revenue stream or published application they are at risk of having removed. As far as I can tell, they have no such issue.
If saurik suddenly decided that developing Cydia was harming his relationship with Apple and pulled it, I would be disappointed in him, not Apple.
It's their game, their rules. We all know the consequences of performing an end run around those rules, as developers of arguably one of the most famous jailbreak tweaks ever, they should know.
All of this was obviously going to happen from the get go. The only odd part was when they caved because Apple sent them a sternly worded letter.
That's not a terrible idea... Are there any cellphone cases on the market that would make swapping out such a piece of plastic sufficiently straightforward?
I know it's neither as convenient nor as easy to use as a case mod or f.lux, but it's worth a shot.
Also the effect appears gradually.
This is an end-run around Apple's policies, just like jailbreaking. Apple doesn't like it, just like jailbreaking. The only hard to understand or confusing part is where the f.lux developers deicde they suddenly care enough about what Apple does or doesn't like to pull their app.
Some states also recognize causes of action for interference with prospective relationships, although these are notoriously hard to prove.
There are non-root apps that use an overlay instead, which can sorta help but it's not an optimal solution.
https://play.google.com/store/apps/details?id=com.vito.lux&h...
I don't know which license matches this so I'm going to write it out. You can do what you want with the code, but do not distribute compiled copies of the app, especially on mass download sites.
I mean, it's not quite BSD, but it's hardly 'all rights reserved'.
// Created by Thomas Finch on 6/22/15.
// Copyright (c) 2015 Thomas Finch. All rights reserved.(Though it looks like this project doesn't have a standard license)
In OS X you can use CoreImage to filter a view, but that has always been excluded from iOS.
The platform perception management kicks in, they can't let all the cool kids install a filter on top of all the rendering then complain that iPad and iPhone battery life sucks.
In my own Sudoku program I automatically manage the screen white point by sensing the backlight level (I'm not allowed to use the ambient light sensor, so I watch something that watches it.) but I have to do it by changing all of my colors everywhere I draw. It's not a big deal and works beautifully, until you finish a puzzle and the pure iOS alert comes up in full white and burns a hole straight through your drowsy dark adapted retinas. Then you have to go to sleep because you have a huge afterimage floating around in the center of your vision.
Honestly, I'm surprised more people aren't responding "Wait, why _isn't_ this possible in iOS? Windows has had the necessary tools to do this for years."
Not enough people care. On the grand scale the number is tiny. I'd imagine that's because so few people have heard of this. As you said Windows has had it for a very long time but the vast VAST majority of people dnot use it, it's still niche.
When enough people want some (say user swappable keyboards, or Notification Center) Apple adds it once they have a good design.
These guys blatantly violated the TOS. There should be no surprise here. If anything what they did was basically a stunt.
> I have talked with startup founders time and time again they tell me their iOS apps are more barebones because Apple's policies or permissions prevent them from implementing the same features they can implement on Android
Apple implements things at the pace they want. That's one of the reasons things in iOS are generally well thought out and it's so hard for a rogue app to destroy battery life or violate your privacy.
Apple chose the trade offs they want to make, andnit seems to be working very well for them.
I found a mirror on GitHub, but I haven't verified it: https://github.com/jefferyleo/f.lux
I think I did this right. I ran `shasum -a 256` on the zip, but let me know if it doesn't look quite right.
This sounds entirely wrong to me. Checksums are used all the time to verify the integrity of archives.
find . |xargs shasum -a 256
And then posted the output, that would be helpful to people that want to verify these files.
38f463ee5780a4f2b0160f9fa21dbe3c78c5d80d3c093e4ff553aaca230e2898
So it looks like the GitHub version matches the original.
$ cd f.lux-master/
$ shasum -a 256 iflux | grep 10428983a681b07f687511e150f46e39b6f9da506316a8041742a78bc0ce9ef6
10428983a681b07f687511e150f46e39b6f9da506316a8041742a78bc0ce9ef6 ifluxhttps://justgetflux.com/forum/topic/1267/sha-1-for-ios-sidel...
I downloaded it this morning, very excited to try it as I can't stand the blue glow of my phone after dark.
You don't have to be in the Apple developer program to post an Xcode project on a web site. Nor to download Xcode, since it comes free from the Mac App Store.
Applications developed under this Agreement for iOS Products, Apple Watch, or Apple TV can be distributed in four ways: (1) through the App Store, if selected by Apple, (2) through the B2B Program area of the App Store, if selected by Apple, (3) on a limited basis for use on Registered Devices (as defined below), and (4) for beta testing through TestFlight.
You can only allow third parties to install your app on their devices for testing if you have written approval from Apple.
You can only use a limited number of devices that you/your company own for testing.
Your license to use Xcode, the SDKs, and release software for iOS can be revoked at any time: "Apple reserves the right to revoke, disable or suspend any Provisioning Profiles or any access to the device deployment and provisioning features of the Apple Software and Services at any time, in its sole discretion. By way of example, Apple may do this if Apple has reason to believe that Apple IDs were fraudulently obtained, that an unreasonable number of devices have been entered into the Apple Software, and/or that the Services are being used in a fraudulent, suspicious, or improper manner."
That you're supposed to agree to. What proportion of the users of Xcode do you suppose have even read that license?
Also the license doesn't prevent you using it, though it possibly prevents you from legally using it for commercial purposes in most developed nations.
With the recent case concerning sending data abroad to process to circumvent patent restrictions it seems that f.lux could just have someone in a country with no copyright/license restrictions download Xcode, compile and make available the software. Apple Computers after all wouldn't own code created with Xcode, which would be a technical rather than artistic work anyhow, so there doesn't appear to be a problem of copyright.
Apple could likely still pull strings that the f.lux people wouldn't find helpful however (maybe the devs have other apps that Apple could block, for example).
A license can restrict non-commercial purposes, too (as long as they aren't purposes protected by law, e.g. fair use). While it is true that most companies only go after license violators who are using the software for commercial purposes, that is only for practical reasons, not legal.
I'd say "are bound by the license" - however if you download Xcode from the app store do you get "adequate notice" of the browse-wrap license?
Can't personally inspect the license from https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewEula?... as it redirects saying one needs the Mac App Store to do that.
A license can restrict use, but copyright concerns copying. They allow copying of the code, which is necessary for use, but attempt to acquire acquiescence to their license terms. I'm not sure however as there is no consideration how users can be considered to be under license. In short if the copying is fair-use, which it looks like it reasonably could be, then how can the use be controlled?
I realize f.lux was distributing a compiled binary instead of telling people to compile it from source, but I think Apple would have sent them a C&D just the same if it were just source.
That said... What percentage of Apple's user base lives with disabilities? What percentage is visually impaired; what percentage has motor difficulties? These are clearly worthy, comparatively small populations of users that Apple devotes an otherwise-inordinate amount of development resources to. Maybe it's time Apple considers melanopsin sensitivity worthy of admitting to this circle.
repost from yesterday's thread
http://thenextweb.com/lifehacks/2014/04/23/7-things-can-righ..., "Blue light is able to pass through what is called the retinohypothalamic tract, or pathway. This pathway is responsible for regulating our circadian rhythm and a number of other biological and behavioral processes."
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2831986/, "Hastings and Sweeney’s paper, published in the December 1958 Biological Bulletin, gathered dust for decades. No one thought these findings might hold any relevance for humans, whose circadian rhythms were then widely believed to be relatively insensitive to light. But scientific discoveries in the past two decades have changed all that."
https://theconversation.com/a-dark-night-is-good-for-your-he..., "In the last decade or two it has become clear that the genes which control the endogenous circadian rhythm (the “clock genes”) also control a large part of our entire genome including genes for metabolism (how we process the food we eat), DNA damage response (how we are protected from toxic chemicals and radiation), and cell cycle regulation and hormone production (how our cells and tissues grow)."
There is room lighting with low-blue content, e.g. the G.E. Align PM bulb, http://www.amazon.com/gp/product/B00PLR3M0M & https://gigaom.com/2014/09/01/what-is-the-blue-light-from-ou..., "It remains unclear whether our screens themselves will soon emit less blue light — Hansler is pessimistic because he says that changing the amount of blue light will be like admitting that the screens are causing health problems, and lawsuits could ensue."
A little hyperbolic there, no? I'm surprised to hear this is even a problem that exists.
> Based off of Thomas Finch's "GammaThingy"
> GoodNight is an app that allows you to directly access the screen's gamma levels, and modify it using IOMobileFramebuffer. With this you can do any of the following: Change the screen temperature, Put the brightness lower than iOS would normally allow you to, Adjust the RGB values of the framebuffer
> This application uses dlsym, which loads in the private symbols at runtime, rather than using headers, so no additional setup is needed once you download the source.
Just from a misremembered story I can't pull up from memory about Steve Jobs interactions with a music/audio software company in the earlier days of Apple.
https://www.panic.com/extras/audionstory/
If you're looking for 10-15 year old story where Apple famously ate someone's lunch then Sherlock/Watson and Konfabulator/Dashboard are some of the more prominent examples but those are fairly obvious directions for OS makers to fill.
>"We also seem to remember Jobs painted us a vibrant (but genuinely honest) picture of how he viewed Audion fairing against iTunes:
"It's like you guys are a little push-cart going down the railroad tracks, and we're a giant steam engine about to run you down."
That gave me the impression that stuck with me. Thanks for the sourced correction.
Surely Apple already has people who are smart enough to do this. They have some of the most color accurate screens in the world and worked really hard on that kind of thing there's no way they don't have people who would know how to do this.
f.lux isn't open source.
How to: http://lifehacker.com/toggle-your-iphones-brightness-with-a-...
It feels more likely that this is related to excitation of S cones -- which dimming the screen without changing the colour temperature would also accomplish, to a degree.
In other words, dimming the screen should be at least somewhat effective.
In Xcode 7, you can install apps directly to your iOS device with a free account from Apple. So we decided to make a beta version of f.lux for people to try. It’s a few more steps than installing the app store, but there are plenty of harder things even on Pinterest. So, here’s how to get f.lux installed on your iOS device. Download f.lux for iOS for use with Xcode 7 Ingredients Mac, OSX 10.10 or greater 1 installed version of Xcode 7 1 Developer account (use your AppleID) 1 Download, f.lux for iOS, unzipped Instructions First, mix the build ingredients together. Batter may be slightly lumpy. Open the “iflux.xcodeproj” project in Xcode Open Xcode > Preferences > Accounts and enter your iCloud or developer credentials Under Targets > iflux > General > Identity, add a word to the end of the Bundle Identifier to make it a unique name In the same place, under Identity > Team, select your iCloud account or Developer profile While the batter chills, connect your iPhone or iPad and load the iflux build: From the Xcode Product menu, choose Destination and select your iOS device (f.lux doesn’t work in a Simulator) Push Cmd-R when you’re ready to have f.lux When you first run, you’ll be prompted to open Settings > General > Profile on your device, and trust your developer account Run again, and allow location and notifications (things don’t work so well without both of these) By loading an app this way, there are no automatic updates or bug fixes, so this version does a daily update check. If one is available, a message will appear at the bottom of the app, so you can stay up to date when we make fixes.
(instructions are still there if you scroll down, I guess they'll delete them imminently)
And on and on it goes.
My 2010 Macbook Pro heats up and has fan going off crazy, and my 2008 ThinkPad T400 is sitting next to the MBP, just chugging away like a champ.
If you are talking about user interface, I agree on that. But hardware wise, I am not that impressed. However, if you do run into hardware issues, AppleCare is excellent.
I will say that I wish Apple would either build f.lux type technology into the OS as part of the Accessibility settings, or just allow the f.lux developers to use the APIs they need. When I did have an Android phone it was a welcome tweak that made it easier to read on my phone before bed.
There was a time when I wouldn't touch an iPhone with a ten foot pole after using the original and a 4S, but with the 6 and iOS 8/9 Apple has finally made a phone that surpasses Android and Windows on the balance of stability and function.
There are a lot of compelling and expedient reasons why iOS is the way it is. Apple isn't the only player on the market, and they aren't misleading or a monopolist like IBM was in the 80s or Microsoft in the 90s.
As for why can't you do on iOS what you can do on your Mac... Apple doesn't want the types of problems that android has.
Apple, on the other hand, consistently treats developers on its platform with nothing but disdain.
Users benefit from a secure system, mostly safe applications and consistent UI.
The consequence of Microsoft's fuck-the-user, go developer philosophy has been over a decade a pain for the users. That's why Dell and HP are giving away PCs under cost while giving up share, while Apple is growing and making a killing.
> Developer learns iOS > Developer uses private APIs (which is neither easy, or allowed per the terms they agreed to) > Developer sends in app for approval, is rejected for above because duh > Developer whines on the Internet and gets a bunch of people angry at Apple, who likely will not change.
You know I feel the need to point out that Apple doesn't lock us out of code to be mean, they do it because it ensures their devices don't suck, because we as developers do not have access to the system level things that can make them suck.
Here's what actually happened.
Developer develops a tweak requiring a jailbreak. It becomes one of the most popular jailbreak tweaks available. Five years pass, Apple inadvertently allows sideloading by giving anyone who wants one a dev certificate. Developers utilize this to create a version of their tweak that can live inside the sandbox & can be signed by end users, but still utilizes private APIs.
They develop this and release it, knowing full well that they're doing an end-run around Apple's policies, very similar to requiring a jailbreak. They did not develop it expecting it to be approved. I have no clue where you got that from.
The only confusing part is when they caved because Apple complained, knowing full well they would complain at some point.