Wow interesting thread you guys! Unfortunately all of the experiments I've done with node and iOS has been with jailbroken devices. Indeed, V8 is the major problem with this, and it seems like there's no way around it, for the reasons Tim already explained.
>From what I understand, libuv works on iOS, cause I've seen pull requests for libuv in the past that addressed iOS problems. So to answer the original question: No, there haven't been any NodObjC apps accepted into the App Store. You could probably do Cydia if you wanted to go down that road, but most people don't. Feel free to poke those guys in the V8 issue thread, but I don't expect much there, when Apple wouldn't let it be put to use anyways. On Sun, Jun 24, 2012 at 10:48 AM, Ted Young <t...@radicaldesigns.org> wrote: > Out of curiosity, when running a UIWebView on iOS, is it running full > WebKit with JIT enabled, etc, or is there something dumbed down about it? > > Ted > > On Jun 23, 2012, at 10:35 PM, Tim Caswell wrote: > > The difference between V8 and most other scripting languages is that V8 > does not have an interpreter. It is JIT only. That means it works by 1. > writing machine code to memory, 2. executing the code. JIT is very fast > and most of the modern scripting engines do it (V8, JSC, SpiderMonkey, > LuaJit, ...). All of these engines (except for V8) also have an > interpreter mode where the machine code is fixed at compile time and it > walks over your script code interpreting it. State is kept using various > data structures like one big state machine simulating a CPU that knows how > to run JavaScript natively. This is slower, but doesn't require using the > same region of memory as both writable and executable. > > On Sat, Jun 23, 2012 at 9:09 PM, Ryan Schmidt > <google-2...@ryandesign.com>wrote: > >> >> On Jun 23, 2012, at 17:13, Jorge wrote: >> >> > On 23/06/2012, at 19:03, Ryan Schmidt wrote: >> >> >> >> On Jun 23, 2012, at 02:37, Jorge wrote: >> >> >> >>> I don't know the answer to your question, but my guess is that many >> of the things that node does won't run/can't be done in a sandbox. I >> believe the experiments with node on iOS so far have always been in >> jailbroken devices. But I may be wrong. >> >> >> >> Certainly, being able to run in a sandbox will be necessary, since >> Apple will not approve apps anymore that don't. I haven't tried it yet, but >> why do you think node won't run in a sandbox? >> > >> > iOS wont't let user code jump into a block of writable (from your app's >> point of view) memory -for security reasons- >> >> That seems reasonable. >> >> >> > and it seems that v8's JIT compiler requires that: >> http://code.google.com/p/v8/issues/detail?id=1312 >> >> Thank you for the link, but I think the discussion goes over my head. It >> talks about mapping executable memory pages, which are concepts I'm pleased >> as a JavaScript developer not to have to know anything about. On the >> surface, I don't understand why the block of memory containing my program >> code should need to be writable. I'm not wanting to change my program code >> as it's running. I'm just wanting to run it. Or are you saying that by >> virtue of being an interpreted language it must be writable? Also, that >> issue was started over a year ago, and has not been touched in six months. >> There is a patch attached to implement some improvement, and there's no >> indication whether it was committed. Maybe something has already changed? >> Or if not, maybe it's time to remind the v8 devs about it? >> >> >> > The Nitro JIT in JavaScriptCore in mobile Safari requires that too, but >> the security measure has been conveniently lifted for that particular app >> :-P >> >> The second article I linked to in my original post mentioned Apple >> relaxing its restrictions on interpreted languages, in recognition of the >> fact that many games use scripting languages like lua. Does lua also run >> code in writable memory? If so, how are they bypassing Apple's requirement? >> And if not, is there something we can learn from how lua is doing that that >> could be applied to improve node / v8? >> >> >> > Also it seems that quite a bunch of the usual posix APIs simply aren't >> there... until you jailbreak it and install the things yourself. >> >> I'm not interested in jailbreaking devices; I'm interesting in creating >> apps users on everyday iOS and OS X devices can install. I'm not familiar >> with how sandboxing works in OS X or iOS. I haven't found out yet how I >> could build a sample sandboxed application to play around with it either. >> What specific POSIX APIs that node needs will be unavailable? >> >> >> > Apple wants you to develop your apps using their cocoa APIs not >> anything else. Soon we are going to suffer similar constraints (sandboxes >> etc) in Mountain Lion too. And finally a day will come when nothing but >> Apple's approved apps (that is: from the mac app store) will run in a >> Mac... "for your security". >> >> I can't speculate on what direction Apple might go with future versions >> of OS X, but concerns like these are precisely why I started this thread. >> In light of the current and potential future security restrictions, how can >> we use node and NodObjC to develop an OS X or iOS app? It's no use to spend >> time developing an app if it can't be distributed to end users. >> >> >> On Jun 23, 2012, at 19:43, Tim Caswell wrote: >> >> > I don't think there is a way to get nodejs using V8 running in an >> app-store friendly format. >> >> Again, why? Is it the same concerns Jorge expressed above? >> >> >> > But I would love to get libuv and some scripting engine running there. >> I may try my luvit project first (luajit + libuv) or luvmonkey >> (spidermonkey + libuv). Another combination would be JSC + libuv. >> >> I'm interested in getting node and NodObjC usable for making OS X and iOS >> apps. The promise of using JavaScript for both server side and client side >> (web and app) programming is very appealing. I simply want nothing less >> than what the NodObjC homepage advertises: "So you can write entire Cocoa >> or iOS GUI applications entirely in NodeJS JavaScript!" >> >> >> >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to nodejs@googlegroups.com >> To unsubscribe from this group, send email to >> nodejs+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
