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 know of two existing alternatives, and one future possibility.

C#

• MonoTouch is a C#.NET implementation with bindings for iPhone specific functionality such as touch screen and accelerometer. It integrates with Xcode and Interface Builder and also allows for custom Objective-C bindings to be made.

Java

• alcheMo-for-iPhone generates C++ code to be compiled for iPhone from J2ME source. It also provides touch screen and accelerometer bindings.

Flash / ActionScript 3

• Adobe has announced that Flash Professional CS5 will allow Flash applications to be deployed for iPhone. No details have been given yet.

I'd like to know if anyone has experience with any of these. Our company is looking into re-using code using these solutions if possible, rather than re-writing the same functionality in Objective-C.

EDIT: I know the drawbacks of not using Objective-C and the provided frameworks. I would like input as to possible solutions from people with experience doing this rather than reasons why Objective-C is better.

Answer 1

I'd be pretty skeptical of non-ObjC languages on the iPhone. Not necessarily because there's some huge technical hurdle to be surmounted (you can compile pretty much whatever you want down to the iPhone, and even get it to run with some tweaking), but for two other important reasons:

• Frameworks. While the things you listed have touch screen and accelerometer bindings, you'll most likely be missing things like Bluetooth connectivity and the Game Kit, audio frameworks, In-App Purchase, and the like. It'd be pretty difficult to reproduce everything Apple offers in another language, and if you choose a different way and then wind up needing one of those frameworks you may be stuck.
• App submission. If you want to get apps on the App Store, you should probably stick with ObjC. Apple is notoriously picky about what they allow through, and using a different language might strike some reviewer the wrong way.

You'll also have a lot more trouble with things like code signing/certificates, not to mention debugging (it struck me as strange that MonoTouch is advertising debugging as a feature, rather than something that's kind of taken for granted within the language).

All in all, I'd stick with ObjC if you can. It's generally just easier for all concerned.

Update: as of the latest Terms of Service, Apple has banned applications not originally written in one of the Objective-C family of languages (C, C++, ObjC++).

Answer 2

MonoTouch looks good, but it's excruciatingly slow. I've been playing around with XCode on my last generation MacBook for a while (ca 2007) and it's quick and responsive. I downloaded MonoTouch last week as I'd like to convert an existing large Mono codebase to run on the iPhone and whilst it installs and runs fine, using it is painful in the extreme as everything in the IDE is sludgy and unresponsive.

YMMV if you've newer and more powerful kit, but it doesn't bode well.

Answer 3

Unity for iPhone is a good platform for non-ObjectiveC development.

http://unity3d.com/unity/features/iphone-publishing

It is for more than just games, and if you need .NET or other script language support this may be a good way to go.

IMHO: MonoTouch is more work than a good IB + ObjectiveC stack, even with some of the learning overhead of ObjectiveC.

Answer 4

You will be losing out in several ways by not choosing Objective-C, seeing as how it is the only Apple supported environment.

All of Apple's docs, sample code, tool chain etc. assume you're using Objective-C. You won't really be able to use your code level support incidents. Any new framework will have to be wrapped for your environment, which also introduces a new source for bugs.

To me, using something other than Objective-C for the iPhone would be opening up a big bag of hurt.

Answer 5

