Hacker News new | comments | show | ask | jobs | submit login
f.lux for iOS is no longer available (justgetflux.com)
616 points by kilian on Nov 12, 2015 | hide | past | web | favorite | 400 comments



Author of f.lux here:

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.

[1] https://news.ycombinator.com/item?id=10552070


> When Apple calls up and says they don't want that to happen

"Please stop doing whatever you want with your device, we like to determine what you can do." Ok, bye.


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.


Wait! What do you mean "breaks" w.r.t. f.lux?

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?


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...


so by the same logic, iOS should only be available in one language and should not allow deletion of any data, ever?


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.


> I don't see why he didn't just pay the 99 USD and distribute it via the app store

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.


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*

(* See https://ifixit.org/blog/7401/ifixit-app-pulled/ )


Flux uses private API, it will not be allowed on the App Store.


> "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.

1: http://www.cio.com/article/2938766/privacy/how-apples-privac...


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'm not particularly surprised. Actually, I would have been surprised if these restrictions weren't in place. But I figured it was worth looking into.


> Where has Apple ever indicated that the new Xcode signing was intended for your use-case?

Apple never officially explained the decision, but from what I've heard it was to encourage Swift adoption.


That's what I was wondering, too.

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.


Inviting the wrath of Apple's legal team is definitely not a winning strategy ...


It seems a little strange that one should have to worry about such things while not doing anything wrong.


Isn't violating the spirit or actual terms of a license "doing something wrong?"


Are they? As far as I know they're just releasing the source with setup instructions.


Sometimes licenses (contracts) over reach or contain elements that should be removed or ignored. See contract of adhesion and unconscionability.


> This doesn't seem to be a winning strategy with Apple

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


Yes it is. There is nothing impolite about that whatsoever.


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)?


