Re:Apple starts rejecting apps with “hot code push” features
by wolfgke on Wednesday March 08, 2017 @07:28AM
(#13819760)
What is "code"? Everybody who has programmed in LISP or Scheme knows that there is no essential distinction between code and data (only many programming languages make it a little hard to see that it is all the same). Thus Apple would have to see not only all code, but also all data that goes onto the devices. But this would imply that Apple disallows all apps that read data from a foreign (i.e. at least not Apple-controlled) server if one does not want to get into a self-contradiction.
[ Parent
| on HN ]
Re:Apple starts rejecting apps with “hot code push” features
by Spivak on Wednesday March 08, 2017 @11:55AM
(#13821493)
Which is why you're not allowed to use a Lisp interpreter or use any method of evaluating data as code. In this model the only thing that data can do is change which code paths run, not what they do.
Re:Apple starts rejecting apps with “hot code push” features
by cortesoft on Wednesday March 08, 2017 @12:42PM
(#13821887)
Changing a code path is the same as changing what they do.
Re:Apple starts rejecting apps with “hot code push” features
by nevir on Wednesday March 08, 2017 @09:24PM
(#13826358)
They do allow things like pushing updated JS bundles to react native apps. My guess: RN constrains the surface area of the native API it comes into contact with (e.g. no performSelector, or similar)
Re:Apple starts rejecting apps with “hot code push” features
by kazinator on Thursday March 09, 2017 @03:38PM
(#13833330)
That characterization isn't enough to distinguish a Turing complete interpreter from something that trivially manipulates an input datum. An interpreter is just a program containing code paths, which are activated in response to the input (the interpreted code).
Re:Apple starts rejecting apps with “hot code push” features
by wolfgke on Friday March 10, 2017 @06:14AM
(#13837773)
> That characterization isn't enough to distinguish a Turing complete interpreter from something that trivially manipulates an input datum. An interpreter is just a program containing code paths, which are activated in response to the input (the interpreted code).
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...
Re:Apple starts rejecting apps with “hot code push” features
by st3v3r on Wednesday March 08, 2017 @12:36PM
(#13821833)
"What is "code"?"
Apple has decided that, and you're not going to get around their policies with a clever rhetorical question.
Re:Apple starts rejecting apps with “hot code push” features
by zodiac on Wednesday March 08, 2017 @08:15PM
(#13825840)
So what is Apple's decision about what code is?
Re:Apple starts rejecting apps with “hot code push” features
by st3v3r on Friday March 10, 2017 @01:36PM
(#13840867)
When it comes to what's run on their platform, yes.
Re:Apple starts rejecting apps with “hot code push” features
by zodiac on Saturday March 11, 2017 @12:16AM
(#13844351)
I didn't ask a yes/no question, I asked what apple's decision was
Re:Apple starts rejecting apps with “hot code push” features
by wolfgke on Wednesday March 08, 2017 @01:41PM
(#13822485)
> "What is "code"?"
> 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.
Re:Apple starts rejecting apps with “hot code push” features
by paddyoloughlin on Wednesday March 08, 2017 @01:44PM
(#13822507)
Apple doesn't need to change mathematical facts, they just don't let you publish on their AppStore.