I've also looked for alternatives to Objective-C because writing it for me is simply not productive. I'm currently looking into XMLVM (http://xmlvm.org/overview/) as a way to write Java which then becomes Objective-C source code. There are many nice things about this solution but the biggest in my opinion is that it produces Objective-C source code so you are not prevented from attaching your core application to APIs which have not yet been mapped using XMLVM. My intention is to write the core of my applications in Java which is then portable to IPhone and Android, then add platform specific functionality on top of that in either Objective-C or Android-Java.

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.

Answer 7

I would suggest looking at using a hybrid solution.

Because of Objective-c's flexibility, you can implement your interface in Objective-c and your data model in almost anything else. You can practically draw the interface using Interface Builder so your actual coding in Objective-c is minimal. The real challenging parts of most serious applications are in the data model and that is where you are most likely to have legacy code or code from other projects.

As noted here by others, there are many libraries that allow you to glue almost any major language/API into Objective-c.

Answer 8

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 9

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 10

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 11

Objective-C and Cocoa are better for one reason: because that's what Apple wants you to use on the platform. The iPhone approval process is way too black of a box to start messing around with non-endorsed frameworks and tools. Who's to say Apple won't devise a way to see who is building apps with Mono and just rejects them all?

Answer 12

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 13

How about the other built-in language, Javascript?

Either you can run a web application inside a UIWebView, or you can use a hidden UIWebView to run pieces of Javascript code and examine their return values to drive your native application.

An advantage over third-party languages and frameworks is that the Apple dev license clearly allows you to download and run javascript programs (as you use their official API to do that).

Just found this Xcode plug-in that offers HTML&Javascript development of native-looking apps: Nimble Kit. May be worth a look...

Answer 14

Here's my answer as someone who bought MonoTouch and am using it as the basis for all of my iPhone apps.

There are no shortcuts. You need to know Objective-C and CocoaTouch before you even consider something else. You can't grab MonoTouch and start coding for the phone without any knowledge of the native stuff, it just isn't going to happen.

MonoTouch is easy enough to extend/alter as needed, if you already know CocoaTouch and ObjC well enough. So the idea that the native frameworks could change leaving you in the dust isn't that relevant.

I have found in my experience that MonoTouch apps are slower than their native counterparts, but not enough to matter. If it does matter, you can always write that part of the app with native code, and it's possible ObjC wouldn't be fast enough anyway and you'd want to drop to pure C even in a native app.

MonoTouch has netted me some serious productivity gains, from being able to use a far less terse and chatty language to being able to use libraries like Rhino Mocks and NUnit out of the box.

MonoDevelop is a great IDE in theory. It's also far superior to xcode, in theory. It's lightweight, simple, very easy to use, excellent intellisense and macros, and makes managing an iPhone project far easier than xcode. But ... it's really buggy. That is it's true downfall right now.

Answer 15

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 16

There is also the Rhodes framework which is a ruby interpreter allowing you to write Rails style applications with HTML views.

Answer 17

I've recently written a blog post with a compilation of frameworks used to create iPhone apps in other languages, which you might find useful:

http://akosma.com/2009/10/29/iphone-apps-without-objective-c/

Answer 18

A web app is also a very good alternative if you want to make an app for your web site. A lot of hardware is exposed through some of the up-coming HTML5-APIs, and PhoneGap exposes some more for you.

You can avoid the Apple approval process if you want by only hosting it on the web, or you can add it to the App Store by using UIWebView to load your web app. PhoneGap can help you with this also.

There is another question that specifically asks about web application frameworks for iPhone, that lists a lot of good alternative frameworks: Available iPhone Web Application JavaScript UI Library/Frameworks

Since JavaScript is interpreted by WebKit natively on the iPhone, Apple also approves these apps (depending on quality). The browser on iPhone is one of the best browsers on a mobile handset right now, but they're not the only one. With a little extra work you can make your web app also work on multiple plattforms. Peter-Paul Koch has done a lot of research on the state of the browsers, and also regularly blogs about web development for mobile devices. Check out his scientific results on mobile browsers or read some of his rant (funny and informative): http://www.quirksmode.org/mobile/

I also like Jonathan Stark's book Building iPhone Apps with HTML, CSS, and JavaScript

You can even make the app available offline with the help of a manifest file: Safari reference - HTML 5 Offline Application Cache. This is also further described in Jonathan Stark's book so you automatically modify the manifest when a resource is changed. Since the browser downloads all resources specified in the manifest file, it could be compared with updating the app in the App Store. Except it's instant and no approval process ;)