Apple has close relationships with those companies so it's often a case of them reaching out to the developers rather than just blinding rejecting the app.
But any idea that Apple would allow them to run ruff shot over the platform and do whatever they wanted is a bit ridiculous.
"Rough shod", before we get another mondegreen propagating across the internet.
Roughshod means the horseshoes have their nails sticking out the bottom to help prevent slipping, so you can imagine trampling someone with those could be painful.
The idiom refers more to what a roughshod horse will do to a road or trail surface; the nailheads dig in and scatter surface material every which way, leaving behind a hell of a mess that'll turn to deep slush or sticky mud, depending on the temperature, with the next precipitation.
Apple uses private APIs (http://sourcedna.com/blog/20151018/ios-apps-using-private-ap...) to build some of their software and reject apps doing the same, effectively killing competition.
But Google and facebook uses them because they want to create products that can compete with apple's features. E.G: https://daringfireball.net/2008/11/google_mobile_uses_privat...
Yet they are not rejected, because they are "big enough".
The only reason I know they do is because some of my friends working on mobile video games regularly complain they can't get some features because they are private while google and facebook do. They analyzed some apps to try to copy said features and realized the unfairness of their situation.
Those are lunch chit chats, not hard facts. But they got seldom reasons to lie.
I'm not sure if Apple made it available to other companies privately though.
Apple often uses immature frameworks internally - like the extensions framework - to to polish them or to dog food them before making them official.
The point is not that these APIs exist; the problem is when vendors actively block others from using them, with hacks and/or policy bans. That's extremely hypocritical and anti-competitive. I can see why unofficial APIs must be discouraged (because let's be honest, developers will bitch and moan when they change -- Microsoft in particular was strong-armed into legacy support for decades by the likes of Adobe and Symantec), but it should never be an excuse to ostracize or tilt the playing field.
It is perfectly reasonable, and so far, any other interpretation seems to be a skewed view to facilitate some sort of non-compliant piece of software.
Security premise: when you are looking at Facebook, you are looking at Facebook. You are not looking at a third party app drawing over Facebook and pretending to be Facebook.
I do not see the above as a slippery slope. Phishing is a capability apps should not have. Even if they have the best of intentions.
Please?
...pretty please?
If MS had taken a harder line then at least hundreds of millions of people would have had faster computers... And arguably safer ones. But it would be hypocrisy for MS, given they gave us IE, ActiveX, DLLs, VB macros, etc.
Most third party firewalls are just GUIs using the OS API for filtering, not parsers written in C running in the kernel.
That being said, it's hard to argue that Apple (or Android) shouldn't be able to set boundaries on behaviors which are only allowed to be done by the OS as a opposed to an app. Apple's tight control of device screen characteristics makes it pretty understandable that they don't want one app able to control how another app looks on the screen.
The optics of the f.lux situation is just really, really bad. But considering the f.lux never really charged, they have a claim to fame that few can match: creating a feature good enough that Apple incorporated into both iOS and MacOS (now in beta).
It's really not. The argument for user freedoms is almost as old as software.