After reversing the new APIs in iOS9, it’s really really clear that Apple has added lots of great features to iOS (and the new devices) to adjust screen colors. The new models even have RGB color sensing, so they are an ideal platform to build f.lux on. (I was pretty excited about our next version!)
If this were only about reverse-engineering or using LLVM to compile code I wrote, it would be reasonable to fight it. The remarkable thing about their agreement is that it concerns using information that is not provided under the agreement. This is a reasonable term for app store distribution, but it seems unprecedented and heavy-handed for unsigned binaries.
Ultimately, we pulled the app both to show good faith, and also because we were asking hundreds of thousands of people to use Xcode to make accounts and sign our software. When Apple calls up and says they don't want that to happen, it is not really a thing you can fight. It’s their infrastructure, and they can decide how it is used.
We were feeling pretty good about introducing “building stuff in Xcode” to people who’ve never tried it before.
We have been as polite as we can to Apple in hopes that they will open up the platform to developers like us. The demand for f.lux is certainly incredible.
> Ultimately, we pulled the app both to show good faith, and also because we were asking hundreds of thousands of people to use Xcode to make accounts and sign our software. When Apple calls up and says they don't want that to happen
I called this yesterday[1], and I was told Apple would never do this.
Now that they did... Gee, colour me surprised!
To be honest I'm a little bit surprised. I assumed it would take more than 24 hours. Good job being the tech kill-joys you always are, Apple.
When it breaks they have to deal with it, not the f.lux team.
It's the same reason they don't want apps that ask you to throw your phone in the air, or put a bag full of sugar on the screen for weighing purposes.
Not justifying anything just explaining their PoV.
This is a bit of a strawman argument, F.lux is not in this category of silly apps. F.lux is a reasonable app it has a good track record respecting its users and is requested by many many users. It is about control.
Think about the cost to Apple's support teams after grandma is having problems with her phone being yellow. Her grandson definitely was not messing with her phone, at all...
I'm rather confused as to why you thought the following:
> We understood that the new Xcode signing was designed to allow such use, but Apple has indicated that this should not continue.
Where has Apple ever indicated that the new Xcode signing was intended for your use-case? I never saw the download you provided, but I'm assuming you didn't actually release f.lux as open source, but instead just provided essentially a prebuilt download and had Xcode re-sign it. Is that assumption correct? Because that seems to be a pretty blatant violation of the spirit of the developer program, even if it's not explicitly spelled out in the agreement. The new Xcode signing model is intended to allow people to get started with iOS development without paying any money, so they can build and run their own projects on their own devices, and only have to pay for the dev program when they want to start distributing to other people. If you did in fact release f.lux as an open-source project, that would be within both the spirit and the letter of the agreement (I doubt Apple has any problems with people installing open-source apps on their personal devices). But it should be obvious that Apple wants all binary distribution to be done through the app store (or enterprise distribution where applicable).
Speaking of enterprise distribution, did you ever investigate that approach? I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement. But I've never actually looked into it myself so I don't know.
I gotta say I was infuriated until I read your comment, you totally nailed it.
Distributing binary code to thousands of iOS users is dangerous, if nothing else. So Apple clearly has a point trying to control distribution through the app store.
And if the author truly does believe in curing sleep issues, as they state, then they should have released the source code and let people install the app themselves.
In fact, with 176000 page views, and 15 million downloads of their desktop app (I myself have been a long time user) I don't see why he didn't just pay the 99 USD and distribute it via the app store. I certainly would have payed for it because it pains me to see my SO in bed solving sudoku with a flipping 50W lamp in her face.
That's correct. Additionally, although there are many ways to work around these static code checks Apple performs at app review time (due to Objective C's runtime capabilities), you can bet an app as popular as f.lux would get pulled very quickly with potentially long-term damage to their relationship with Apple*
> "I'm going to guess Apple has some stricter requirements on getting an enterprise developer program account, and I don't know if there's any restrictions in the agreement."
There are. Using enterprise distribution to distribute to the general public is explicitly disallowed for some IMO really good reasons (the ability to call private APIs being a big one).
There's some gray area when it comes to using enterprise distribution (e.g., to external testers not otherwise affiliated with your company) and Apple generally doesn't police these, but allowing the general public to install is very, very much against the rules and will get you banned.
So that's how it is nowadays, pay the Apple extortion fee it's good for you . As an app developer with principles I will never endorse Apple's business model as it is toxic and destroying the open internet. That users will not find the app is actually good as it might make them consider switching provider for their mobile OS and one less iOS user is a victory for anyone carring about the health of the internet market and mobile ecosystem at large.
> So that's how it is nowadays, pay the Apple extortion fee it's good for you .
That's not what OP is saying, though. The f.lux folks were leveraging private APIs, that are unpublished and not part of the set of tools you're authorized to build commercial apps on for iOS. Apple doesn't want to support those APIs for whatever reason, so they're not included in the toolset. Just because you can find a way to do something (like distributing binaries to have users compile into their own version of an app, trusting that the distributor is trustworthy, that the distribution hasn't been corrupted somehow, that...) doesn't mean it should be allowed willy nilly.
Strong requirements like this at some level have kept quality in the average iOS app high.
I recently dumped Android for iOS again because I got sick after 4 years of my devices never quite working right. If I don't have to spend so much time on my iPhone policing apps from randomly deciding to go off the reserve (like happened even with quite popular apps on Android), I'll take that over complete unfettered license to muck about in the operating system.
Cause that as a practice just doesn't turn out well. For every f.lux there's 100 development operations who are gonna screw something up.
I've been an Android user ever since 2011 and I also own iOS devices. Care to name "popular apps on Android" deciding to "go off the reserve" and that don't work?
My first smartphone was actually an iPhone 3GS. Because of Apple's walled garden, it couldn't help me with a really simple and downright obvious task for a smartphone - blocking unwanted phone numbers from calling or texting me. People had to jailbreak their phones and install Cydia in order to do that. And because Apple caters to users instead of mobile careers, my iPhone could not tether my 3G connection either because Orange wasn't allowing it without an extra $5 per month. Oh wait, I think I got that backwards. So another use-case for which my smartphone was completely unsuitable for.
Now I've got an iPhone 6s that I received as a gift (well, I'm blessed with friends that think I want Apple stuff just because I use a MacBook for work). And I find the restrictions to be as annoying as ever. Yesterday's Firefox release for iOS reminded me of this very fact. On Android I've got the real Firefox and it can do extensions and it can innovate. For example I was blocking ads long before iOS 9, the very concept of ad blocking happening for Firefox first. Plus I use Firefox on my desktop so syncing is nice and I hate monocultures, like what WebKit has become. You see, I couldn't give a crap about F.lux, but I do care about having Firefox, as it's the open-source browser that saved the web and the browser that now keeps WebKit from taking over the whole market, like IExplorer 5 and 6 once did.
> I'll take that over complete unfettered license to muck about in the operating system
I understand that, but this is were we disagree the most. In society people can be very evil, people can steal from you, can leave you without your job, people can hurt you and your family in myriads of ways. Yet we can cope with this uncertainty, as we've invented institutions that protect us in times of need, we came up with rules for interacting with society (e.g. the concept of trust), we do our part in educating our children to not be complete assholes and all of this usually works, in spite of having certain rights and freedoms, like the freedom of expression, the right to having property, or the right for privacy. People often forget about that last one of course, as we increasingly prefer to police our peers in the name of security, in spite of a lack of evidence that it leads to a more secure environment and often forgetting what it is like to live in a police state, though as somebody that grew up in an Eastern Europe country that was once a police state, trust me when I say that's not nice.
But back to the point - personally, I consider any platform that rejects useful apps to be completely inappropriate, no matter the reasoning. And of course, Apple can do whatever they wish with their property, which is a fundamental right after all, but that doesn't mean I can't exercise my freedom of expression to bitch and moan about how much that sucks.
As is the expected answer to your softball there, no, I don't keep a list of apps I had issues with in my back pocket. You can choose to disregard my previous post if you'd like given this shocking revelation, that's kind of the point right?
I suspect there's a solution for every trouble I had, but the point is that after 4 years I don't want managing a phone to require that much of my life.
> I understand that, but this is were we disagree the most.
Apple isn't the USSR, nor a post-USSR bloc state. It's in a sense an agreed-upon model for the social structures you're discussing here.
Many, many consumers have chosen the ethos of Apple-as-institution.
Not sure what your point is with the right to privacy stuff. I'm not sure I've seen compelling evidence that Google of all companies protects your privacy any better than Apple.
Edit: Here's one[1] comment at least on the different approaches the two companies have taken, and the advantage Google may have with it's softer stance on protecting your privacy. (Though, I'm sure the source is biased in some way, it's just one article.)
But back to the point -
It's good that your personal definitions disagree with the line Apple draws between "useful" and "potentially dangerous to the experience or stability of the phone." You should absolutely have your own opinion and make choices based on it, I've nothing to say in the contrary.
I can name everything that frustrated me over time on both Android and iOS. And I can certainly name ways in which the apps I use have failed. I also have a pretty bad memory in general, the only reason for why I can remember such things is because we humans have a pretty good memory for things that cause us grievance.
This is why I was curious, as I certainly want to learn from the experience of others. You not being able to name apps that you claim have been going "off the reserve" and "muck about in the operating system" is a pretty strong indicator that you're probably lying. Again, this is how trust works.
And I wasn't talking about who is providing better privacy, but about policing your peers in the name of some bullshit security claims and other nonsense. Practices which have been agreed upon, embraced actually in the former USSR by its people. Or maybe you've got the impression that the "social structures" in the former USSR weren't "agreed upon", but that would be odd.
Even more so, you seem to think that iOS apps don't go "off the reserve". Remember that time when it was discovered that Twitter on iOS is tracking installed third-party apps from last year? As if everybody else wasn't doing it - I know because I participated in the development of such an app a year earlier. And do you know how Dropbox detects movement to wake up its app in order to backup your pictures? It must do that because otherwise iOS doesn't leave background processes running, so instead Dropbox is asking for (and has the potential to track) your location. And do you remember when VLC was pulled from the iTunes Store (not sure why), with the iTunes Store being then filled with knockoffs guilty of using VLC's name and logo, and probably spyware (since that's what knockoffs usually are) with Apple not lifting a finger to clean that up?
There, I just named 3 instances for iOS without being a heavy iOS user.
> This is why I was curious, [...] is a pretty strong indicator that you're probably lying.
Like I said above, discount all of my comments if you'd like, that was your goal in the first place.
It's an indicator that I didn't keep a list, and that, as I said, I don't want a phone to be such an important part of my conscious experience that I could do so. I doubt any list I gave you would actually lend credibility here, as your position seems to be to discredit vs discuss.
> Again, this is how trust works.
Not really, no. Trust is established through a set of conditions two or more parties agrees establishes authenticity. You've just made demands, I'm pretty sure.
> And I wasn't talking about [...]
Neither of these products is "policing your peers in the name of some batshit security claims." Apple, Google and Microsoft have published ground rules for playing in their playground. You said above that you don't want to play in Apple's.
So don't play in Apple's. That's totally cool. I just got sick of playing in Google's. It's counter to your message to attempt to force someone else's compliance with your set of values, isn't it?
I think Apple may have been a bit too generous with this offering. How long does the code signing stay valid this way? Forever?
I think it would have been sufficient for the majority of use cases if an app sideloaded like this would only be valid for like 12 - 24 hours. I mean, as you wrote, this system is supposed to be for devs who want to test their apps on devices without having to pay for the dev program.
I think 12 hours would be enough time to judge you progress on device. Since you are going to test many iterations of that app, you are going to deploy it often anyway. Why would there be a need to have those apps work forever?
I realize there are edge cases where some people would want a longer, broad beta test for their app but is that really necessary for such a "free" option? Surely if you plan out your app of such scale and you arrive at that point in time to warrant a week long beta test you will very likely deploy on the app store anyway so you might as well buy into the 99 bucks a year program to correctly sign your apps.
Had Apple directly limited the time sideloaded apps like that work and made it public that this is "just" a feature aimed at developers to become interested in iOS development, this whole thing could have been avoided.
Why time-limit it? There's no rule that says you must publish every app you make to the app store. What if you're making an app that's intended precisely for your own personal use and nobody else's?
> We have been as polite as we can to Apple in hopes that they will open up the platform to developers like us. The demand for f.lux is certainly incredible.
This doesn't seem to be a winning strategy with Apple -- they move at whatever pace they want. A better move might be to continue to offer the download and show overwhelming interest in the product, enough that when they shut down the taps the users revolt and force Apple's hand.
Have you considered open-sourcing your code with a license you're comfortable with? http://choosealicense.com/
As a developer who suffers from sleep disorders (both sleep apnea as well as general restlessness which is fortunately aided by f.lux!), how do I donate to your project (ideally in bitcoin)?
> We have a version internally (it looks beautiful!)
> but it requires a very complicated installation
> process. We are working to simplify this and ship
> f.lux to the Android OS as soon as possible.
I'd have thought Android users would generally be more willing to do this "very complicated installation" than iOS users would be to sideload with XCode, but there you go.
Twilight and Lux both contain naive implementations using a semitransparent overlay. The result of this that blacks and dark colors end up being brightened instead of left alone, as a proper color-temperature change would do. This looks bad on all screens, but especially so on AMOLED displays that support a true black.
Cf.lumen[1] is, I believe, the only Android app that can actually change the color temperature of the screen like f.lux can, but it requires root as well as installation of a special "driver" in order to do so. My guess would be that the "complicated install process" referenced by the f.lux devs is probably similar.
> And Cyanogenmod has a built-in color temperature changer anyway.
Really? Cool! Where is it though? I just went through the settings and couldn't find anything but Display & Lights > Colour calibration, which just gives some R/G/B sliders (that don't even seem to do anything?) no colour temp, that I could find.
I have no idea. But the developers (of f.lux) seem to claim elsewhere that the existing solutions aren't 'solutions' at all; don't do it properly.
I can't speak for the truth of that though. I've used the aptly named "Blue Light Filter" which seems to work fine. CyanogenMod OS bundles something which seems okay too.
CyanogenMod also has a very nice feature which adjusts the colour cast of the screen based on both time of day and the colour of the light hitting the RGB sensor.
It's integrated in CM. Not flux, but something that works very well (as opposed to twilight for example). Too bad I had to switch to 11. Anyone know of a solution that would work for me?
Well, Redshift is a lightweight program that also works, and has a simple-to-use shell command. That's attractive to some Linux-users :)
And it goes all the way down to 1000K, leaving only the red channel :) Which is not particularly useful, but it does make Redshift literally cooler than F.lux.
Thanks for the awesome software! f.lux was the only reason I jailbroke my phone, over a year ago.... glad to see its possible to install on an iOS device without jailbreak now...even if the install process is circuitous
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.
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.
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!
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.
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.
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'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.
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.
> 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.
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.
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?
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.
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.
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.
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.
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.
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 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.)
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.
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!
"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.
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.
> 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.)
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 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.
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.
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. :)
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.
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.
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.
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.
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."
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.
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:
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.
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.
> 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.
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?
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.
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.
>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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
All this passionate advocacy, and they won't even mention that this is allowed on Android (with a few apps doing it distributed through the Play Store) - or build an Android app themselves? I get that people are iOS fans, but there seems like a bit of Stockholm syndrome here.
The apps that change screen gamma on Android still require root, so it's not as easy as going to the Play Store on any device (at least the apps are on the Play Store if you do have root though).
There are non-root apps that use an overlay instead, which can sorta help but it's not an optimal solution.
Regardless of how it is accomplished, I use Twilight for Android, and I love it, and it is the number one reason I can't go back to using iOS. It has made a HUGE impact on reducing my insomnia, and I will not look at any screen without a screen reddener within a couple hours of bedtime.
wurd, I really like iPhones and iPads. But I find the OS hard to deal with. Twilight is a good example. Theres also an Audiobook app I love that could not be used on iOS. I don't want to be forced to use Safari or a rebranded Safari. The list grows :)
I think the proper solution is to add gamma correction APIs to Surface Flinger and get that upstreamed so eventually all recent Android phones will support it without root. At least, that was my idea when I looked into it. IIRC OpenGL ES 2 was missing some OpenGL proper feature that would have made the gamma correction easy.
It works alright, but as the parent mentioned it only provides an overlay. It can't change the underlying colour temperature. (Basically it can add orange, but it can't remove blue.) I've used Lux with and without root, and the experience with is definitely superior.
That uses an overlay instead of actually changing your screen gamma (essentially it's adding more red instead of directly reducing the amount of blue). I definitely agree that it's more useful than nothing at all like on the iOS App Store.
I don't know which license matches this so I'm going to write it out. You can do what you want with the code, but do not distribute compiled copies of the app, especially on mass download sites.
I mean, it's not quite BSD, but it's hardly 'all rights reserved'.
That's the default header created by Xcode when making a new file, I didn't add that on purpose. I suppose I should go through and get rid of those lines.
My guess is that it might have a negative effect on rendering energy consumption.
In OS X you can use CoreImage to filter a view, but that has always been excluded from iOS.
The platform perception management kicks in, they can't let all the cool kids install a filter on top of all the rendering then complain that iPad and iPhone battery life sucks.
In my own Sudoku program I automatically manage the screen white point by sensing the backlight level (I'm not allowed to use the ambient light sensor, so I watch something that watches it.) but I have to do it by changing all of my colors everywhere I draw. It's not a big deal and works beautifully, until you finish a puzzle and the pure iOS alert comes up in full white and burns a hole straight through your drowsy dark adapted retinas. Then you have to go to sleep because you have a huge afterimage floating around in the center of your vision.
Hard to say. Sometimes Apple's OS is just legitimately missing the feature (I'm reminded of the tricks needed to have one process render into another process's window before QuickTime needed that feature for 10.6).
Honestly, I'm surprised more people aren't responding "Wait, why _isn't_ this possible in iOS? Windows has had the necessary tools to do this for years."
> Honestly, I'm surprised more people aren't responding "Wait, why _isn't_ this possible in iOS? Windows has had the necessary tools to do this for years."
Not enough people care. On the grand scale the number is tiny. I'd imagine that's because so few people have heard of this. As you said Windows has had it for a very long time but the vast VAST majority of people dnot use it, it's still niche.
When enough people want some (say user swappable keyboards, or Notification Center) Apple adds it once they have a good design.
Geez Apple just keeps doing terrible on the app developer relations front. I have talked with startup founders time and time again they tell me their iOS apps are more barebones because Apple's policies or permissions prevent them from implementing the same features they can implement on Android
How is 'not publishing unlisted APIs that have been unpublished for years' Apple 'doing terrible things'.
These guys blatantly violated the TOS. There should be no surprise here. If anything what they did was basically a stunt.
> I have talked with startup founders time and time again they tell me their iOS apps are more barebones because Apple's policies or permissions prevent them from implementing the same features they can implement on Android
Apple implements things at the pace they want. That's one of the reasons things in iOS are generally well thought out and it's so hard for a rogue app to destroy battery life or violate your privacy.
Apple chose the trade offs they want to make, andnit seems to be working very well for them.
Can someone who downloaded yesterday please publish a sha256sum of the zip (or each file in the directory tree), for comparison with the github mirror?
For various reasons (at least, metadata and the .git folder) it's very unlikely that you'd get the exact same checksum for the entire zip... you'd need to post the sum for each file individually if you want to compare them.
I diffed the version on GitHub with the one downloaded from Dropbox (after verifying the Dropbox file's hash). The only changes to the GitHub version are the Readme file and that it was upgraded to target iOS 9.1, as well as some apparently minor changes in the XCode project file. So you won't get the same SHA sum, but all the files aside from those are the same. In particular, the "iflux" binaries are identical.
So it looks like the GitHub version matches the original.
I'm not 100% sure. The version from Dropbox has some differences in the Xcode project file, including a different "target version". The Dropbox version says it targets 8.0.
For those interested in verifying the f.lux they downloaded from 3rd party sources, there is this thread on the forum providing a hash of the official file.
Apple won't let apps use APIs that aren't officially approved. Officially approved APIs can't do the things that flux needs to do. So, no flux on iOS in the App Store. The flux developers put together a beta that used said APIs and made it available for sideloading. Apple killed that off as well by threatening to kill their account due to a violation of the Developer Agreement which prohibits distributing your app anywhere but the App Store. Apple will only let apps onto iOS devices via the App Store. No side loading, no direct downloads, no third party app stores.
The confusion is that the "sideloading" was just an Xcode project along with instructions for how to build it. It's hard to figure out what part of that is supposed to be a violation. Are you not supposed to provide Xcode projects to other people? Are you not supposed to tell them how to use Xcode? Or is it just the fact that they were too overt about the purpose of it all?
You don't have to be in the Apple developer program to post an Xcode project on a web site. Nor to download Xcode, since it comes free from the Mac App Store.
Lowercase free is not the same as uppeprcase Free. Xcode is freeware (as in no cost) but it has a restrictive 14 page license attached to it that you must agree to to use it.
https://www.apple.com/legal/sla/docs/xcode.pdf
You can only allow third parties to install your app on their devices for testing if you have written approval from Apple.
You can only use a limited number of devices that you/your company own for testing.
Your license to use Xcode, the SDKs, and release software for iOS can be revoked at any time: "Apple reserves the right to revoke, disable or suspend any Provisioning Profiles or any access to the device deployment and provisioning features of the Apple Software and Services at any time, in its sole discretion. By way of example, Apple may do this if Apple has reason to believe that Apple IDs were fraudulently obtained, that an unreasonable number of devices have been entered into the Apple Software, and/or that the Services are being used in a fraudulent, suspicious, or improper manner."
> it has a restrictive 14 page license attached to it that you must agree to to use it //
That you're supposed to agree to. What proportion of the users of Xcode do you suppose have even read that license?
Also the license doesn't prevent you using it, though it possibly prevents you from legally using it for commercial purposes in most developed nations.
With the recent case concerning sending data abroad to process to circumvent patent restrictions it seems that f.lux could just have someone in a country with no copyright/license restrictions download Xcode, compile and make available the software. Apple Computers after all wouldn't own code created with Xcode, which would be a technical rather than artistic work anyhow, so there doesn't appear to be a problem of copyright.
Apple could likely still pull strings that the f.lux people wouldn't find helpful however (maybe the devs have other apps that Apple could block, for example).
I am not sure what you mean by 'supposed to' agree to the license. You are correct in that the license doesn't self-enforce, but legally you have agreed to follow the license when you download the code. So, Apple can take legal action to enforce compliance with the license, which is what they did whey they sent a C&D notice to f.lux.
A license can restrict non-commercial purposes, too (as long as they aren't purposes protected by law, e.g. fair use). While it is true that most companies only go after license violators who are using the software for commercial purposes, that is only for practical reasons, not legal.
A license can restrict use, but copyright concerns copying. They allow copying of the code, which is necessary for use, but attempt to acquire acquiescence to their license terms. I'm not sure however as there is no consideration how users can be considered to be under license. In short if the copying is fair-use, which it looks like it reasonably could be, then how can the use be controlled?
What if they, hypothetically, developed their code with a separate toolchain/IDE and didn't use xcode at all? Are they still bound by the terms of it, or is it the users compiling the app to put on their phones bound by it? I'm also pretty sure advocating people violate a license agreement isn't illegal, or did Apple get an exemption for the first amendment?
I realize f.lux was distributing a compiled binary instead of telling people to compile it from source, but I think Apple would have sent them a C&D just the same if it were just source.
I think it has to be something to do with the binary component. I can't see this being an issue if they'd delivered all source code in their project and required users to build the entire thing.
I think you're correct. They were distributing an iOS app outside of the approved channels, which is explicitly called out near the very top of the Apple Developer License Program agreement:
Applications developed under this Agreement for iOS Products, Apple Watch, or Apple TV can be
distributed in four ways: (1) through the App Store, if selected by Apple, (2) through the B2B
Program area of the App Store, if selected by Apple, (3) on a limited basis for use on Registered
Devices (as defined below), and (4) for beta testing through TestFlight.
This is tough. On one hand, there's obviously a demand (of which I am part) for f.lux, but on the other, 15 million downloads, despite being a respectably big number, barely registers compared to an install base that can grow by 75 million in a single quarter. Using private APIs does negatively impact the iPhone experience (witness the constant screen wakes in the pulled Xcodeproj), and making those APIs public has development overhead – As big as the iOS team may be, its human resources are finite (even if Apple's cash reserves are barely so).
That said... What percentage of Apple's user base lives with disabilities? What percentage is visually impaired; what percentage has motor difficulties? These are clearly worthy, comparatively small populations of users that Apple devotes an otherwise-inordinate amount of development resources to. Maybe it's time Apple considers melanopsin sensitivity worthy of admitting to this circle.
It seems to me that there could be a half-way model. Some permissions are surely problematic to give to everybody. But perhaps they could then not give them to absolutely everybody? One option would be to require preapproval. The other would be to say that they are sensitive, such that Apple gives apps that use them a much lower threshold for complaints.
I'd imagine they don't want to end up looking like they're encouraging this behavior in anyway (including tacitly). Flux may be relatively harmless, but that might not be the case with other apps.
We can only hope that control of blue light emissions will be natively implemented by all phone and tablet manufacturers, to protect the future health of billions of humans. Here are some articles about the impact of blue light on eyes and sleep.
http://thenextweb.com/lifehacks/2014/04/23/7-things-can-righ..., "Blue light is able to pass through what is called the retinohypothalamic tract, or pathway. This pathway is responsible for regulating our circadian rhythm and a number of other biological and behavioral processes."
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2831986/, "Hastings and Sweeney’s paper, published in the December 1958 Biological Bulletin, gathered dust for decades. No one thought these findings might hold any relevance for humans, whose circadian rhythms were then widely believed to be relatively insensitive to light. But scientific discoveries in the past two decades have changed all that."
https://theconversation.com/a-dark-night-is-good-for-your-he..., "In the last decade or two it has become clear that the genes which control the endogenous circadian rhythm (the “clock genes”) also control a large part of our entire genome including genes for metabolism (how we process the food we eat), DNA damage response (how we are protected from toxic chemicals and radiation), and cell cycle regulation and hormone production (how our cells and tissues grow)."
There is room lighting with low-blue content, e.g. the G.E. Align PM bulb, http://www.amazon.com/gp/product/B00PLR3M0M & https://gigaom.com/2014/09/01/what-is-the-blue-light-from-ou..., "It remains unclear whether our screens themselves will soon emit less blue light — Hansler is pessimistic because he says that changing the amount of blue light will be like admitting that the screens are causing health problems, and lawsuits could ensue."
> We can only hope that control of blue light emissions will be natively implemented by all phone and tablet manufacturers, to protect the future health of billions of humans.
A little hyperbolic there, no? I'm surprised to hear this is even a problem that exists.
> GoodNight is an app that allows you to directly access the screen's gamma levels, and modify it using IOMobileFramebuffer. With this you can do any of the following:
Change the screen temperature, Put the brightness lower than iOS would normally allow you to, Adjust the RGB values of the framebuffer
> This application uses dlsym, which loads in the private symbols at runtime, rather than using headers, so no additional setup is needed once you download the source.
After they stuck a middle finger in Apple's face in public?
Surely Apple already has people who are smart enough to do this. They have some of the most color accurate screens in the world and worked really hard on that kind of thing there's no way they don't have people who would know how to do this.
Isn't the Apple way to invite them in to talk about their software intimating a buyout then incorporate the software features and sideline the other company?
Just from a misremembered story I can't pull up from memory about Steve Jobs interactions with a music/audio software company in the earlier days of Apple.
No, you misremembered it. Apple set up a meeting with Panic (makers of Audion) but they had to cancel because they were trying to get bought out by Aol. Apple ended up buying competitor SoundJam to use as the basis of iTunes and then still offered to hire the Audion devs but they declined.
If you're looking for 10-15 year old story where Apple famously ate someone's lunch then Sherlock/Watson and Konfabulator/Dashboard are some of the more prominent examples but those are fairly obvious directions for OS makers to fill.
This is why I much prefer using Android devices. Apple and their grandiose pretense think they know what's best for us, I prefer a bit more control. It's so sad because they do make the best hardware!
I don't get it. Is Apple against programmers publishing their own source code? If the authors are giving away the code anyway why not just put it on GitHub and let anyone clone it and use it?
Ahhh. In that case, I can understand why Apple wouldn't want to encourage this. if he just open sourced it, Apple wouldn't care about him distributing it or using private APIs.
I setup a shortcut on my iPhone. When I triple tap the home button, my screen becomes dimmer than the dimmest setting on a MBP. If I triple tap again, it returns to the previous brightness settings.
I haven't read any research on this, but this feels incorrect. If this is true, staring at red-tinged floodlight should do less to keep you awake than looking at a blue LED with masking tape over it.
It feels more likely that this is related to excitation of S cones -- which dimming the screen without changing the colour temperature would also accomplish, to a degree.
In Xcode 7, you can install apps directly to your iOS device with a free account from Apple. So we decided to make a beta version of f.lux for people to try.
It’s a few more steps than installing the app store, but there are plenty of harder things even on Pinterest. So, here’s how to get f.lux installed on your iOS device.
Download f.lux for iOS
for use with Xcode 7
Ingredients
Mac, OSX 10.10 or greater
1 installed version of Xcode 7
1 Developer account (use your AppleID)
1 Download, f.lux for iOS, unzipped
Instructions
First, mix the build ingredients together. Batter may be slightly lumpy.
Open the “iflux.xcodeproj” project in Xcode
Open Xcode > Preferences > Accounts and enter your iCloud or developer credentials
Under Targets > iflux > General > Identity, add a word to the end of the Bundle Identifier to make it a unique name
In the same place, under Identity > Team, select your iCloud account or Developer profile
While the batter chills, connect your iPhone or iPad and load the iflux build:
From the Xcode Product menu, choose Destination and select your iOS device (f.lux doesn’t work in a Simulator)
Push Cmd-R when you’re ready to have f.lux
When you first run, you’ll be prompted to open Settings > General > Profile on your device, and trust your developer account
Run again, and allow location and notifications (things don’t work so well without both of these)
By loading an app this way, there are no automatic updates or bug fixes, so this version does a daily update check. If one is available, a message will appear at the bottom of the app, so you can stay up to date when we make fixes.
(instructions are still there if you scroll down, I guess they'll delete them imminently)
Incredible how developers are always ever so gosh darn polite when complaining about Apple, who in turn tend to respond/not respond in a blatantly passive-aggressive manner.
Is there anything stopping you from throwing this up on Github with a CC non-commercial license, or does that also break the Apple Developer Agreement?
Problem is that it is pointless, because the f.lux is released as a binary.. it is not like we can just look at the source code to change the 1900K to whatever temperature we wanted
My 2010 Macbook Pro heats up and has fan going off crazy, and my 2008 ThinkPad T400 is sitting next to the MBP, just chugging away like a champ.
If you are talking about user interface, I agree on that. But hardware wise, I am not that impressed. However, if you do run into hardware issues, AppleCare is excellent.
Well I got screwed and couldn't obtain the original version (was in airport at the time) but I seem to have obtained an alternate. Been waiting for this for years, no surprise Apple tried to screw users immediately.
Your comments in this thread are out of line. They aren't constructive critique or any critique at all, but a vendetta that crosses into personal attack. You can't do that on Hacker News, so please don't post anything more like this.
Edit: it unfortunately seems you've done this before. We ban accounts for this, so please: no more personal attacks here.
You don't know enough to rant like this. You are also cherry picking specific details to make them sound bad. You sound like an asshole. That is why you are getting down voted.
>A wealthy California couple that previously got famous for refusing to give their fingerprint while attempting to buy a new BMW in cash spends six years making this product? And now their complaint is that you can't use your fingerprint to authorize installation of it via the app store?
Most people buy cars without ever being asked to be fingerprinted. I don't think that's really on them so much as it is on the crazy dealer.
I don't understand why you call f.lux's inability to get in the App Store "drama." The reason it can't get in the app store is really simple: Apple provides no public API to do what that app does, and Apple prohibits the use of private API in the app store. It wouldn't matter who was doing it, Apple wouldn't allow it regardless.
So I really see no connection between being unable to get f.lux into the App Store and making the news for refusing to allow a BMW dealer to take fingerprints while buying a car.
And suffer multiple regressions just for one progression? No thanks. I gave up a few nice things moving from Android to iOS, but I gained much more than I lost. In the end it would be quite a bit of hassle.
I will say that I wish Apple would either build f.lux type technology into the OS as part of the Accessibility settings, or just allow the f.lux developers to use the APIs they need. When I did have an Android phone it was a welcome tweak that made it easier to read on my phone before bed.
Mostly stability. I've yet to own an Android phone that the dialler hasn't crashed either placing or during a call. And I've owned around a dozen different Android phones since 2010. I've had issues with GPS being wildly inaccurate, screens losing touch sensitivity, random force close events in Google and third party apps, terrible camera software, WiFi working sporadically or not at all, sound server crashing in the middle of calls (Nexus 4 is notorious for this), and so on. All of this across the gamut of cheap to flagship phones running AOSP, Cyanogen, and carrier/manufacturer ROMs from 1.5 through 5.1.
There was a time when I wouldn't touch an iPhone with a ten foot pole after using the original and a 4S, but with the 6 and iOS 8/9 Apple has finally made a phone that surpasses Android and Windows on the balance of stability and function.
Very strange. I too have owned multiple Android devices but never faced so much issues on branded mobiles. Never seen dialler crash even on cheap mobile. Experienced random crash on a very early very cheap tablet. I did lose touch sensitively(not fully but a narrow strip) on N4. Which resulted in me purchasing One Plus X. The mid range mobiles are now very good. iPhone was always out of question for me prices are too high here.
There are a lot of compelling and expedient reasons why iOS is the way it is. Apple isn't the only player on the market, and they aren't misleading or a monopolist like IBM was in the 80s or Microsoft in the 90s.
As for why can't you do on iOS what you can do on your Mac... Apple doesn't want the types of problems that android has.
You're right this is not like Microsoft in the 1990s. It's significantly worse than that. Microsoft, for all their faults, constantly championed developers on their platform. Just think of that Steve Balmer "Developers! Developers! Developers!" video.
Apple, on the other hand, consistently treats developers on its platform with nothing but disdain.
Worse -- For developers. Apple's customers are users.
Users benefit from a secure system, mostly safe applications and consistent UI.
The consequence of Microsoft's fuck-the-user, go developer philosophy has been over a decade a pain for the users. That's why Dell and HP are giving away PCs under cost while giving up share, while Apple is growing and making a killing.
Speaking as an iOS developer, you do not screw with the fruit.
> Developer learns iOS
> Developer uses private APIs (which is neither easy, or allowed per the terms they agreed to)
> Developer sends in app for approval, is rejected for above because duh
> Developer whines on the Internet and gets a bunch of people angry at Apple, who likely will not change.
You know I feel the need to point out that Apple doesn't lock us out of code to be mean, they do it because it ensures their devices don't suck, because we as developers do not have access to the system level things that can make them suck.
Developer develops a tweak requiring a jailbreak. It becomes one of the most popular jailbreak tweaks available. Five years pass, Apple inadvertently allows sideloading by giving anyone who wants one a dev certificate. Developers utilize this to create a version of their tweak that can live inside the sandbox & can be signed by end users, but still utilizes private APIs.
They develop this and release it, knowing full well that they're doing an end-run around Apple's policies, very similar to requiring a jailbreak. They did not develop it expecting it to be approved. I have no clue where you got that from.
The only confusing part is when they caved because Apple complained, knowing full well they would complain at some point.
It doesn't help to ensure anything. But having binaries out there that anyone is encouraged to sign and install, with no way to know what hidden features are there in what projects, is not a very well thought out model if Apple wants to make suckage less likely.
How is it any different than having binaries on the App Store that anyone is encouraged to install, with no way to know what hidden features are there in any of them?
As you well know, upon upload for App Store submission, Apple runs processes that scan those binaries for use of private APIs. Admittedly imperfect processes, yes, but different from having no processes whatsoever.
Yes they are balancing the cost/benefit equation of the untold levels of damage to consumers and to Apple itself potentially done by bad apps on one side, versus the relatively less impactful in their judgement benefits of potentially useful apps on the other side. The assessment that this increases the device's suck relies on an certain assumptions about just how bad the damages could possibly be, assumptions that you make, but that they are reluctant to make on behalf of their users.
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.