You may remember me discussing PlayN in previous posts, it’s a Google run cross-platform, open source game library. Previously the most missing feature was iOS support and frankly that feature is still missing, but there is light at the end of the tunnel!
PlayN developer Michael Bayne recently made a post announcing he had successfully got the Peas demo running on an iPhone4. 
Without a doubt this progress is a “very good thing”, as iOS support is easily the most important missing feature of PlayN today.
Michael’s progress:
I got side tracked by trying to get things working on a real device.
The simulator runs the Mono VM in JIT mode (though with various
restrictions in place to ensure that you don’t do anything that’s
incompatible with AOT compilation), but actually doing AOT compilation
enforces substantially more restrictions. I had to "refactor" IKVM to
contain no references whatsoever to System.Reflection.Emit even if
they were never called. I also bumped into a Mono compiler bug and
spent some time digging into the internals of IKVM and mcs (the Mono
compiler) so that I could come up with a work-around and file a
sensible bug report. It turned out to have already been fixed in trunk
(which made my investigations that much more perplexing), but since
MonoTouch is commercial software, I was necessarily working with the
latest beta release, not trunk; annoying!Performance of the Pea Physics demo is not stellar on an iPhone 4
(it’s quite reasonable, it’s just not silky smooth 60 FPS with twenty
or thirty peas moving on screen). It’s pretty comparable to what I’ve
see on actual Android devices. Depending on what Box2D’s interfaces
are like, there’s a possibility that it could be improved by writing
an interface-compatible implementation of Box2D directly in C#. C#
supports value types, and in a physics simulator, being able to store
your Vec2s and Matrix3s directly inline, rather than separately on the
heap, can substantially improve cache performance. That said, the
Box2D implementation, as is, is not very data-oriented. Rewriting it
to store all of the entity geometry in big flat arrays and to perform
its calculations by iterating over those arrays, rather than following
a zillion pointers through the heap, would probably help a lot on
every platform.Now that I’ve got things running on an actual device, I’ll go back to
finishing up the platform implementation. IOSCanvas is substantially
done. IOSStorage is done (built on Sqlite). IOSTouch (and IOSPointer)
are done. I need to implement the font and text rendering bits of
IOSGraphics/IOSCanvas. Then IOSSound, IOSNet and other niggling bits.
I’m not sure what I’ll do about IOSKeyboard. I’d kind of like an
additional interface for requesting a string of text from the user,
which would allow the keyboard to pop up in "edit a line of text" mode
so that the user can use the standard copy/paste and click with
magnification text navigation. Having the app respond to key events
and attempt to implement text entry directly is a massively bad idea
(on any mobile device), IMO.
Excellent news and great work Michael!
So for the people looking to see if PlayN works with iOS, the answer is no, but it’s damned close!