Native mobile app vs cross compile framework [duplicate]

Native mobile app vs cross compile framework [duplicate] - android

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 11 years ago.
Our company will soon start developing few products for mobile platforms, as CTO I was asked to examine the Pro and Cons of the different tools available in order to achieve the best quality / cost effective solution.
We will be aiming primarily at iOS and Android , secondary for Windows-Mobile and BlackBerry.
Candidates:
After conducting some background research, I found the following possible candidates:
Native - Simply but laboriously develop for each platform with its native tools and language.
HTML5, CSS and JavaScript - Could be a web service running on the device's browser (a website) , or an app which incapsulate such code around WebKit.
Rho mobile - Made by Google so it ought to be good - nevertheless based on Ruby (which we are not comfortable with) and does have a complex and rather flimsy dev environment.
PhoneGap - It seems easy and mostly based on Javascript - It is open source but lately acquired by adobe - (not a good sign)
Appcelerator - Anything from Javascript to PHP and to python, have a nice range of API Access but we heard many stories of rejection (by apple), and incompatibilities when using complex code across different platforms.
And more like MoSync, Sencha, Appmobi and Corona (didn't tested them first hand).
Some points of reference:
We are not planning on developing games, the applications we are planning to develop are in the realm of business applications & information tools.
The applications are not depending on excessive use of the devices API's (but do need some minor basic access)
The company already developed for iOS and we have a small team of native iOS developers (Objective-C geeks)
We would like to be sure that we can carry on developing our applications in the feature without them getting broken due to new OS or APIs
It will be beneficial to ensure before hand that the application will not be rejected due to cross platform code (mostly AppStore)
Like any company we would like to be as cost effective as we can - on the other hand we insist on high quality products and top-of-the-line User experience.
There is no better place to ask this question than StackOverflow, I would appreciate any comments from developers with experience on this topic.

There are 500k+ apps on the app markets and competition is fierce. It is paramount to have great UX and graphics.
Cross-platform tools are NOT on par with native development. If they were, we would all be using them. But we are not. With a reason - you do NOT have full control. And full-control is necessary to have great looking apps.
If your app is not a consumer app, but an enterprise app, which use is dictated by some internal department, then you might get by with so-so design, because the value of such app is in it's functionality.
But, if you are serious about mobile apps market - then the only way is to go native. And you need an UX guy and a designer (who knows mobile development) on team full time. You will spend upwards of 50% of time on looks. The project that I'm part of now is spending 80%+ of time on looks (graphics, animations, UX, usability testing).
A suggestion: spend a reasonable amount of time (= days) using you competitors apps. Also spend time with top 50 apps on each market. You will get a feeling how high the bar is. Then check apps made with cross-platform tools (you can find links on their sites) and compare.

While I'm in complete agreement with #Peter Knego, I'd add a few minor points for teams looking to support several platforms:
As Peter notes, UX is huge, and cross-platform UX is least-common-denominator UX. It's hard enough to get this stuff to be everything it needs to be without tying a hand behind your back. Really fantastic web apps are judged on their ability to come close to a native experience, not the other way around.
There are many parts of a product that aren't UX. It's worth considering carefully what kind of reuse you can get there. For instance, I've often advised teams who have SQL databases already working on Android not to try to use Core Data on iPhone. There's no reason to reinvent your object and data models.
This is not a blanket suggestion that you write your core in C++. If you have an extensive, existing C++ core, I've made suggestions before about how to reuse it. But I don't generally recommend it for new code. It's better to use the best OS-level features of the platform in most cases.
Designing network protocols that work well on all platforms is pretty easy and should be pursued. Your best bet here in almost every case is REST and JSON. Keep it simple, especially for iPhone which hates things like SOAP and parsing complex XML.
Some complicated layout problems are easier in HTML+CSS than with native controls. This is particularly true if you have complex multi-column tables (especially things you'd need colspan and rowspan for). I've had fairly good luck embedding individual UIWebView pieces in otherwise native apps, even when portability is not a consideration at all. There can be some worthwhile reuse here. Just remember that you don't want to waste a lot of effort and performance trying to make your HTML browser-neutral. On iPhone, use WebKit extensions anywhere they make your app better for the user.
One of the most important lessons in this, though, is that there isn't a single "right" way to make an app that is appropriate for all platforms. iPhone apps should act like iPhone apps. Android apps should act like Android apps.
Highly cross-platform approaches are a cheap way to get "something" if you don't really care what "something" is. They're a very expensive way to get something great.

I work at AppMobi and I'll just make a few comments.
You're app shouldn't be rejected for being cross platform using a native webview. We haven't had Apple use that on any AppMobi submitted apps.
Rhombile isn't "Made by google". In fact, it's not even the part of Motorola that Google bought, it's their business division. They are pushing towards HTML5/Javascript but currently Ruby.
Appcelerator started out supporting a webview, then backtracked. They just raised a ton of money to go back to the webview suppport.
As to people saying "No" to the cross platform apps. Facebook and some other major companies are moving towards HTML5 based apps for mobile.

Related

How is cross platform mobile development done in practice today (year 2013)? [closed]

Unfortunately, there is no way to develop a cross-platform app which has really native look and feel and shares same code for all platforms.
Its possible to share some code on some platforms though (for example, you can use C/C++ for iOS and Android), but only for the logic part of your app. To get native UI you will be forced to use native APIs. If your app doesn't involve some complicated data processing then this approach may have more downsides than really helping you out.
You can get rather good platform independence with hybrid app platforms such as PhoneGap or Titanium, but that involves HTML/Javascript development which could lead to a lot of time and efforts required to bring user experience to be somewhat similar to that of a native app.

Since you are a .NET Dev one logical solution for you would be to use Xamarin's offerings. (http://xamarin.com/) They allow you to develop your back-end logic once and then compile it into all three major mobile platforms (iPhone/Android/WP). You can then use this back-end logic project to write the UI layer for each specific platform.
Another option that devs have is to use the javascript/html route similar to PhoneGap. While I haven't looked at this recently there used to be some performance hits and hardware usability gaps when going the JS/HTML route. This may have been improved now.
EDIT:
Since you specifically mentioned games like Angry Birds. The Unity platform offers very good support for development that is compatible with most devices if you need 3D.
For Angry Birds specifically...they use Box2D for the Physics and I'm not 100%, but it looks like Cocos2d to draw the elements.
If you are looking to build games and like the idea of Xamarin then take a look at MonoGame which basically looks like an XNA port to the Mono Framework.

in addition of Jared's answer, this afternoon I tested Xamarin.
You are a .Net Developer and if you are already using Visual Studio, you are so lucky. Because Xamarin has an extension for Visual Studio
I just want to give a bad impression about xamarin, you can test good ones by the time, user interface is created in a xml based file and there is no auto complete, so you have to write whole code or use properties window. But I think it will be better by the time. nice coding

Mobile development - Native VS Cross Platform VS JavaScript [closed]

There are 500k+ apps on the app markets and competition is fierce. It is paramount to have great UX and graphics.
Cross-platform tools are NOT on par with native development. If they were, we would all be using them. But we are not. With a reason - you do NOT have full control. And full-control is necessary to have great looking apps.
If your app is not a consumer app, but an enterprise app, which use is dictated by some internal department, then you might get by with so-so design, because the value of such app is in it's functionality.
But, if you are serious about mobile apps market - then the only way is to go native. And you need an UX guy and a designer (who knows mobile development) on team full time. You will spend upwards of 50% of time on looks. The project that I'm part of now is spending 80%+ of time on looks (graphics, animations, UX, usability testing).
A suggestion: spend a reasonable amount of time (= days) using you competitors apps. Also spend time with top 50 apps on each market. You will get a feeling how high the bar is. Then check apps made with cross-platform tools (you can find links on their sites) and compare.

I work at AppMobi and I'll just make a few comments.
You're app shouldn't be rejected for being cross platform using a native webview. We haven't had Apple use that on any AppMobi submitted apps.
Rhombile isn't "Made by google". In fact, it's not even the part of Motorola that Google bought, it's their business division. They are pushing towards HTML5/Javascript but currently Ruby.
Appcelerator started out supporting a webview, then backtracked. They just raised a ton of money to go back to the webview suppport.
As to people saying "No" to the cross platform apps. Facebook and some other major companies are moving towards HTML5 based apps for mobile.

Downsides of using Appcelerator Titanium (or equivalent)?

At our company there is a huge push for cross-platform (iOS and Android) development. Appcelerator Titanium is being considered (and seems to be the only thing that's being considered) to achieve multi-platform development without extra development time.
Everyone here can think of reasons to use Titanium. For reasons against using Titanium I guess the performance of the resulting "native" app from Titanium may not be as good as an app written in Objective-C for iOS. How significant would the difference be? Are there other reasons to not use Titanium (or equivalent)?
Note: I may write Titanium but reasons may not only be Titanium specific only. All reasons in support for coding in platform language (e.g. Objective-C, Java) qualify.

The Good:
Can create iPhone apps using very simple Javascript.
The Bad:
Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn't responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api
"Native Widgets" are used, but only nominally: there's a layer of
logic and abstraction between them and your code; and this layer
changes their behavior and reduces their speed. The difference is
visible in the Showcase apps.
API docs are perpetually out of date. (no process for refreshing).
A wiki was created, which is becoming out of date. Editing only
allowed for employees.
Github projects do not have wiki enabled.
Appcelerator isn't true open source: they do not accept contributions from the community: The
titanium_mobile project on github has a long list of open pull
requests.
The help forum software has many technical & design weaknesses.
Email notifications from the help forum often do not work.
Staff rarely answers questions in the Q&A forum. Haven't been seen
in months.
Showstoppers appear continuously in "all the little gaps":
Correctly displaying images on the iPhone 4
Correctly loading images in a scrolling list
Although the platform does simultaneously support iOS and android,
the library/framework does not. A lot of runtime testing (if/then's)
is needed in apps that will work on android and iphone.
Continually releasing new products but not fixing existing products
and website problems. The "new" products are announced while in beta
and release candidate phases.
"Chat with Sales" app not attended to.
Appcelerator does not take down outdated training videos.
Stretching the truth and bait-and-switch with pricing: a 30% sale
only applies to yearly memberships, not month-to-month. The blog
posts & marketing materials do not state this. Only upon checkout is
this shown.
[Seen 8/13/2011] Another way in which Q&A forums are broken: The order of
results for a search is trashed: each page of results orders its hits
from oldest to most recent, at the bottom of the page. Go to the next
page of results (i.e. 51-100), and again, the 1-year-old hits are
first, with 6-weeks-old at the bottom.
My Unanswered Questions:
[Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff
and receive sub-par treatment.]
Results:
Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.

How significant would the difference be?
AFAIK, Titanium will generate Objective C, so unless their stuff is woefully inefficient, I wouldn't expect speed to be a major issue.
Are there other reasons to not use Titanium (or equivalent)?
Well, that depends on how you define "equivalent".
Personally, when I get into cross-platform apps, I expect that I will use PhoneGap. That's for one reason: standards.
With PhoneGap, you're writing HTML, CSS, and JavaScript, as if you were writing an HTML5 offline app. All PhoneGap does is turn that into an installable package (e.g., APK for Android) and give you opt-in proprietary APIs for getting to device-specific stuff. Their expectation is to simply fill in the "gap" between what HTML5 on mobile supports and what native apps on mobile supports. Heck, it's even in their name. :-)
As a result, what you are writing is the same sort of tech you would use for a Web-based app, and it may even get to share some of the client-side code. You can use whatever you like from mobile frameworks (e.g., Sencha Touch, jQuery Mobile). And, if someday app stores support HTML5 offline apps, you might even be able to drop PhoneGap altogether, if you're not heavily dependent upon the device integration features.
Titanium lets you write in JavaScript, but the standards compliance largely ends there. You're using proprietary APIs for everything, including the whole UI. Personally, I'd rather back a more popular horse -- HTML5 in this case, more so than PhoneGap specifically. If for no other reason, it'll be way easier to hire HTML5-savvy developers than Titanium-savvy developers.
Neither PhoneGap, nor Titanium, nor any of the plethora of other options (e.g., Rhodes, Flash/AIR) give you all of the device capabilities. These engines will vary in their extensibility -- I know that PhoneGap has a plugin model, that Flash/AIR is pretty much only what you get from Adobe, and I'm not sure about any others.
Titanium has one advantage: you get a near-native UI, instead of an HTML-based UI. (I say "near-native" because some of their widgets do not necessarily have native equivalents on all platforms, so they roll their own as needed) For some apps and some audiences, that alone may tilt things in Titanium's favor.

Titanium/iOS specific answer, my 2c.
Native iOS vs Titanium
PROS
It's nearly as fast as native for most things.
The time needed to write a working prototype it's way shorter.
If you need to integrate javascript legacy code or libraries it will work provided that it doesn't use the dom.
Your javascript code needs to be well spaced and to include semicolumns where needed or the compiler will complain and eventually abort the build.
You can use Coffeescript or any other language that compiles to js
Automatic memory management is top notch, getting the same results in objc is always time consuming and sometimes debugging intensive.
You can write your own modules in native code to extend Titanium's capabilities.
It's open source.
They recently changed their support offering removing the 5 app limit, much more affordable.
You can change a view js code while running the app in the simulator, you will see the results when you reload the view you're editing. That's a boon :) (exception: there's no way I know of to reload the code in app.js)
CONS
Debugging is a pain. Haven't tried out Titanium Studio yet, it might be a big improvement.
Adding too many views tends to degrade performance faster than using native code.
The Titanium Developer app on Mac has plenty of interface glitches and you might find yourself restarting it pretty often.
In some versions the print to console debug statements are broken.
You will often stumble into cross-platform abstraction leakage.
Support on the forums is a bit light, many issues you will encounter are not big but still annoying.
Need to pay attention to JSON correctness, the included parser tends to be picky. Using eval is always an option.
Compile times and loading in the simulator are not that fast, titanium objc is pretty big.

Compared to Xcode, Visual Studio & even MonoDevelop, Titanium Studio feels slow (real slow), buggy (restarting several times each day, even reinstalling a few times) and of course you've got to deal with JavaScript... We found that the pain of developing in Titanium was too great, especially when you have competent iPhone & Android devs around so -
We looked long & hard into the best option for cross-platform dev & ended up using Mono - Touch & Droid. It's been great, we do actually share 80% of the code between iPhone & Android, & we're just beginning a port to WP, which is going well (again sharing 80% of the code). Of course it's not a miracle fix - you still need to know how to develop for each platform. I've even grown to like C# almost as much as Obj-C now :-)
Obviously, some will disagree.

Converting iPhone/iPad apps onto Android [closed]

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 9 years ago.
I have started to build my own apps on iPhone and iPad using the iPhone SDK. The next question that is always asked by the client is, "Can we have it on Android?"
So my question to you, 'the internet', is: what are my options?
I don't have the time to learn another language (learning iOS has been enough!), so are there companies who specialize in this, or are there any online services that do a conversion?
Any help on this welcome, just need to know which way to turn...

No, there is no way to convert an existing iOS app to an Android app.
However, there are cross-platform frameworks that allow you to code once and deploy your app in more than one platform. The most popular are based on HTML/CSS/JavaScript and one of them is PhoneGap.
You can also develop for iOS and Android with Adobe technologies such as Adobe AIR (this was forbidden by Apple until recently).
And there are online services (such as Mobile Roadie) that allow you to generate cross-platform apps using a content management system.
That said, I strongly recommend to:
Learn Android and Java development if you want to specialize in mobile development.
Take advantage of the strengths of each platform when working on an iOS/Android project, instead of creating something that uses only what's common to both.

Converting a native application from one mobile platform to the other is not a straight-forward process unless the initial application was built with a framework with cross-platform capabilities from the start.
Your options at this point are learn the other platform and develop it yourself, or contract with another development company which specializes in the platform you need to target.

Due to the massive differences between the 2 platforms, you are looking at a complete rewrite of your application. You either do it yourself or pay someone else to do it. I don't see any shortcuts you can take.

You may be interested in reading my book, HTML5 for iOS and Android, which enables you to take web apps created in HTML, JavaScript & CSS, and turn them into standalone apps that you can upload to the app stores (for free or to sell). See http://html5formobile.com - the wrappers to do this for the iOS and Android SDKs are freely available on the website, and you don't need any knowledge of either programming language if you follow the instructions in the book.

You can try the following https://bitbucket.org/zabirauf/icona.
Its open source iOS to Android Application Conversion Tool.

Even if there was a way to easily port an Objective-C application to Java, I wouldn't highly encourage it. iPhone users and Android users are two different families of users. The typical iPhone interface just wouldn't sit well with Android users who aren't familiar with how the iPhone works. Yes, I understand that the UIs of both iPhone and Android seem pretty trivial to learn to most people, but when you break a novice's comfort zone, it puts your applications (or websites) on a higher learning curve.
You should take the time to learn Android's language and UI and develop your application in a fashion that is consistent with how applications on Android work. As said in other answers, if your taught yourself Objective-C, you should find that Java will come pretty easily to you. In addition, in never hurts to know more than one programming language.

You can't just convert iOS apps into Android. iOS is Objective-C and Android is Java.
I highly doubt there are 'converters' on the internet, even if there are that's not the way you should program an app because every SDK has his own special capabilities and you should use them for maximum user-experience.
I'm sure there are some companies who specialize in porting apps from iOS to Android. Look it up on Google I'd say..

If you want an easy place to look for android development you can try appMaker which I hear is a GUI based Android development tool or I believe Google has released its own GUI based android application development tool. If you are not a java programmer than you might be better off with the gui. Otherwise I would say android is not too different from traditional java. As a java programmer who went from Android to iOS, I will tell you Android is a walk in the park compared to learning iOS. Two completely different beasts in my opinion.

Selecting a mobile development environment which will enable you write once and deploy/distribute it on many devices would be a better solution in the future. If your application is HTML-based, go with HTML5/CSS alternative (ex: PhoneGap, ). If you prefer native, then chances are you may want to learn Lua, a scripting language (ex: Gideros Studio) or C++ (ex: Mosync).
Other than that, the application you created on iOS with Objective-C is very, very hard to port to Android and other devices.

Developing cross platform mobile application [closed]

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.
More and more mobile platforms are being launched and sdk's are available to developers. There are various mobile platform are available:
Android, iOS, Moblin, Windows mobile 7, RIM, symbian, bada, maemo etc.
And making of cross platform application is headache for developers. I am searching for common things across the platforms which will help to developers who want to port application to all platforms. Like what are the diff screen resolutions, input methods, open gl support etc.
please share details that you know for the any of platform.
Or are there possibilities, by writing code in html (widget type of thing) and loading it into native application.
I know about the android, in which we can add the web view into application by calling setContentView(view)
Please share the class details where we can add the html view into native application of different type of platforms that you know.
Purpose of this thread is share common details across developers. marking as community wiki.
Cross platform tools & library
XMLVM, Codename One and iSpectrum (cross compile Java code from an Android app or creating one from scratch
Phone Gap (cross platform mobile apps)
Titanium (to build native mobile and desktop apps with web technologies)
Mono Touch ( C# for iphone )
rhomobile - http://rhomobile.com/
samples are here: http://github.com/rhomobile/rhodes-system-api-samples
Sencha Touch - Sencha Touch is a HTML5 mobile app framework that allows you to develop web apps that look and feel native on Apple iOS and Google Android touchscreen devices. http://www.sencha.com/products/touch/
Corona - Iphone/Ipad / Android application cross platform library . Too awesome.
http://anscamobile.com/corona/
A guide to port existing Android app to Windows Phone 7
http://windowsphone.interoperabilitybridges.com/articles/windows-phone-7-guide-for-iphone-application-developers
Jquery MobileTouch-Optimized Web Framework for Smartphones & Tablets

My answer here covers some of the technical limitations of cross-platfrom tools but let me expand a bit:
I think that cross-platform tools have historically always been also-rans because such tools have the wrong philosophical focus.
All the selling points for cross-plaform tools are the benefits they bring to developers. They are sold on the idea that they allow the developers to write-once-run-anywhere. They are sold on the idea that they allow the developers to expand their market without learning new APIs. They are sold on the idea that they allow the developers to slash cost and time to market.
What cross-plaform tool are NOT sold on is the benefit they bring to end users.
Benefit to the end user is not a selling point because cross-platform development is seldom a benefit to the end user. The end user does not care how hard the developer had to work to bring the product to market. Nor do they care how many platforms the app can run on when they they don't use but one platform. They just care if the app does what they need it to on the hardware they need to run it on. Unless they have a specific need to run the app on many different platforms, the fact that it does brings them no value.
Conversely, the inevitable compromises of making a cross-platform API mean that all the apps created by the API will be at best B-grade on every platform. They will never be the best tool to use on each platform.
All this means that in most use cases, cross-platform tools give the end user an inferior product compared to ones made with platform specific APIs. The end user will always have a better choice.
You make money in the long run by giving end users the most useful tools. If you don't philosophically concentrate on making the end user's life easier and more productive, you are pretty much doomed from the outset. End users have lots of choices and if your tool isn't one of the best you won't make it in the market.
You should only use cross-platform tools if you think, "the users will really benefit from running this app on many different platforms." If you start out looking at cross-platform tools solely because they will make your (the developers) life easier, then you have picked them for the wrong reason and they will hurt you more than they will help.

There are several approaches to cross-platform development on mobile devices. Of course they all have limitations. No solution manages to take advantage of all the device's functionalities the way a native application can.
Re-using code
While all mobile OS don't use the same development language and API you can sometimes share some classes or logic tier code.
C++ for example can probably be re-used for an iOS application, for an Android app by using the NDK, for a Symbian app since they are developed in C++, etc.
Some solutions also offer the possibility to write the app in an other language than the one normally used by the device. The most famous (in fact the only one I know) are commercial and based on the Mono project (C# development):
MonoTouch for iPhone [ 1 ]
MonoDroid for Android (still in development)
Similar project for BlackBerry (still in development)
But I'm not sure we can really call this cross-platform development since the re-use of code is limited depending on the device :
Windows Phone 7 will not allow native code development (maybe in further updates)
AFAIK mono like project do not exist for all platforms (yet?) bada, webOS, maemo, etc.
And the UI part also stays specific to each device.
Web development
A regular answer when asking about cross-platform development for mobiles is web development. We would then need a wrapper, that will use the mobile browser, to make it look and behave like a native application. That is how some of the cross-platform framework that we will see further on work.
The rise of HTML5 brings to web development functionalities that could only be done with a native application like geolocation, off-line application, local storage.
We can found more and more frameworks to develop web application for mobiles with a native look and feel by taking advantage of the latest web standards HTML5, CSS3, Js:
Sencha Touch
JQTouch based on jQuery
JQuery Mobile framework
But HTML5 is still very young and implementation may vary from a browser to another. Most default mobile browsers use the WebKit engine (main exception being Windows mobile/phone using Internet Explorer) and even so they don't necessarily support the same functionalities. Local database is still awkward to work with and we can't be sure how it is going to implemented by the different browsers. Moreover, even with HTML5, web development is still very limited compared to a native app. You can't access contacts, camera, accelerometer, etc.
Edit: Earlier this month the W3C have delivered some warnings about the evolution of HTML5: Article from ZDNet
So it will only suit a limited category of applications.
Cross-platform frameworks
And than we have the cross-platform mobile applications frameworks. With which you can presumably develop once and deploy on different platforms. These solutions usually focus on iOS and Android and rely on the WebKit engine. They offer more interaction with the phone functionalities while developing with web technologies. The most well-known are Nitobi PhoneGap, RhoMobile Rhodes, Appcelerator Titanium. But many others are out there and don't all use the same technique like MoSync which translate your code to it's own intermediate language before compiling it for the desired platform.
[ 1 ] Remember that Apple has a special policy about apps written for their platform. They don't seem to be blocking these apps at this date but it is an information that should be taken into account.
Edit: Apple has changed this policy since September 9.

You get some commonality when deploying as a webapp (html5 as mentioned above) but for rich native apps the APIs are completely different for the various smartphones.
HTML5 may improve things somewhat but to do interesting things you need to go native.
There are 'cross platform' smartphone frameworks such as Phonegap but I've heard mostly bad things about using it for "real" work. (lots of overhead etc)

Yes, html5 is getting some attention. You should also look at this consortium & platform to come in Q4.
Not sure about the success of that project, as it sounds like a huge challenge, but here are the details:
Website:
http://www.wholesaleappcommunity.com/default.aspx
News:
http://news.google.de/news/search?aq=f&pz=1&cf=all&ned=us&hl=en&q=%22Wholesale+Applications+Community%22
WAC aims to publish its initial
specification and components of its
SDK to developers in November. This
specification will be based on W3C
standards and create a strong platform
for developing rich mobile web
applications. WAC will also provide
backwards compatibility for devices
based upon the current JIL and BONDI
specifications.
(http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=31021)
.
It IS an international coalition of around 25 telecom companies that's aiming to create a platform open to all developers and selling to all mobile phone users.
(http://www.downloadsquad.com/2010/02/15/atandt-wholesale-applications-community-is-a-platform-not-an-app/)

As far as I know most of those devices are able to run this:
Java ME - the Most Ubiquitous Application Platform for Mobile Devices
I think this can serve both as good and bad example.

Develop Reference

The Android operating system is a mobile operating system that was developed by Google (GOOGL?) to be primarily used for touchscreen devices, cell phones, and tablets.