It is surprisingly simple to make an interpreter that is "accidentally" Turing complete (this IMHO so often happens by accident that I love to say that if an interpreter is not "obviously" more restricted than a Turing machine, it probably is Turing complete).
This is not just my opinion - there lots of pages in the internet of things that are "accidentally" Turing complete, for example:
http://beza1e1.tuxen.de/articles/accidentally_turing_complet...
Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.
> Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.
Apple cannot change mathematical facts by "decisional" rhetoric.
I just don't understand how Apple is supposed to draw a line here.
> With Rollout’s SDK you can update and modify your Objective-C methods with logic written in JavaScript so we’re good on the first condition.
I think that is the problem with Rollout.
"Code" is another term for what you are referring to as "binary".
An example that comes to mind is a high speed image compression app for taking rapid sequences of photos. Apple bought the company or the rights so they could include it themselves.
Software is only easier to write than read if you have an idea what it's supposed to do. If you've ever googled "how do I do X?", then you likely have reverse engineered the answer you found to fit your particular use case.
In addition, and in some countries, you can't patent software (thankfully), and so innovation comes through reverse engineering naturally.
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".
Apple often uses immature frameworks internally - like the extensions framework - to to polish them or to dog food them before making them official.
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.
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.
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.
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.
Exactly!
Apple has always been adamant that they see _all_ code that goes onto devices. Live patching is so bloody obvious against their EULA.