Classy response. I was cringing before I even opened the link expecting whining but I am pleasantly surprised. I use f.lux on my Mac and find it has really improved my sleep. I hope Apple brings Night Shift to Mac as having the feature built-in will help more people. Personally I don't see them changing their policy towards f.lux on iOS until at least iOS 10 as the API's it requires to function are currently private. Maybe with the introduction of Night Shift they'll start to stabilise those and open it up.
I don't see it as classy, because they call to be allowed to do the thing they knew they weren't allowed to do.
And now that it's integrated, what's the benefit of letting a 3rd party do it given how integral it is to the system? That's a lot of risk (wasted battery, making it hard to read, etc.) for little reward.
I think if they had stopped at the "We call for Apple to..." it would have been a great statement. Use it to say "See this is important, so on Android go here and Windows go here and...".
I see it as an attempt to involve themselves with the platform implementors or become acquired by them. Apple, Google and Microsoft will all implement their own version of this in the next few months and f.lux will become irrelevant. Whether or not one of them partners with f.lux or not is what they hope for, I believe.
There is room for third party alternatives to system features.
e.g. spotlight search / watson, iCloud Drive / Dropbox, 1password / iCloud keychain, Instapaper / Pocket / Reading List
Apple's going to go for lowest common denominator, while third parties can go for a smaller slice of that market.
I would love to see both a system feature and enabling 3rd parties to offer this functionality. Don't expect to see it on iOS... it's too small an app class to expect a custom extension point for it.
It's not terrible or rude, but it sounds like they haven't learned anything.
They built an app they knew was against ToS, so they didn't even try to sell it. They then got mad they were told not to do that and called for Apple to let them do it anyway. Then a few months later they called for Apple to let them do it anyway.
Once I read that it was more like hearing a kid say "but mom PLEASE".
It could easily be handled in a seamless way. Have a system default, but also let third-party developers build configuration screens to let users choose when, how, etc. they want to adjustments made. Configuration aside, the only time the third-party code is called is every n minutes where iOS requests "what are the new color settings?" and the app responds. iOS takes those settings and applies them system-wide when appropriate, so (for example) the code is never called when the screen is off, and this would also let Apple provide features such as app-specific exceptions, which the third-party code would have no visibility into. Very similar to how content blockers work for Safari.
In general that's not "the Apple way". When they provide customization points like that (keyboards, notification widgets, share sheet icons) it tends to be after the 'reference implementation' has been in iOS for a few years and the problem has been well studied. Examples where it works very successfully (Android usually) help.
Content blockers are the only thing I can think of off the top of my head that haven't followed this pattern. That may be because it was a feature Apple wanted to improve the experience but didn't want the legal fight that would come with shipping their own blocker.
Thinking of it from Apple's perspective what do they gain from opening up these private APIs? They now have a new set of APIs that they have to maintain, document, and support. Where does the financial justification come from? I honestly don't see "f.lux runs on iOS" being a selling point for most buyers.
What's the benefit? They can do it better perhaps? That they will be able to do things that benefit the customer that Apple can't or won't. Just because Apple releases a feature doesn't mean it's the best in the category (more often it's not).