Even without JIT, we're not allowed in. There's a rule against interpreting code too; clearly this is a very flexible rule, as I can't think of a game company that uses any variant of C for in-game scripting, not to mention that we have apps running Squeak. My guess is they'll let you do it as long as you don't let end users do it. Hence, not a security concern.
I am uncertain whether it's presently okay or not okay (it's been both okay and not okay at different times) to reproduce any part of the SDK agreement, so I'll just point at section 3.3.2.
On Thu, Oct 22, 2009 at 8:42 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/10/23 Ronald Spengler ron.spengler@gmail.com:
Yeah Safari has it's own "fast javascript engine." It's treated me well, though I could see Google's money making v8 the king of the Hill for both browsers in the long run.
I grok the technical implications of what you gentlemen are saying. They're real. I wanted to diverge a bit though.
I don't think the technical issues come primarily from a real security perspective: I believe that the biggest barriers to many of the things we want to do (in particular, compile code on the device) stem from Apple's *desire for control of the distribution channel*.
+1 once one can compile own code on their devices, he won't need App Store since then :) And allowing or disallowing native execution for memory page has nothing to do with real security, this is just a myth.
John, I've been wondering: Is this the main reason I cannot purchase your Squeak VM on the App Store? I dig my wiki server, but I'd really really like to be able to Squeak on my phone without voiding the warranty.
-- Best regards, Igor Stasenko AKA sig.