Comparison between Corona, Phonegap, Titanium

Question

I am a web developer and I want to move my web products to iPhone. One of the products is like Google Maps: show map on the phone screen, you can drag or resize the map and view some information that we add to the map.

I know there are some technologies that enables you to use HTML, CSS and Javascript to develop native iPhone apps. I've identified a few:

• Ansca Mobile
• PhoneGap
• Appcelerator

Are there other, similar products? What are the differences between them? Which should I choose?

Answer 1

The Corona SDK (Ansca Mobile) uses Lua as its coding language. See lua.org for more about Lua.

While we plan to add further web integration and native-UI elements, our focus will tend to be on graphics-intensive applications, such as game development, as opposed to web-based technologies. In other words, we don't envision people writing Corona apps entirely in Javascript/HTML/CSS.

Answer 2

native mapkit is supported in Titanium

Answer 3

From what I've gathered, here are some differences between the two:

• PhoneGap basically generates native wrappers for what are still web apps. It spits out a WhateverYourPlatformIs project, you build it, and deploy. If we're talking about the iPhone (which is where I spend my time), it doesn't seem much different from creating a web app launcher (a shortcut that gets its own Springboard icon, so you can launch it like (like) a native app). The "app" itself is still html/js/etc., and runs inside a hosted browser control. What PhoneGap provides beyond that is a bridge between JavaScript and native device APIs. So, you write JavaScript against PhoneGap APIs, and PhoneGap then makes the appropriate corresponding native call. In that respect, it is different from deploying a plain old web app.

• Titanium source gets compiled down to native bits. That is, your html/js/etc. aren't simply attached to a project and then hosted inside a web browser control - they're turned into native apps. That means, for example, that your app's interface will be composed of native UI components. There are ways of getting native look-and-feel without having a native app, but... well... what a nightmare that usually turns out to be.

The two are similar in that you write all your stuff using typical web technologies (html/js/css/blah blah blah), and that you get access to native functionality through custom JavaScript APIs.

But, again, PhoneGap apps (PhonGapps? I don't know... is that a stupid name? It's easier to say - I know that much) start their lives as web apps and end their lives as web apps. On the iPhone, your html/js/etc. is just executed inside a UIWebView control, and the PhoneGap JavaScript APIs your js calls are routed to native APIs.

Titanium apps become native apps - they're just developed using web dev tech.

What does this actually mean?

1. A Titanium app will look like a "real" app because, ultimately, it is a "real" app.

2. A PhoneGap app will look like a web app being hosted in a browser control because, ultimately, it is a web app being hosted in a browser control.

Which is right for you?

• If you want to write native apps using web dev skills, Titanium is your best bet.

• If you want to write an app using web dev skills that you could realistically deploy to multiple platforms (iPhone, Android, Blackberry, and whatever else they decide to include), and if you want access to a subset of native platform features (GPS, accelerometer, etc.) through a unified JavaScript API, PhoneGap is probably what you want.

