What is the state of non-Objective-C programming for iPhone?

Question

After spending three weeks learning Objective-C and Cocoa programming for my work, I\'ve been tasked with researching alternatives to it for iPhone development.

I kn

Answer 1

There are four applications currently in the App Store that are written entirely in Squeak Smalltalk (and the Seaside platform above it), using the VM created by John McIntosh (name completely coincidental).

Answer 2

There's an attempt to get the functional language Haskell (compiled or interpreted) on the iPhone, but it doesn't seem to move very fast...

http://www.haskell.org/haskellwiki/IPhone

Answer 3

Although using C# and Java on the Iphone will make someone with a background in those languages feel more confortable, I'd still stick to ObjectiveC.
In the beginning it'll seem easier to use C# or Java but will may be harder later on. For instance, what if Apple decides to modify the cocoatouch framework in the future? You'll have to depend on monotouch implementing all those changes and in fact will be lagging behind on the guys who are using ObjectiveC.
Even when Apple does keep things as they are, it'll still be possible you'll run in quirkinesses of the Mono stack and will have to jump through hoops to get things done.

Answer 4

If you are simply looking at a direct port, step back and ask yourself if you really want to make your product that mediocre. For any platform you have an application for, you should ship the strongest app possible for that platform - and mobile applications are small enough that it's not so big a hardship that you have separate codebases for a few platforms.

Answer 5

As someone who was given early access to the native iPhone application export in Flash CS5, I hope I can provide a little bit of information about it. For the record, one of my games created with this technology was featured at the Adobe MAX 2009 conference, so it is publicly known that I've worked with it, and I'm not breaking NDA by talking about my experiences as long as I stick to what Adobe has already disclosed.

First, let me make one important point. In many cases, Flash may not be the right technology for what you want to build. For instance, 3D games and applications that should use native UIKit controls are better off if they're developed with with Objective-C or other languages that have access to full native capabilities and libraries of the device. For the right type of experience, and the properly-skilled developer, Flash may be a good choice.

As one should expect, there is a big difference in CPU capabilities between desktop and mobile. Thankfully, in the conversion process, ActionScript 3 goes through an LLVM-powered compiler to be optimized ahead of time as native ARM assembly for the iPhone. As a result, code performance doesn't suffer too greatly, if at all. The majority of my code from existing projects I'm porting to mobile remains unchanged. Mainly, I have to redesign visual content to fit on the device and focus on bottlenecks in Flash's software renderer. Even on the desktop, the renderer is probably the main wall developers run into when pushing the capabilities of Flash Player.

Thankfully, one thing Adobe engineers are finally exploring is hardware acceleration (actually, video is accelerated in the desktop plugin, but only in certain specific situations). For example, as long as a display object stays static, it can be marked to be cached as a surface and drawn to the screen very fast because it is kept in graphics memory. Other interesting optimizations can be made to speed up visual content too, like using bitmaps to replace display objects that have filters (drop shadows, glows, and other stuff like that). This sort of thing can improve performance on the desktop too, but lazy developers don't always do what's best when it looks "good enough" on their own machines. Some of my colleagues find this sort of workflow change unacceptable, but I consider it both a wakeup call about how lazy some of us have become and an obvious requirement of moving to a more limited platform.

Answer 6

Regarding the flash compiler there could be a couple issues there:

• The compiled binary bundles all its resources into the compiled application, whereas with XCode the compiled binary bundles everything as individual files. This may cost you space-wise, as there are compression techniques Apple uses on some resources (PNG, etc.) to get smaller binaries out the other side. What is more, any resource-handling optimizations availed by the operating system will not be available to the resources in the flash binary.
• There has been some discussion as to the acceptability of flash-compiled iPhone binaries. Adobe's take is that they're legitimate binaries and do not violate iPhone application binary rules, terms of service, etc. Apple is not well known for playing the benevolent dictator in the App Store when it comes to applications that make them nervous. Until it has proven to be an accepted method by Apple, caveat builder.