This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Write once deploy on Windows Mobile 6, Windows Phone 7, Android and iPhone?
Currently I have created a 2 simple apps for iphone and 1 for windows phone. When I go to promote these apps they usually....well do you have this for android or blackberry or whatever.
Do I have to rewrite my applications in every environment in order to have them compatible across all the operating systems out there? Is there tools that address this or do you guys simply recreate the app in eclipse, xcode, visual studio etc..?
Complex applications generally need to be created with the native environment.
Simple applications can be created with cross platform tools like Titanium and PhoneGap:
- http://www.appcelerator.com/
- http://www.phonegap.com/
#Fraggle (see comment)
I have quite some experience with Appcelerator Titanium. The choice for native v.s. cross-plafrom completely depends on the kind of application you need and your knowledge. General considerations:
Can the application be created with web technologies like HTML, CSS and JavaScript?
What language / environment do I know the best (native vs web technologies)?
How much time and money can I spend?
Do I really need cross-platform compatibility?
Most mobile phone applications only provide an easy interface for internet services like news updates, traffic info, social media and video. Those applications can be easily written with web technologies. Therefor most mobile applications can be written with tools like Titanium. The great thing about Titanium: Get the native experience on multiple devices while only maintaining one code-base. Cheap way of developing cross-platform applications.
Many developers use Titanium because they don't know the native language (objective-C / java), but they have extensive knowledge about web technologies. This way they can create pretty nice applications without learning new languages. Titanium is actually used for many non-cross-platform applications.
Complex graphics, device specific tools and complex interfaces still require the native environment.
Native applications will always perform better and use device specific features, but do you really need that degree of perfection? Yes, develop native applications for every device. No, simply create one cross-platform application.
Check this page to see what Titanium can do:
http://www.appcelerator.com/showcase/applications-showcase/
You may be able to use a third party tool like http://www.phonegap.com.
There are many options for cross-platform app development, but I would suggest Adobe AIR as it is also supported on the Blackberry Playbook by RIM. As far as I know, it's the only cross-platform runtime that is supported by a major platform owner.
I have also seen it do well on Android, and iOS support is also advertized.
Well there are definitely some supposed "write once, run everwhere" solutions out there. Here is one from RhoMobile which specializes in this space. But that is just what a quick Google search turned up. I haven't tried any of them.
I had an app that was developed for Android, and I ended up essentially re-writing it in Objective-C when I wanted to port it over to iPhone. It worked out pretty well and took less time than I thought (considering I hadn't done any iPhone programming prior). But now of course I have 2 code bases that I have to maintain and when I add features I'll have to do it for both the Android and iPhone version.
So having a single code base that lets me build apps for multiple platforms would be great. Do any of the tools out there work well? Not sure. Do they give you full control to make your app look and operate the way you want it, and make us of all the OS's features? Not sure.
Qt (now owned by Nokia) is another provider of a cross platform mobile framework
http://qt.nokia.com/
Even though iphone and android seem to be missing from their official Supported Platforms list I think there is an Android 2.3 release just around the corner. Qt for Iphone also seems to be in the works.
HTML5 may be one solution if the app you providing is simple enough. Google is doing it this way. Otherwise, even you have anything "cross-phone" it may still feels alien.
A friend of mine told me that some frameworks (PhoneGap and/or QuickConnect) can transform my HTML/JS/CSS code to an iOS App.
Personally, I hate this kind of frameworks because when you get a bug, it's very hard to debug. But, on the other hand, as i'm starting learning iOS programming, I find Objective-C hard to learn.
Did anyone tried these tools? What are their limits? What about performances?
Thank you,
Regards.
These frameworks are handy if you are coming from web development world. Since they allow you to develop using HTML/CSS/Js you'll be able to get going quite rapidly.
Even though they offer more interaction with the native capabilities of the device (contacts, camera, accelerometer, etc.) than pure web development (using Sencha Touch or jQuery Mobile for example) they are still more limited than a native application.
Webkit
Most of these solution are focused on devices using a WebKit based browser for the rendering. Which is used by many of the main mobile OS :
Symbian, iOS, Android, BlackBerry, Bada, etc.
Main exception being Windows Phone which uses Internet Explorer
Cross-platform
Their goal is to enable cross-platform development ever by wrapping your web development into a native app (PhoneGap, Titanium) or by "translating" to the appropriate language for the targeted device (RhoMobile Rhodes, MoSync).
iPhone specific
Aiming several platforms implies that some phone specific features might not be so easily supported. And the UI won't look as native since it's targeting different OS. So if you are only aiming iOS4 you could maybe try some of the more specific solutions such as:
iWebKit
Ansca Corona
Performances
For standard apps you should'nt notice much difference. But if you are planning to develop games some of these frameworks are probably not the best solution. Corona claims to be appropriate...
Caution
If you plan to develop a commercial application beware of Apple's policy.
Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine
Many applications using these tools/frameworks are still accepted but there is nothing official.
Edit: As stated by Rydell the policy has changed since September 9.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd like to start developing for iPhone or Android in my spare time, as a chance to learn something new but also hoping make some extra income.
I'm not sure which is the best development for me to start developing on. I own an iPhone, but I don't have a Mac (which I would need to use the SDK), plus with the iPhone I believe there's an annual charge to develop for it.
As far as I understand Android, the SDK is free and can be used on Windows.
Professionally I develop using .net and C#, which sounds more similar to the Java based Android enviroment.
Another negative I perceive against iPhone is it has a much more crowded App Store, I would think apps get better exposure on Android?
Both can be good/bad for various reasons.
iPhone - good
Great SDK & get to use Xcode which rocks
Well documented online (many tutorials)
Large deployed base of devices
Well established app store
Get to learn Objective (I find it a fun language)
Most people tend to upgrade their iPhone OS so you can get away with only developing for the latest and greatest
iPhone - bad
Crowded app store, very hard to break through (the "gold mine" is a myth)
App Store apps need to be approved by Apple, with some often rejected for dubious reasons
Have to buy a Mac (not necessarily a bad thing)
Have to learn Objective C (can be a hassle)
Have to pay $99/year to publish apps
Can only multitask on iPhone 4.0+. Hardware restrictions will mean many devices will not be able to use this however
Android - good
No restrictions on apps that you can develop/publish
Wide deployment of devices and growing - set to overtake iPhone soon
Can multitask on Android
Get to code in Java which is widely known
Some of the SDK tools integration with Eclipse is nice (although still needs a bit more work)
Only have to pay $25 to publish apps (one off fee)
Can develop on any platform (Mac/Windows/Linux)
Great Android devices coming out this year - platform could really take off.
Nice XML way of laying out views. While not as flash-looking as the iPhone Interface Builder, it is very powerful.
Get to work in Eclipse (which some people think rocks)
Android - bad
Have to support wide variety of screen sizes and devices
Many people still using old versions of Android OS (1.5) so you'll probably have to support those if you want to reach that market
SDK is not as polished as iPhone SDK
Android Market is not as popular as iPhone App Store - hit apps will not make as much $$$
All in all, starting with whichever is fine in my opinion, especially as now Android is gaining ground. Given your background I'd say you should go for Android.
In my honest opinion - I see the recent changes in iPhone SDK a kick in the teeth. I'm an Adobe person and you would assume, an infinite number of developers begin building applications in CS5 would be great for you App Store? Apparently Apple do not agree.
However - if your looking for exposure, getting an App into the App Store will yield more results if you build a quality app. As the Android store hasn't got a footing yet (if they'll ever be one), all marketing is on your own head.
I recently defunct Apple as they force us developers to 'be them' and I don't agree with their ethos.
That said, having programmed for both, The Android is slightly tricker to get installed and took a very long time to sort itself out. Although the instructions are very good and the examples are well defined.
If you've got a mac, installing the iPhone SDK is a sinch and you ready to build apps. It does cost £50 for the developer connection and yes android is free. [Correction - this may cost a one of fee of $25]
If you are building an iPhone app thats heading for the wild, you will need the connection (this can take up to 3 weeks in my experience) so you can test it on your iPhone.
And you'll definitely need to purchase a Mac.
--
With Android, its java, and with the newest rendition, a very good API to work with. As an additional bonus its build upon Eclipse, so it'll take you seconds to understand whats going on.
--
As a final thought - being an Actionscript/JS developer, the transition to Java was a logical and simple step and (please don't shoot me if you don't agree) Objective C is a train wreck of two different language styles. I found it very very difficult.
but don't just take my word for it, definitely try them both, as I see Android emerging market just an ice berg right now, but Apples is established.
Two disadvantages of iPhone/iPad apps ecosystem are:
Apple test & accept apps before puts them into AppStore (this take time and acceptance depends on Apple current policy) -- Google seem not to care about that so much.
AppStore it's the only official place for iPhone apps -- on Android you can install apps from unsafe source (i.e. website or email attachment) -- so you can provide and charge for app in various ways.
You say you want to (a) learn something new and (b) make some extra income.
As far as (a) goes, your barriers to entry with Android are probably lower. You can develop on Windows, Linux, or Mac; the sdk is free, and there are no charges. Android development is usually done in Java, which is not that different to the c# you already know. So, I'd say get Reto Maier's book and give Android a try. At some point you'll need an Android phone, but you can get some way using the emulator. You won't have to buy a mac or pay for a developer licence.
Once you're familiar with developing for a mobile platform you'll have a better idea of what it takes to build apps that other people will want to use, and maybe even pay for. At that point you can evaluate the platforms from the point-of-view of (b) and decide which one to pursue. If you end-up buying a mac and paying for a development licence then at least you'll be making an informed decision. But get some experience first.
Like you, I'm a c# dev. I've done some Android development for my own amusement, and (for what its worth) my personal opinion is that its a superior platform in comparison to the iphone because it is more open (technologically and commercially). I believe Android will fairly soon either achieve partity with, or even overtake, the iphone.
Try Android, get some mobile experience, then decide.
MonoDroid for Android is in beta, which means you'll be able to write Android apps with C#. You can sign up for the beta here.
iPhones are getting more and more restrictive. Android is opening up. Android is also shipping more phones than iPhone. You decide.
take a look at this book , it's a good reference to decide the 3th way... HTML, javascript & CSS for iPhone and Android at same time, based on webkit, using jQTouch and
PhoneGap . You can see on the first chapter the pros and cons.
I would suggest getting your hands on the latest iPhone SDK and a Mac from a friend before taking the plunge unless the $600 minimum investment for a macmini(what I did in my case) doesn't bother you.
You could try installing GNUstep for Windows and messing with Objective-C without buying a Mac to check out the language but it's not the same without XCode and Interface Builder,SDK,etc.
The reason I say this is because I'm currently taking an iPhone class and just learning Objective-C is a lot larger learning curve than I thought it would be and eating up a lot more of my time than I cared for.
Unlike C# or Java you have to manually keep track of memory management which is really annoying and a hassle not to mention Cocoa Touch, which is sort of like .Net or Java classes for Objective-C; another big learning curve! Bottom line neglecting the fact that it is a mix of SmallTalk and C and looks horrible if you can get over that it is still hard and easy to crash your program.
Forget to hook up your outlooks correctly in Inteface Builder?
CRASH!
Forget to use an # for an NSSTring due to the loose type checking?
CRASH!
I'm just saying that you'd probably be more productive and actually get applications completed in your spare time going the Android more familiar Java language route vs the Apple route. Also, I'm not sure how big Android is on the whole MVC concept, but it's everywhere in the iPhone SDK since Cocoa uses the Model-View-Controller (MVC) design pattern throughout.
On the other hand, if you like a challenge or learning the Apple route is the way to go and if you are good you app will sell and you will make money. Like I said there is a ton to learn with the iPhone before you can even start thinking of selling the next killer app LOL.
p.s. Oh and unless you want to test something on actual hardware that doesn't work in the iPhone/iPad simulator or actually upload an app to the store you don't need to pay the $99 fee to develop.
If you're a C# developer, and you're looking to begin iOS development, then you owe it to yourself to read Josh Smith's iOS Programming for .NET Developers.
It's exactly what you're looking for.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
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?
I registered with stackoverflow just for the purpose of commenting on the mostly voted answer on top. The bad thing is stackoverflow does not allow new members to post comments. So I have to make this comment more look like an answer.
Rory Blyth's answer contains some valid points about the two javascript mobile frameworks. However, his key points are incorrect. The truth is that Titanium and PhoneGap are more similar than different. They both expose mobile phone functions through a set of javascript APIs, and the application's logic (html, css, javascript) runs inside a native WebView control.
PhoneGap is not just a native wrapper of a web app. Through the PhoneGap javascript APIs, the "web app" has access to the mobile phone functions such as Geolocation, Accelerometer Camera, Contacts, Database, File system, etc. Basically any function that the mobile phone SDK provides can be "bridged" to the javascript world. On the other hand, a normal web app that runs on the mobile web browser does not have access to most of these functions (security being the primary reason). Therefore, a PhoneGap app is more of a mobile app than a web app. You can certainly use PhoneGap to wrap a web app that does not use any PhoneGap APIs at all, but that is not what PhoneGap was created for.
Titanium does NOT compile your html, css or javascript code into "native bits". They are packaged as resources to the executable bundle, much like an embedded image file. When the application runs, these resources are loaded into a UIWebView control and run there (as javascript, not native bits, of course). There is no such thing as a javascript-to-native-code (or to-objective-c) compiler. This is done the same way in PhoneGap as well. From architectural standpoint, these two frameworks are very similar.
Now, are they any different? Yes. First, Titanium appears to be more feature rich than PhoneGap by bridging more mobile phone functions to javascript. Most noticeably, PhoneGap does not expose many (if any) native UI components to javascript. Titanium, on the other hand, has a comprehensive UI APIs that can be called in javascript to create and control all kinds of native UI controls. Utilizaing these UI APIs, a Titanium app can look more "native" than a PhoneGap app. Second, PhoneGap supports more mobile phone platforms than Titanium does. PhoneGap APIs are more generic and can be used on different platforms such as iPhone, Android, Blackberry, Symbian, etc. Titanium is primarily targeting iPhone and Android at least for now. Some of its APIs are platform specific (like the iPhone UI APIs). The use of these APIs will reduce the cross-platform capability of your application.
So, if your concern for your app is to make it more "native" looking, Titanium is a better choice. If you want to be able to "port" your app to another platform more easily, PhoneGap will be better.
Updated 8/13/2010:
Link to a Titanium employee's answer to Mickey's question.
Updated 12/04/2010:
I decided to give this post an annual review to keep its information current. Many things have changes in a year that made some of the information in the initial post outdated.
The biggest change came from Titanium. Earlier this year, Appcelerator released Titanium 1.0, which departed drastically from its previous versions from the architectural standpoint. In 1.0, the UIWebView control is no longer in use. Instead, you call Titanium APIs for any UI functions. This change means a couple things:
Your app UI becomes completely native. There is no more web UI in your app since the native Titanium APIs take over control of all your UI needs. Titanium deserves a lot of credit by pioneering on the "Cross-Platform Native UI" frontier. It gives programmers who prefer the look and feel of native UI but dislike the official programming language an alternative.
You won't be able to use HTML or CSS in your app, as the web view is gone. (Note: you can still create web view in Titanium. But there are few Titanium features that you can take advantage of in the web view.)Titanium Q&A: What happened to HTML & CSS?
You won't be able to use popular JS libraries such as JQuery that assume the existence of an DOM object. You continue to use JavaScript as your coding language. But that is pretty much the only web technology you can utilize if you come to Titanium 1.0 as a web programmer.
Titanium video: What is new in Titanium 1.0.
Now, does Titanium 1.0 compile your JavaScript into "native bits"? No. Appcelerator finally came clean on this issue with this developer blog:Titanium Guides Project: JS Environment. We programmers are more genuine people than those in the Marketing department, aren't we? :-)
Move on to PhoneGap. There are not many new things to say about PhoneGap. My perception is that PhoneGap development was not very active until IBM jumped on board later this year. Some people even argued that IBM is contributing more code to PhoneGap than Nitobi is. That being true or not, it is good to know that PhoneGap is being active developed.
PhoneGap continues to base itself on web technologies, namely HTML, CSS and JavaScript. It does not look like PhoneGap has any plan to bridge native UI features to JavaScript as Titanium is doing. While Web UI still lags behind native UI on performance and native look and feel, such gap is being rapidly closed. There are two trends in web technologies that ensure bright feature to mobile web UI in terms of performance:
JavaScript engine moving from an interpreter to a virtual machine. JavaScript is JIT compiled into native code for faster execution. Safari JS engine: SquirrelFish Extreme
Web page rendering moving from relying on CPU to using GPU acceleration. Graphic intensive tasks such as page transition and 3D animation become a lot smoother with the help of hardware acceleration. GPU Accelerated Compositing in Chrome
Such improvements that are originated from desktop browsers are being delivered to mobile browsers quickly. In fact, since iOS 3.2 and Android 2.0, the mobile web view control has become much more performing and HTML5 friendly. The future of mobile web is so promising that it has attracted a big kid to town: JQuery has recently announced its mobile web framework. With JQuery Mobile providing UI gadgets, and PhoneGap providing phone features, they two combined creates a perfect mobile web platform in my opinion.
I should also mention Sencha Touch as another mobile web UI gadget framework. Sencha Touch version 1.0 was recently released under a dual licensing model that includes GPLv3. Sencha Touch works well with PhoneGap just as JQuery Mobile does.
If you are a GWT programmer(like me), you may want to check out GWT Mobile, an open source project for creating mobile web apps with GWT. It includes a PhoneGap GWT wrapper that enables the use of PhoneGap in GWT.
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?
A Titanium app will look like a "real" app because, ultimately, it is a "real" app.
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.
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.]
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.
I have been working with Titanium for over a week now and feel like I have a good feel about its weakness.
1) If you hoping you use the same code on multiple platforms good luck! You'll see something like backgroundGradient and be amazed until you find out android version doesn't support it. Then have to revert to using a gradient image, might as well use it for both versions to make the code easier right?
2) A lot of weird behaviors, on the Titanium android sdk you need to understand what a "heavy" window is just to get the back button to work, or even better orientation event tracking. This isn't how the android platform really is, its just how Titanium tries to make their API work.
3) Your thrown in the dark, Things will crash and you have to start to comment code and then when you find it, never use it. There are certain obvious bugs, like orientation and percents on android that have been a problem for over six months.
4) Bugs .... there are a lot of bugs and they will be reported, sit around for months, get fixed in a few days. I am surprised they even are planning to release a black berry mobile sdk when there are so many other problems with android.
5) Titanium Iphone versus Titanium Android javascript engines are completely different. On android version you can download remote javascript files, include and use libraries like mootools, jquery and so on. I was in heaven when I found this out because I didn't have to keep compiling my android app. The android apk installation process takes so long! Iphone none of that is possible, also the iphone version has a much faster javascript engine.
If you stay away from a lot of the native UI parts, i.e instead use setInterval to detect orientation changes, sticking with gradient images, forget about the back button, build your own animations, forget window header, toolbars, and dashboard. You really can make an api that works on both that doesn't require of lot of rewriting. But at that points its just as sluggish as a webapp.
So is it worth it? After all the pain, its worth every minute. You can abstract the logic and just build different UI for each rather then if elseing everywhere. Titanium lets you make fluid applications, that feel fast. You lose the powerful layout abilities of each platform but if you think simple, things can get done under a single language.
Why not a web app? On entry level market android phones its horribly slow to generate a webview and consumes a lot of memory you could be using to do more complex logic.
Here's a more recent and in depth analysis of Appcelerator and PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap
And here's even more detail on how they differ programmatically:
http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript
native mapkit is supported in Titanium
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.
Rhomobile Rhodes (http://rhomobile.com/products/rhodes) is very similar in approach to PhoneGap, but is the only framework with:
a Model View Controller pattern (as
most web frameworks provide)
an Object Relational Manager
support for all popular smartphones (including Windows Phone 7)
a hosted development service (not just hosted build): http://rhohub.com
a full debugger and SDK-less emulator in the RhoStudio IDE
support for synchronized offline data
For anybody interested in Titanium i must say that they don't have a very good documentation some classes, properties, methods are missing. But a lot is "documented" in their sample app the KitchenSink so it is not THAT bad.
My understanding of PhoneGap is that they provide Javascript APIs to much of the iPhone APIs.
Titanium seems easier for a web developer background. It is a simple XML file to create a basic TabView application and then everything in the content area is controlled by HTML / JS. I also know that Titanium does provide some javascript access to some of the frameworks (particularly access to location information, the phone ID, etc).
UPDATE: Titanium added Maps API in version 0.8 of their framework.
You should learn objective c and program native apps. Do not rely on these things you think will make life easier. Apple has made sure the easiest way is using their native tools and language. For your 100 lines of javascript I can do the same in 3 lines of code or no code at all depending on the element. Watch some tutorials - if you understand javascript then objective c is not hard. Workarounds are miserable and apple can pull the plug on you anytime they want.
Of the solutions you mentioned, none of them appear to give you direct access to the MapKit framework introduced in OS 3.0.
As the Google Maps HTML widgets aren't nearly as good as MapKit (see Google Latitude for an example), you are probably best off developing a native Cocoa touch application, or choosing a solution you can extend to add MapKit integration. PhoneGap is extensible in this manner (it's open-source so it is by default), and some of the other solutions might be as well.
edit: Titanium now has support for MapKit
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.