"The JavaScriptCore Framework is still private on iOS. So as it is now, I won't be allowed to distribute the game in the AppStore. But my understanding is, that if I bundle my own copy of the JavaScriptCore Framework (which is part of WebKit and thus freely available) with my game, I should be on the safe side."

This is true. You can compile Javascript Core and include it in your app. I have done this previously as an experiment.

However, there is one HUGE drawback in doing so: no compiled/jitted javascript code is possible.

This is because iOS applications are not allowed to create executable code in the heap or on the stack, so there is no way for JavaScriptCore to compile to native code when it is running as part of a third party application.

So unfortunately there is no good way to get this going at the same speed that you get when linking against the private framework.

Sad. This is also a major problem for other scripting languages. They all can only run in interpreted mode. Which might be good enough but is never the best you can get.

Yep, I hit this roadblock too. For my similar project I ended up using a non-jit version of Spidermonkey for embedded Javascript. Interpreted performance is pretty poor in comparison to jit though, and I ended up moving to a much higher level Javascript API to share between canvas and native implementations. It runs at 60 fps on 2nd gen hardware now with moderate (1 - 2 hundred sprites).

Just thinking out loud:

I wonder how feasible it would be to pre-compile the Javascript to machine code before distributing it? Maybe someone determined enough could probably hack one of the existing JIT engines to emit executable machine code to a file?

For a restricted subset of Javascript it wouldn't be that hard.

I'm not sure that solves the iphone problem though - I don't think it's kosher to use non c/c++/objc code. A Javascript to C compiler would work fine, though. That would be quite a bit more work, though.

[Edit]As pointed out below, it might well be ok. I guess you'd have to somehow get the generated machine code into a static library and link it with your application. That might work.

It's kosher now, as of Apple's recent changes to their developer agreements.

Summary: Technology demo wherein the author takes a Javascript game, runs it as an App (no browser) using OpenGL instead of <canvas> and the Javascript interpreter already in the iPhone for the drawing and gets 60fps.

• The Javascript interpreter interface used is considered private and thus the app can not be distributed in the store.

• There is a history of private to public interface transitions, so perhaps…

• It suggests you could have all the game code be common between a web and a higher performance app version of a game.

• No word in the article about what percent speedup this represents.

The speedup is substantial, at least in this case. Biolab Disaster has to draw lots of small 8x8 pixel squares (about 500 for each frame) to produce the background map - which seems to be awfully slow in the iOS browser.

Running in the browser, I had about 10 frames per second as noted in my previous blog post: http://www.phoboslab.org/log/2010/09/biolab-disaster

You can bundle the JavaScriptCore with your iOS and be legal for the app store, you just can't use the private API.

This sounds like some really, really great stuff. As it is, canvas in Safari/IOS is simply too slow to make any fast action game in JavaScript.

On the homepage of the game, he says that the web version runs with about 12FPS on the iPhone. So he got about 500% speedup by this.

So it sounds like the source code for game is written in pure javascript (utilizing any special APIs calls provided by Impact). This javascript src is packaged using the Impact Game Engine which creates a Obj-C wrapper around the javascript. When the Game is loaded on an iOS device and run, the Obj-C wrapper (implemented by Impact) executes the javascript src via JavascriptCore.

It sounds like this is basically a Canvas to OpenGL translation layer.

Can only the Canvas object be leveraged when creating games/apps with this? Or could a "account creation" screen be created leveraging HTML elements like forms (I would assume not since its sounds like its executed outside of Safari, and the translation provided is from Canvas > OpenGL)

Yah, the original game is all in pure javascript written to the canvas. I have been poking around with making canvas apps and a few weeks ago I grabbed the source and spent a few hours reading through all of it. Good stuff. If the author wasn't in Poland (corporate doesn't have an office there) I would try to hire him.

There's a lot of interest in the mobile and JavaScript communities for a JavaScript engine you can distribute on iOS. Games are one thing, but with this you could take cross-platform, natively packaged web apps to a whole new level.

Sort of like an even more native Titanium Appcelerator? < http://appcelerator.com >

Exactly, or like PhoneGap. For example, you could write an Appcelerator or PhoneGap app and call into native code from a JavaScript bridge. Right now, each native API needs to be explicitly wrapped by Appcelerator or PhoneGap.

Can someone summarize the impact (no pun intended) of this?

Make multimedia software, generally games, for iPhone/iPod Touch/iPad using javascript and html5 canvas and make it run almost as fast as a native version.

It is a native app: it uses JavaScriptCore and all Canvas calls are rendered using OpenGL. The implications are that if you write a game for Impact engine you can generate an iOS native app.

It's not quite that simple, though, from the sound of it - the author said he had to 'reimplement' all the canvas calls to use OGL. Fine if you're familiar with it, but for those people who just want to bash out a Javascript game without having to worry about the engine, they might have trouble.

So far I only reimplemented those Canvas API functions needed for the game; the most important one being .drawImage().

What I mean by "reimplement", is providing a .drawImage function for JavaScript that works in the same way as it does in the browser, but uses OpenGL-ES behind the scenes. This reimplementation is done in native Objective C.

The changes I had to make to Impact (the "HTML5" engine) are concerned with the loading of images, scaling, input and getting a reference to the canvas element and its drawing context. But I guess I could provide a dummy "document" and "getElementById" function, so that you can just write some JavaScript using Canvas and run it in the browser and on the iPhone unchanged.

Note that this whole idea isn't exactly new: http://www.youtube.com/watch?v=0UN2iYrZmEY

From what I understand he only had to re-implement the canvas calls in the game engine. "I of course had to make some changes to the engine, but the game source code is exactly the same as for the web version."

See my comment about not being able to use compiled/jitted javascript from apps because of code execution restrictions set by iOS.