You can use [redshift](https://github.com/jonls/redshift) - it's like f.lux, except it respects your freedom.


Why not just start work on an android version?


From the FAQ [1]:

    > 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.

[1] https://justgetflux.com/faq.html


On Android we already have dimming/warming apps like Twilight. Why is f.lux any more complicated?


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.

[1] https://play.google.com/store/apps/details?id=eu.chainfire.l...


Also that one: https://play.google.com/store/apps/details?id=mobi.pruss.Gal...

And Cyanogenmod has a built-in color temperature changer anyway.


> 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 believe if Lux has root access it changes its behaviour to also change the actual color temp rather than using an overlay.


It does if you install either a plugin specific to your device, or a plugin to use CF Lumen as its backend.


For reference, the most popular screen dimming/warming apps for Android:

- 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 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.


Twilight doesn't properly dim the whole screen, it leave the menu bar undimmed and is good but not great.


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?


I use 'Bluelight Filter' on my Nexus 7. It's.. somehow 'different' to CM's solution (which I have on a Wileyfox Swift) but seems fine.

I think you can pay to remove the spammy ads, but it's otherwise free.


There's already an Android version called Twilight and it's awesome.


Apparently that doesn't work. On current androids, you can't have proper "f.lux" without root.


Thank you for all of your hard work! I have used flux for years now and it's only when I don't have it that I realize how damn well it works.


So what does F.lux do differently to the FOSS solution Redshift?

https://github.com/jonls/redshift


Redshift was inspired by F.lux. I actually use Redshift since F.lux is not available in linux, but Redshift has no mobile versions.


>since F.lux is not available in linux

I've run it on my Ubuntu install for quite a while, at least a year I think? Am I missing something?

https://justgetflux.com/linux.html


strange! i was convinced that I started using redshift due to f.lux's inavailability... my bad!


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.


Weird. I distinctly remember installing and using it on my Linux boxes. https://justgetflux.com/linux.html


>> The demand for f.lux is certainly incredible.

I'll say! Is it really hundreds of thousands of people? That's fantastic.


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


Have you considered open-sourcing your project?


Never used Xcode and it was simple to side load onto my iPhone.

It's a great app, keep pushing and apple will see sense.


I usually don't get annoyed at fans wearing rose-tinted glasses (aka fanboyism), but I feel that people sticking up for Apple here is some variant of the Stockholm syndrome. We're heading for a world where advanced users might not be allowed to interact with their devices because They (et al.) Know Best. Protecting knowledgeable users from running arbitrary code is generally a pretty solved problem. There are layers of trust in the system, and human connections that keep the system alive. This delegation of critical thinking to Apple is an unfortunate path.

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


This is literally the capstone of iOS. You have no power, or privlidge. You work in the languages the master wants, using the tools the master has you buy, using the APIs the master blesses you with.

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.


I think years later people are going to look back and say we had it pretty good with Windows/Linux/*BSD and x86.

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.


You're right. Growing up with PCs I took for granted the fact I could download any OS and install it easily. It's so incredibly different to the closed off world of tablets and phones, where getting any non-OEM code to run is a huge undertaking. A few years ago this seemed OK, because the phones and tablets were low powered utilities. Today they're rapidly becoming our PCs and so we're quickly moving towards a world in which our primary PCs are completely closed devices.

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.


> I think years later people are going to look back and say we had it pretty good with Windows/Linux/*BSD and x86.

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.


It wasn't just x86, it was the fact that IBM released the entire documentation for the PC architecture up to the AT, including the BIOS source code (which was copyrighted, so competitors could not just copy it, but they could certainly study its function and produce a different but compatible implementation.)

For the PC, things started taking a turn for the worse with EFI and SecureBoot, but before that it was quite open.


Yes of course x86 implies the BIOS and the historically very significant reverse engineering of it by Compaq.

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.


"I think years later people are going to look back and say we had it pretty good with Windows/Linux/*BSD and x86."

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.


What people don't get about Microsoft is however bad they were, they practically enabled a hugely diverse and mostly open hardware and software ecosystem and they had to standardize and open up in order to keep it going. Sure they had their monopolistic ways but fortunately they were reigned in for the better.

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.


Right, so dictatorship is pretty good when the experience is ok.


The only way to get apps on the original iPhone was to hack your iPhone. It was only through the incredible demand that users wanted to do this that Apple actually released a store for applications. I'm continually surprised at people that are surprised when Apple does stuff like this.

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.


I doubt it. A few million downloads is still a drop in the bucket and such software has been available for OS X forever and they haven't cared to integrate it.


There's a tonne of stuff available for OS X forever that they haven't cared to integrate though. Not true of iOS, mobile is somehow different, and as above - it started off completely closed to third-parties!


And that has saved them from a ton of complexity and security issues. Users (by and large, HN is very skewed from normal) don't seem to mind at all.


Interesting perspective. I've always thought the lack of an appstore in 1.0 was just pragmatic. It definitely made it easier to launch the first version of iOS and cope with the very limited resources -- 128MB of ram!


At the time, Jobs was showing off how developers could create app-like experiences using HTML - with the ability for people to "install" your app using the add-to-home-screen feature. That was the intended solution for us plebs. Native apps were most likely going to be only for partner companies.

Ironically when people starting creating actual apps using HTML via PhoneGap and the like, Apple was resistant to that too!


Meh, Apple wants to control everything because they want a seamless, dead-simple device for non-techies. Because that's the majority of customers - not the power users who want to get down to the bare metal of their machine. They are tyrannical about protecting that experience and basically not allowing you to screw up your device no matter how hard you try.

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.


> The greatest irony is how many walked into this with open arms, and how many continue to praise this.

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.


Through several generations of Android I had problems with battery life. However I never had problems with apps like you describe. Since my Note 4 I cannot complain about battery life, and now that iPhone has taken on some Android features like multitasking, friends I know with older iPhones are having battery issues (including one with an iPhone 5 that just had the battery replaced). So it was a tradeoff of emerging features, where Android had included many more from the start (Apple is more careful/conservative) and they are at parity now.


My Android phone just works™. No tinkering required. It's not even rooted anymore. I don't have to think about it at all.

Maybe you just had a bad device?


3 bad devices from HTC and LG, I guess.

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.


My Galaxy S2 has a battery life of about 2 days and I haven't experienced any hangs for a long, long time.


Very true, and an interesting comment. It is interesting to see the other platforms attempting to model themselves after this (such as the Windows application store or whatever it is called), although you obviously have the power to install and run whatever you want there.

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.


I think I need to preface this by saying that I sideloaded f.lux using the original technique the moment it came out without hesitation and will not remove it from my phone now that it's not kosher.

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.


IANAL, but my understanding is that you can not distribute a copyleft software using Apple's app store. Therefore, all copylefted applications that are in Apple's store must be dually licensed.


That's true, but I was more referring to the fact that you can download and compile open source apps for sideloading similar to what f.lux wants you to do, but the advantage there is that they are open source and don't use undocumented APIs.


It is how many of us worked in industry before FOSS was a thing.

Some of us don't have an issue with this model.


It's also possible to have issues with the model but still participate. I've spent the last few years working on a .NET stack doing Android and iOS apps. I'd really prefer building on linux, but sometimes you make compromises because it's what the job requires.


Same applies to me.

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.


it's also one the greatest digital publishing platforms ever invented... sooooo sorry that every once in awhile they enforce some rules to keep it so. The alternative is Android. Which, if you ever tried to program for, is literally worse than going to the dentist.


Sorry, your comment is grandiose enough that I couldn't help but comment.

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.


> The alternative is Android. Which, if you ever tried to program for, is literally worse than going to the dentist.

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 wouldn't say you have no power or privilege. For their 30%, they are putting your device in a market that has the most affluent users of technology, in the world. There's a reason that they've been able to get away with what they're doing--they're giving consumers what they want. It's just that important things like this aren't decided by popularity, e.g. freedom. They're rights bestowed to us by our government. I'm not saying that what Apple is doing is right or wrong. I am saying that them doing it is a great loss of freedom for users and developers.


Rights are not bestowed upon us from our government -- they are natural and inalienable and a part of what makes us human.


While I'm a rabid defender of rights, I don't agree they are not bestowed upon us, nor that they are unable to be taken away. Ask anyone in prison or a wartorn or repressive country if they still have all of their human rights. They don't. Rights CAN be taken away, and routinely are. The question is do we fight to retake and retain them.


You misunderstand -- I'm not saying they can't be taken away. What I'm saying is that they cannot be /given/, /granted/, or /bestowed/ because governments don't make or own rights.

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.


You're making rights out to be something they aren't. Humans, outside of government, humans "in the wild" have exactly the rights an animal has: they're free. Free to be food for something bigger, or to defend themselves if they can. But that's about it. Rights are a human-made concept, and can only be given from one person to others.


So if rights are bestowed upon someone by another person, who bestowed those rights to the grantee? And who bestowed them to that person, and so on?


Now? Ideally we give the right to hand out rights, via voting. Originally? Whoever could take control by force, dolled out rights as they saw fit.


Can you back that idea up with historical fact? Or is that a guess?


It's a guess. Can you back up the idea that rights are anything other than a human-made concept, at all? That they're somehow intrinsic to the universe?


I don't have to as I didn't assert that.


Fair enough, so what's your answer to your question "So if rights are bestowed upon someone by another person, who bestowed those rights to the grantee? And who bestowed them to that person, and so on?" i.e., what's your core assertion about this subject?


I'm a Christian, so my belief is that God created us with a set of rights: the right to survive (food, clothing and shelter), the right to exist peacefully in creation and the right to live securely.

As humans, we routinely violate those rights.

You did ask :-)


I think it's just a terminology thing. Naturally our rights are inalienable, but we tend to rely on our governments to enforce this reality.


The terminology here is absolutely key, though. A government cannot imbue someone with "rights" -- only privileges.


For those who are interested, there is more information of the philosophy of natural/inalienable rights available on Wikipedia.

https://en.wikipedia.org/wiki/Natural_and_legal_rights


You only have rights as long as your government is willing to respect them. For this purpose, bestowing a right and not taking it away are exactly the same (and you acknowledge below that a government can "take away" rights).

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.


> rose-tinted glasses

In this case, the fans are literally not being allowed to wear their rose-tinted glasses...


LOL, up voting.


Down voted to -4. Really? Are you guys just completely lacking in humor or are you just angry at anyone who laughs because you were brought up with no appreciation for laughter? What is it with super fragile egos? It's not about you! Don't be so vain. Jesus.


Do you really think everyone who finds a post entertaining is compelled to reply with "LOL"? This place would be full of substanceless posts like that, you'd have to wade through them all to find any actual discussion. It's considered rude to post when you have nothing to say.


Considered by whom? yourself? others like you? the whole of humanity? Obviously, to many of us, emotion is not void of information, but to you it and others it may be.


I on the other hand love it. I use Linux, Windows and OSX on a daily basis. I use an iPhone and an Android tablet. Each device has its purpose, and levels of trust, and a kowegeable buyer knows the strenghts and weaknesses of each platform going in. If you're getting upset that Apple is enforcing its rules for what it views as a security concern, is silly in my opinion.

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.


What if I don't want somebody "protecting" me but I also don't want Google or Microsoft taking all my data?

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.


People bought Android instead of WebOS and killed the most open platform mobile has ever seen. Hell, you could boot a kernel over USB, and Palm gave you the tools and commands to do it. On their official website.


Google does the same with its Nexus devices[1] in that you can build a completely open-source version of Android except for certain hardware-specific binary blobs.

[1] https://source.android.com/source/running.html


So... You can build the complete OS... Except for all the hard driver parts.


The hard driver parts are for things like LTE, GPS, GSM, wifi, camera, etc. which the device manufacturers haven't chosen to open-source. I don't see how it's relevant to Android itself, any other OS would have the same problems with that hardware.


As does Google. Or has "fastboot boot" stopped working on Nexus (and many other bootloader-unlocked) devices?


> Hell, you could boot a kernel over USB, and Palm gave you the tools and commands to do it

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.


It's sad that what you're describing sounds scandalous today.


The market has basically failed your particular niche. Until enough people (or lawmakers) step up on privacy Apple is your best bet, all things considered.

Sorry.


I wouldn't say the market doesn't provide them; there are Ubuntu and FirefoxOS smartphones. It's just that a niche demand only gets a niche supply.


That's my conclusion as well. I use an iPhone but I'm not terribly happy with it. It may be the best choice, but that doesn't mean I can't complain about its many deficiencies, among which Apple's stupid "security" policies are some of the worst.


I'm pretty happy in Apple land, but the battle was lost years ago when it comes to the internet. Gmail tracks me. Facebook tracks me even though I'm not a member. YouTube tracks me because I use Gmail. Google tracks me because of Gmail. Everything tracks me.

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.


> 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.


I imagine you're right that that's how it would have gone. But at least someone would have been trying. The EU is still pretty pissed over Snowden.


Do a web search for TTIP.


I wonder what would have happened if the f.lux developers refused to take down the code, besides cancelling their developer account.


iOS does not send data to server?


I didn't say that, did I?


But I want f.lux on my iPhone :/


I usually don't get annoyed at fans wearing rose-tinted glasses

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.)


Probably the backlight leaking through?

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.


> Protecting knowledgeable users from running arbitrary code is generally a pretty solved problem.

Surely you're joking.


Have you ever used OS X? I have never had a problem caused by running binaries I've downloaded from the internet. I understand how to read signals of trust and using my brain to vet sources. Why should my phone or tablet be any different? It's a risk, sure, but even Apple's approval isn't foolproof!


The existence of things like MacKeeper seem to indicate otherwise.


>I understand how to read signals of trust and using my brain to vet sources.

History shows the average member of the population is not so skilled at discerning such signals correctly.


Perhaps "solved," as in "proven futile"? ;)


"I feel that people sticking up for Apple here is some variant of the Stockholm syndrome."

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.


Given the app involved would you say "Rose tinted screens"


f.lux cannot ship an iOS App using the Documented APIs, because the APIs we use are not there. In the last 5 years, we have had numerous conversations with Apple about our product and what would be required to make it work with iOS.

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.


ALWAYS?

I wouldn't be so sure about that: http://daringfireball.net/2008/11/google_mobile_uses_private...


> I feel that people sticking up for Apple here is some variant of the Stockholm syndrome

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.


This would be a lot more interesting if f.lux was actually distributing source code. Instead, they were just distributing a binary that you sign with your own dev cert.

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.


> Side-loading pre-built binaries like that is a huge risk for users

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.)


You can do it on non-iOS Apple devices, too.


> its my device, not apple's

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


> Except when a device gets highjacked or something by a malware or whatever then user always blames the manufacturer of the OS

In other words, a bad swimmer blames the producer of the bathing drawers for his bad swimming skills. I understand.


It would be ridiculous for a bad swimmer to blame the creator of his or her swimwear.

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.


Except that for many users, they would GREATLY PREFER to have the RIGHT to acknowledge the risks entailed, and use the device how THEY WANT TO USE IT. They purchased a physical device, and they deserve to be able to use it how they want. This is just another example of why the DMCA needs to be dismantled.


I've been spending some time trying to understand this today, and I don't understand why such users don't just go buy a device they can root and take full control that way. Why blame a vendor that doesn't ship what you want? Why not just... buy what you do want?

Separately: The DMCA needs to be dismantled, absolutely.


There's no good alternative, except maybe the MiPhone in China. Android is pretty horrible and saddled with all kinds of Google integration.


Well, I agree with you there (in general I mean, I don't know the miPhone). I would love to see a truly open source handheld computer. I've thought about picking up a Firefox OS phone. I just don't think it's Apple's job to create it. That's not what they do.


> Except that for many users, they would GREATLY PREFER to have the RIGHT to acknowledge the risks entailed, and use the device how THEY WANT TO USE IT.

Let's face it: These people (rightly) buy Android and Nexus devices.


I am not sure I follow how you arrive at the conclusion that "many users" would prefer this. What platform are those users on? It appears that many users (certainly a financially measurable majority) have indicated their preferences already.


No bad swimmer will blame a coach who did not control his swimming and let him drawn. That's the logic behind no tech skilled users. Remember how everybody was blaming apple for celebrities photos leaked, they did not blame stupid celebrities for having the same easy password for all their online accounts...


Some of those people think nothing of hiring physical security costing five or even six figures every year. They didn't also consider hiring someone to spend an hour a month administering their personal devices? I notice that I am confused...


Let me have a switch and require me to do some trivial but scary sounding procedure to enable the functionality so that idiots don't run across it - flash the firmware or something. Void the warranty when I do so to discourage the cautious, with appropriate warning labels to go back before doing so.

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.


The naive outnumber the skilled by so very many... perhaps the skilled need different devices and different operating systems?


This used to be Apple's key offering. They sold systems which were suitable for the skilled and the naive alike. It was wonderful because it meant that the naive could smoothly transition to being skilled, and the skilled could have all the comforts and ease of something suitable for the naive.

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.


It was Apple's offering only during OS X, and only because its BSD underpinnings. If Apple had chosen to build OS X on a homegrown kernel, Apple wouldn't have been appealing to the skilled.


I disagree that it was only during OS X. Classic Mac OS, and going back further the Apple IIs, were great for power users.

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.


Not sure why you're being downvoted, the only thing that convinced me to use a Mac (for a while) was the BSD base on some nice hardware. Without it it would be like trying to develop on iOS: slow, locked down and flashy.


I wasn't sure how to answer this yesterday. I never experienced Apple's "better days" as I've been developing in Windows for the last 20 years. Apple's current days, well, they seem pretty good for my needs, but I wasn't paying attention during the times you're talking about.

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 like having an intuitive, easy-to-use WIMP system for my common tasks. I don't want to read my e-mail in a terminal window, or use some X11 chat app with a programmer-designed UI.

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.


As far as free developer tools, I again don't know what is different from before. I hear you, but haven't experienced the nirvana you describe: I've been on Windows, where development tools have very often been free to play with and require payment to use them for real work.

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.


Before, the process for shipping an app looked like:

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.


To my mind, iOS security is where it needs to be for that device. I respect your opinion, but we're not going to agree on that. I've considered your argument and I don't see anything that changes the fundamental "so don't buy an iOS device, they do not have a monopoly and there are other fish in the sea". For my part, I'll keep buying them because I follow a similar philosophy that security changes are preeminent and should be allowed to break and constrain other software.

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. :)


That is the common response to my complaints.

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.


If you believe that arbitrary browser code running arbitrary website code doesn't weaken security, then I don't know what to say except I disagree.


Weaken it more than having everybody use the same proprietary build of WebKit? No, I don't think it does.


Maybe. It's not clear to me how many people would go to the bother of unlocking their devices and then complain to Apple when something went wrong if there was some trivial roadblock.

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.


Unless you are trying to argue that iOS is replacing desktop operating systems, I don't see why the presence of a locked-down device is a threat to a general purpose computer. I find general purpose computers are not expensive at all and I don't particularly expect that to change.


The switch could simply be downloading the development tools. Then you know that you're in development mode, and that things could break.


[deleted]


Outlawed? Just because one vendor sells a non-general-purpose computer, you feel like general-purpose computers have been outlawed? I don't understand.


Unfortunately the world we live in suggests that yes, you can do what you want with the device. However, the OS is a licensed piece of software and can only be used within their terms.

It sucks, but desktop OSs technically have a similar right. While I have f.lux now on my phone, I'm happy.


> Side-loading pre-built binaries like that is a huge risk for users

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.


> 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.

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.


You are actually conflating two separate issues:

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.


I'm deliberately entangling them, because outside of an abstract conversation, the behaviour of humans and the resulting economics of the marketplace are entangled, as I'm sure you agree. Freedom for humans creates incentives for manufacturers to exploit that freedom.

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."


r/conflating/confusing


No, I did mean “conflating”.

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.


> distributing proprietary software without users being able to see the source is a Bad Thing.

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.


> That's quite an odd thing to say, isn't it?

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.


> Isn't that how most every exploit and virus seen on Android work?

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...


You're not wrong, but don't those same arguments apply to every other device and platform?

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 consider desktops different than phones. My phone is an appliance for me. I would be pissed if they tried to do it to OS X.

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.


The drama! You're describing the Windows application model of the past 30 years.

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.


>You're describing the Windows application model of the past 30 years.

Considering how many viruses, lost work, malware and hair-tearing that model has induced, it makes sense to go beyond it, doesn't it?


The day I lose the ability to load my own binaries on to devices I own is the day I stop using them.

If you don't have root, you don't really own the device.


Why do you need to own devices? I'm perfectly happy with Apple being my phone's sysadmin, the way my company's IT department is the sysadmin of my workstation (or, more relevantly, the way Google is the sysadmin for ChromeOS devices.)

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.


The comparison with ChromeOS is flawed because you can go into Dev mode[1] on ChromeOS and do whatever the heck you want in a linux userland. There's even a project called Crouton[2] that allows you to install traditional Linux apps side-by-side on your Chromebook. You can also build ChromiumOS[3] the open-source version of ChromeOS and make it do whatever the heck you want.

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 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.

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.


>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.


I'm ~100ms away from most cloud services on a good day, and I've seen ~4000ms in country areas via 3G. Far too many companies are assuming large bandwidth/low latency connections. I'd like my SD card back, Google.

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.


> I've seen ~4000ms in country areas via 3G

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.


Does your motherboard's BIOS allow flashing custom firmware? How about the firmware for the flash controller on a USB stick? If that's your standard, virtually nobody has owned a device in the past 15 years.


I was more talking about kernels and userland binaries - if I couldn't disable UEFI SecureBoot or load my own keys I wouldn't use it.

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?


Mine does -- I have an X200 I freed myself using a beaglebone.

But you are right: no-one has properly owned their own devices since the 80s because no-one can verify them using primary sources.


No, really no. Mild inconveniences dwarfed by the benefits that freedom offered.


Wondows had security problems due to tons of design decision thar went sour.

And current Windows is quite safe. A few safe coding lessons will do wonders for a company :)


No.


>You're describing the Windows application model of the past 30 years.

Windows makes you sign binaries with your own certificate before running them to bypass the signed code protection?


They do with shell scripts (although there's a way to turn it off).


Amen. As a person whose experience as an engineer and admin came almost entirely from Free Software, the fact that so many people who should know better defend Apple's model is pretty pathetic.


The problem is the world is now networked extensively and much more of our 'life' is online. Creating malware and the financial benefits of doing that are much more understood. State actors have invested billions (if not 100 of billions by now) in cyber attacks. I think it makes perfect sense for Apple to police anyone trying to provide unsigned binaries. They protect the security of their i devices in a way that no other ecosystem owner does.


Their devices? I thought people paid for those things.


Ah, that makes a lot of sense. I thought they were distributing the source for you to compile yourself.


> I thought they were distributing the source for you to compile yourself.

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

[1] https://justgetflux.com/news/pages/eula/


Developers distributed binaries before app stores. They could publish a hash for their binary, on an HTTPS web page.


True, but I can understand Apple's position.

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.


If the source of the freeware is authenticated by HTTPS, users can make their own informed decisions, e.g. to enter a risk pool with millions of other users whose health has been improved, courtesy of a known developer with no track record of shipping 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.


I am talking about closed-source freeware only. f.lux is closed source. Nobody can verify whether it does what it says. Apple clearly does not want to set a precedent.

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.)


Millions of people have used f.lux on other platforms. Hundreds of hours of real-world testing per user, multiplied by millions of users, leads to expectations about the behavior of f.lux on iOS. This is also known as reputation, credibility and brand recognition. For those who need what f.lux offers, this empirical data means more than Apple's walled garden theories and non-liablity EULAs.


There is a gigantic amount of closed-source freeware available on the App Store. Literally hundreds of thousands of apps. Roughly zero of which have had any security scrutiny. Apple's review process only checks user-visible behavior. (Edit: and a quick check for private API use, which is not user-visible, but nor is it relevant to security.)

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.


> This is what they should have done. Instead, they chose to distribute a binary of their proprietary (with patent claim [0]), closed source product.

Apple does the same with their own products.


"the same" what?

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


Well, they would sign the binaries themselves if that worked... but you need to sign it yourself to get an iOS device to let you install it.


How is that relevant?


> patent claim

Not seeing anything about patents at that link.


Wikipedia says [1]: "License: Proprietary, with free download. (with patent claim)"

[1] https://en.wikipedia.org/wiki/F.lux


O...k? The linked page doesn't mention patents, Wikipedia doesn't identify what patent, and Wikipedia isn't exactly authoritative anyway.

And also, what in the world does "Proprietary, with free download. (with patent claim)" mean??


Proprietary means not open-standard/open-source.

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...


Go to justgetflux.com and CTRL+F for the word "patent".


That makes zero sense. Millions of people have installed f.lux binaries on more sane platforms without problems.


>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.


Or they just made a public beta program out of their own will -- and not adapted at all.


What is the huge risk for users in sideloading pre-built binaries?

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.


At a minimum, Apple's review process includes a scan to ensure your app submission doesn't include private API usage.

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.


Step 2 doesn't happen. The private API scan is superficial and basically only catches accidental use (for example, maybe somebody discovered the API in a StackOverflow post and didn't realize it was private). It doesn't catch use that people deliberately want to get through. Getting through the check is as easy as some string obfuscation and a dynamic symbol lookup.

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.


What a sad, pathetic day that you have to consider loading your own code a on a general computing device a risk and privilege.


It's not your own code, it's a binary. With your Apple ID, you can always run your own code.


This is not a programming issue, it is a health issue.

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.


So it's a violation of the developer agreement, that's why they pulled it? Of course it's a violation. What do they care? They signed no such agreement and they are not registered Apple developers.

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.


It seems like this was a stunt to put pressure on Apple to make the APIs used public. The temporary solution they came up with was never realistic for a overwhelming majority of users, but it made clear that the only reason why an app like this can't exist is because of Apple's rules.


I like the idea of the product but after sundown frankly it could be replaced with a 20 cent piece of plastic.


> it could be replaced with a 20 cent piece of plastic.

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?


Our local astronomy club just gave out red celophane plastic bags. You could probably use a sheet of that (which looks to be about $15 for a package that you could cut yourself?), and keep it on your nightstand.

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.


Someone could probably make it work via a manual mechanism built into a case -- a loop of transparent film through the case, filtered on side of the loop, with some sort of locking mech to pull the moveable filter tight against glass during usage.


That's the point - you don't have to carry a piece of plastic around with you.

Also the effect appears gradually.


Are you sure they are not registered Apple developers? Seems to me that their being registered Apple developers is the simplest explanation here.


I suppose it's possible, but they don't have any applications under their f.lux brand/company published anywhere. If they're just unpublished but registered developers, then sign up for a new account under a different identity.

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.


Theoretically, Apple could revoke/blacklist the signing certificate for the OSX F.lux app.


That's true, but it would be both extremely petty and a violation of the spirit of the Developer ID program, which is to only revoke Developer IDs in the case of malware. Not because you don't like what they are doing with wholly unrelated applications.


The way this was distributed, everyone who wanted to install had to sign the binary with their own certificate.


Notice the parent mentioned the desktop app, not the mobile app.


On the other hand, they may want to maintain a good relationship with Apple so if/when Apple allows apps to modify the screen's gamma through approved API's they'll be able to start using it immediately.


How does developing the most famous jailbreak tweak for five years constitute "maintaining a good relationship with Apple". As far as I can tell, that went out the window years ago.


Isn't their OSX app signed with a Developer ID certificate? If a relevant person at Apple has their feelings sufficiently hurt by f.lux for iOS, they could revoke said certificate.


IIRC you have to agree to Apple's TOS even if you only sign up for an account to deploy to your device.


I don't doubt that, nor do I disagree they are (or the users sideloading) are violating some agreement. I'm saying, who cares? Jailbreaking and installing f.lux the old way is just as much of a TOS violation and that never stopped them before.


I think you're disappointed in the wrong party here. But I supposed people being disappointed in Apple has never been much of an influence on them before.


> I think you're disappointed in the wrong party here.

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.


I'm no lawyer, but encouraging registered developers to violate their contract with Apple could be pretty shaky ground, legally speaking.


It's called tortious interference with contract and the standards vary state by state. However, the common elements are (1) the existence of a contract subject to interference; (2) the occurrence of an act of interference that was willful and intentional; (3) the act was a proximate cause of the claimant's damage; and (4) actual damage or loss occurred.

Some states also recognize causes of action for interference with prospective relationships, although these are notoriously hard to prove.


What contract? All I see is the same clickwrap you violate when you jailbreak your device and install f.lux the old fashioned way.

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.


Apple solved this bug. After latest update xcode, not a one build tool will run until you accept XCode license even make wouldn't work.


You sign an agreement when you start up XCode for the first time. I imagine it was covered there.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: