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.
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:
ReplyDeleteFrameworks. 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: September 2010 New iOS terms of use embraces third party development, advertising platforms
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.
ReplyDeleteYMMV if you've newer and more powerful kit, but it doesn't bode well.
How about the other built-in language, Javascript?
ReplyDeleteEither 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...
Unity for iPhone is a good platform for non-ObjectiveC development.
ReplyDeletehttp://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.
You will be losing out in several ways by not choosing Objective-C, seeing as how it is the only Apple supported environment.
ReplyDeleteAll 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.
Regarding the flash compiler there could be a couple issues there:
ReplyDeleteThe 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.
Here's my answer as someone who bought MonoTouch and am using it as the basis for all of my iPhone apps.
ReplyDeleteThere 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.
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).
ReplyDeleteI would suggest looking at using a hybrid solution.
ReplyDeleteBecause 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.
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.
ReplyDeleteIn 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.
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.
ReplyDeleteAs 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.
ReplyDeleteFirst, 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.
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?
ReplyDeleteThere's an attempt to get the functional language Haskell (compiled or interpreted) on the iPhone, but it doesn't seem to move very fast...
ReplyDeletehttp://www.haskell.org/haskellwiki/IPhone
There is also the Rhodes framework which is a ruby interpreter allowing you to write Rails style applications with HTML views.
ReplyDeleteI've recently written a blog post with a compilation of frameworks used to create iPhone apps in other languages, which you might find useful:
ReplyDeletehttp://akosma.com/2009/10/29/iphone-apps-without-objective-c/
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.
ReplyDeleteYou 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 ;)