You might be asking: Why would I want to write a PhoneGapp (I've decided to use the name) rather than a web app that's hosted on the web? Can't I still access some native device features that way, but also have the convenience of true web deployment rather than forcing the user to download my "native" app and install it?

The answer is: Because you can submit your PhoneGapp to the App Store and charge for it. You also get that launcher icon, which makes it harder for the user to forget about your app (I'm far more likely to forget about a bookmark than an app icon).

You could certainly charge for access to your web-hosted web app, but how many people are really going to go through the process to do that? With the App Store, I pick an app, tap the "Buy" button, enter a password, and I'm done. It installs. Seconds later, I'm using it. If I had to use someone else's one-off mobile web transaction interface, which likely means having to tap out my name, address, phone number, CC number, and other things I don't want to tap out, I almost certainly wouldn't go through with it. Also, I trust Apple - I'm confident Steve Jobs isn't going to log my info and then charge a bunch of naughty magazine subscriptions to my CC for kicks.

Anyway, except for the fact that web dev tech is involved, PhoneGap and Titanium are very different - to the point of being only superficially comparable.

I hate web apps, by the by, and if you read iTunes App Store reviews, users are pretty good at spotting them. I won't name any names, but I have a couple "apps" on my phone that look and run like garbage, and it's because they're web apps that are hosted inside UIWebView instances. If I wanted to use a web app, I'd open Safari and, you know, navigate to one. I bought an iPhone because I want things that are iPhone-y. I have no problem using, say, a snazzy Google web app inside Safari, but I'd feel cheated if Google just snuck a bookmark onto Springboard by presenting a web app as a native one.

Have to go now. My girlfriend has that could-you-please-stop-using-that-computer-for-three-seconds look on her face.

Answer 4

Making HTML5 widgets tha look like iphone widgets is one thing, but making them perform equally well is another matter altogether. Performance of html5 animations (even plain View Transitions), scrolling long lists, responsiveness to gestures feel sticky and jerky. An iPhone user will notice the difference.

There's also some differences in the kinds of gestures that are supported by different devices which results in platform specific code and usability issues as well.

I'll stay with native apps for now I guess.

Answer 5

I've tried corona. It was good until I discovered it doesn't support streaming mp3 audio. So, I stopped right there. I think if I really want to be an iphone app developer I should learn obj c. All I wanted to make an app which has a list of radio stations and you click on them it start playing.

Answer 6

I'm taking a course in Android/iPhone development and we spent 8 weeks with Titanium (not full time) (Version was Titanium 1.4.2 and time was around November 2010). Here is my experience.

iPhone Android dual targetting

Even though the API guides claim that the functionality is available for both the Android and iPhone, this is not the case. Much of the stuff simply don't work on one of the platforms. Some things works differently.

A lot of the people in the class has done iPhone applications, and they can not make them work on Android without major rewrites. I developed a simple childrens app called Animap (see android market / Appstore in Sweden) and started developing under Windows. Once the Android target was working I opened the project on OS X. It does not show any build stuff for iPhone, just for Android. You need to start a dual target project under OS X. (Ok, I copied the relevant files to a new project). Next problem - the animations does not work on iPhone (they work on Android). The scrolling events does not work the same on the iPhone. (i.e on Android you get the untouch event when user stops scrolling and releases their finger from the screen, this does not happen on the iPhone).

Since this is not mentioned somewhere you basicly need to do trial and error programming on first one platform, then on the other platform. By trial and error I mean it will take about two days to get such a simple App as Animap working on the other platform. You will also need to have if (android) then... or if(iphone)... all over your code...

Download and setup

You must follow the instructions to the letter. Do not try to use java 64 bit. It will not compile the KitchenSink 1.4.0 demo application. (1.3 works OK!) You must put files directly on the C drive as long pathnames will make the external program not receiving all command line parameters if they get to long. (Fine for small programs though) 1/3 of the times, the toolchain simply stops and you must press 'launch' again. Then it will probably work... very unreliable. The simulator will not be found on startup and then you must simply kill of adb.exe with Ctrl+Alt+Delete and retry.

Network connection

On a wifi-network you sometimes looses the live connection and Titanium crashes on you (the compile/deploy interface) If you do not have a working internet connection it will not start as it can not log you in to their servers.

API

CSS, HTML and jQuery is a breeze compared to this. Titanium resembles any other old GUI API, and you need to set some properties for every single button/field/etc. Getting a field wrong is just to easy, remembering all the properties that needs to be set? Did you spell it with capital letters at the right place? (as this is not caught by the compiler, but will be seen as a runtime error if you are lucky to test that part)

In Titanium things simply break when you add another view on top of a control or click somewhere else in the GUI.

Documentation

Several API pages carry the Android symbol, but will only return a null when you try to create the control. They are not simply available on the Android platform despite the symbols. Sometimes Android is mention to not support a particular method, but then the whole API is missing.

KitchenSink

The demo application. Did I mention it does not compile if you put it in your Eclipse project folder because the path gets too long? Must be put on your C drive in the root folder. I currently use a symbolik link (mklink /J ...)

Undocumented methods

You must propably use things as label.setText('Hello World') to change a label reliable but this is not documented at all.

Debugging

Titanium.API.info('Printouts are the only way to debug');

Editing

The APIs are not available in any good format so you can not get ordinary code-completion with help etc. in Eclipse. Aptana please help out!

Hardware

It seems that the compiler/tools are not multithreaded so a fast computer with a fast harddrive is a must, as you must do a lot of trial & error. Did I mention the poor documentation? You must try out everything there as you can't trust it!

Some positive things

• Open Source

• From previous projects I have promised myself never ever to use closed source again as you can't simply fix things just by throwing hours and manpower at it. Important when you are late in the project and need to deliver for a hard deadline. This is open source and I have been able to see why the tool chain breaks and actually fix it as well.

• Bugdatabase

• It's also open. You can simply see that your not alone and do a workaround instead of another 4 hours spent on trial&error.

• Community

• Seems to be active on their forums.

Bugs

• Titanium 1.4 is not threadsafe. That means if you make use of threads (use the url: property in a createWindow call) and program like the threads are working and send events with data back and forth you run into a lot of very, very strange stuff - lost handlers, lost windows, too many events, too few events, etc. etc. This is all dependent on the timing, putting the rows of code in different order might crash or heal your application. Adding a window in another file.js breaks your app.js execution... This also trashes internal datastructures in Titanium, as they sometimes can update internal datastructures in paralell, overwriting a just changed value with something else.

Much of the problems I have had with Titanium comes from my background on realtime systems like OSE who support hundreds of threads, events and message passing. This is supposed to work in Titanium 1.4 but it simply doesn't do it reliably.

• Javascript (which is new to me) dies silently on runtime errors. This also means that small and common bugs, like misspelling a variable name or reading in a null-pointer does not crash when it should so you can debug it. Instead parts of your program just stop working, for instance an eventhandler, because you misplaced/misstyped a character.

• Then we have more simple bugs in Titanium, like some parameters not working in the functions (which is quite common on the Android platform at least).

• Trial and Error debug cycle speed Having run Titnium Developer on several computers, I noticed that the bottleneck is the harddrive. An SSD drive on a laptop makes the build cycle about 3-5 times faster than on a 4200 rpm drive. On a desktop, having dual drives in RAID 1 (striping mode) makes the build about 25 percent faster than on a single drive with a somewhat faster CPU and it also beats the SSD drive laptop.

Summary

• From the comments in this thread there seems to be a fight for the number of platforms a tool like this can deliver app's for. The number of API seems to be the key selling-point.

This shines through very much when you start using it. If you look at the open bugtracker you see that the number of bugs keeps increasing faster than the number of fixed bugs. This is usually a sign that the developers keep adding more functionality, rather than concentrating on getting the number of bugs down.

As a consultant trying to deliver rather simple apps to multiplatforms for a customer - I'm not sure this is actually faster than doing native app development on two platforms. This is due to the fact that when you are up to speed you are fast with Titanium, but then suddenly you look down and find yourself in a hole so deep you don't know how many hours must be spent for a workaround. You can simply NOT promise a certain functionality for a certain deadline/time/cost.

About myself: Been using Python for two years with wxPython. (that GUI is inconsitent, but never breaks like this. It might be me that have not understood the threading model used by Javascript and Titanium, but I am not alone according to their open discussion forums, GUI objects are suddenly using the wrong context/not updating..???) before that I have a background in C and ASM programming for mobile devices.

[edit - added part with bugs and not being thread safe] [Edit - now having worked with it for a month+, mostly on PC but some on OS X as well. Added iPhone and Android dual targetting. Added Trial and Error debug cycle speed.]