There are a lot of players out there in the mobile development framework world. AML isn’t the only option if you’re looking for accelerated or cross-platform mobile development. I believe it is the only option that does what it does, but that doesn’t mean it’s the best one for your application. This article points out the differences, strengths, and weaknesses in a few of the tools out there so that you’ll have the best chance of accomplishing your goal. For the impatient, you can go straight to: App Inventor, DroidDraw, Rhomobile, PhoneGap, Appcelerator, WebView, AML

…or skip it all and jump down to the comparison table.

Update 7/17 @ 9:25pm: Brian LeRoux from the PhoneGap project informed me that much of what I wrote about PhoneGap originally was not correct. This has been fixed, with apologies to the PhoneGap team for the misinformation.

The project promoted by this website (AML) is the last in the list. I will not pretend that it is the best option across the board, and it will be easier to evaluate against the other tools if you have already seen a little bit about them.

Each of the descriptions below are split into a few different sections:

  • Strengths – Why is this a good tool?
  • Weaknesses – Why might it not be a good tool?
  • Development Requirements – How do I get started building apps with it?
  • Deployment Requirements – How do I get my apps onto a device?
  • Overall – Who and what is it best suited for?

The information under each of these sections is compiled from posted documentation in some cases and experience in others, and should hopefully give you a good enough idea about each tool to help you figure out if you want to learn more. Just click on any of the logos or linked titles to go to the official website for each product.

ALSO: I may have missed or misunderstood some critical information about these different tools. If you read something you know or suspect to be untrue, please leave a comment or send me some feedback. It is not my intent to malign any particular tool, or unfairly promote my own efforts. I am open to any contributions that will help clarify.


Google App Inventor

A caveat here to begin: App Inventor is currently still in private beta, and I do not have access to the actual product. What I have written here is only accurate as far as I can tell from posted info, and not from personal experience.

Coincidentally, Google officially announced App Inventor on the same day that I wrote my blog post about my first experiments with Android and AML. As of today, App Inventor is the newest tool out there. It’s is like Visual Basic for Android, providing a friendly GUI for building and coding Android applications. AppInventor greatly lowers the barrier of entry for anyone wishing to start development. It is targeted towards educational arenas as a way to get students started with programming, but it can be used by anyone for any purpose. From the About page:

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

Strengths

  • Free
  • Extremely easy to get started (it’s a web app)
  • IDE runs on any OS that supports Java (again, it’s a web app)
  • Extremely easy to use
  • No coding necessary for layout or behavior
  • Includes an Android device emulator, no phone required
  • Includes predefined “blocks” for accessing web services
  • Provides limited visual live debugging and testing

Weaknesses

  • Android only, no other platforms supported
  • Pure visual design style may be difficult for seasoned developers
  • Does not export Java code, so no direct code creation or modification is possible

Development Requirements Summary

(Official setup instructions here and here)

  1. Create a Google account if you don’t have one (you probably do)
  2. Install the Java Runtime if you haven’t already (you probably have)
  3. Install the App Inventor Extras for your platform
  4. Browse to the App Inventor home page and go nuts

Deployment Requirements Summary

  1. Connect phone to computer
  2. Within App Inventor, click Package for Phone
  3. Select Download to Phone

Overall

App Inventor will be a great tool for brand-new programmers or people testing the waters of mobile development. It is easy and could even be classified as fun. However, it will probably not see wide adoption among serious programmers or in the enterprise market, because it is too restricted and simple. Because you cannot write your own code, you are limited to using the conceptual and functional “blocks” that they provide. For an efficient coder, writing a complex app in this way will almost certainly be more difficult than just using an IDE such as Eclipse.

Verdict: it’s great for anyone (kids, students, and adults) who want to learn programming concepts using their Android device. For other platforms or other types of developers, it’s probably not the best choice.


DroidDraw

DroidDraw almost doesn’t belong in this list because it doesn’t actually build functional application code of any kind. It only creates layout definitions, and only for the Android platform. Even so, because it is a useful tool, directly related to mobile development, and similar in some ways to App Inventor, I have included it anyway. With this difference in mind, I will not list anything like “doesn’t create application code” as a weakness, because that’s not what it’s supposed to do in the first place.

DroidDraw’s official website is rather simple, without a lot of hype or marketing. It has a screenshot of the application in action (which effectively illustrates what it does and how it works), along with the following description from the developer:

This tool was written to make my Java programming life easier. It can be used to build graphical user interfaces for the Android cell phone platform. I hope you find it useful for whatever Android/Java cell phone software development projects you have planned!

Strengths

  • Free
  • Extremely easy to get started
  • Extremely easy to use
  • No coding necessary to create layouts
  • Includes an Android screen layout emulator, no phone required

Weaknesses

  • Android only, no other platforms supported

Development Requirements Summary

  1. Download and run the stand-alone executable from the official website

Deployment Requirements Summary

  1. Generate XML layout content
  2. Copy/paste into development environment

Overall

DroidDraw has been used for some time, and it will probably continue to be used because it is good at what it does. It removes the need to work directly with Android’s XML layout syntax, which is a little tedious even if you are comfortable with it. However, if you want to use it, just keep in mind that all it does is create Android layouts. It will not help you create any application logic in the same way that App Inventor does. On the other hand, it does generate XML data that you can use directly in your own application code, unlike App Inventor.

Verdict: great if you need to visually build an Android app layout. Not suitable for any other platforms or any actual application logic.


Rhomobile Rhodes

Rhomobile’s Rhodes is an established and feature-rich cross-platform mobile development framework. Rhomobile has been around since October 2008, and they just released v2.0 of the Rhodes framework at the end of June, about two weeks ago. Rhodes is a complete Model-View-Controller framework written in Ruby. Rhodes takes your Ruby code and compiles it into native code for whatever device(s) you wish to target. This removes the need for you to write any code whatsoever in the target devices’ native languages. Here’s their own summary of the framework:

Rhodes is an open source framework to rapidly build native apps for all major smartphone operating systems (iPhone, Windows Mobile, RIM, Symbian and Android). Write your code once and immediately build apps for every major smartphone. These are true native device applications which work with synchronized local data and take advantage of device capabilities such as GPS, PIM contacts and camera.

Strengths

  • Free (entire framework is open-source)
  • Ability to deploy a single codebase on multiple platforms
  • Compiles to truly native application, not HTML5 in a mobile browser
  • Interfaces with device hardware such as camera, GPS, and accelerometer using Javascript
  • Built on Ruby (strength if you know Ruby)
  • Browser-based app construction using RhoHub
  • Easy multi-device and cloud data syncing using RhoSync

Weaknesses

  • Does not output native source code, only native package
  • Runs entire app through bundled RubyVM interpreter
  • Built on Ruby (weakness if you don’t know Ruby)

Development Requirements Summary

(Official setup instructions here, free registration required, see Prerequisites)

  1. Install Ruby
  2. Install RubyGems
  3. Install GNU make (usually only required for Windows)
  4. Install rhodes gem
  5. Install Java Development Kit (required for Android and BlackBerry deployment)
  6. Install Android SDK (required for Android deployment)
  7. Install iPhone SDK (required along with Mac for iPhone deployment)
  8. Install BlackBerry JDK (required for BlackBerry deployment)
  9. Setup Rhodes source

Deployment Requirements Summary

(Official deployment instructions here, free registration required, see device-specific sections)

  1. Build app for desired platforms
  2. Sign app packages for desired devices

I want to point out here that while the above list looks simple, the actual deployment process for apps built using Rhodes is rather intimidating. I’m sure it works, since lots of people build apps with the framework, but “summary” above is an incredible oversimplification. Some of the platforms require a lot of scripting or custom configuration to get to the final product. For details, read the official docs. Note that their hosted app development platform RhoHub takes care of these difficulties.

Overall

The Rhodes framework is a complete, feature-rich tool to quickly get your apps onto multiple mobile device platforms. Using the same codebase across all types of devices is a great convenience. If you know Ruby, it’s probably an excellent option. If you don’t know Ruby, you can still build applications (using HTML without any Ruby scripting), but you won’t be able to do nearly as much—think “web apps without AJAX” for an analogy, though it that doesn’t parallel the differences exactly. You’ll just be able to be much more productive and efficient if you are able to include a Ruby component in your app.

The RhoHub online application builder is a very interesting feature, and it looks like it may alleviate some of the complexities in platform-specific deployment. However, if you want any private apps (i.e. hosted apps that aren’t visible to just anyone with an account), you have to pay a minimum of $20/month. The enterprise option (with much higher limits on app count and disk space) is $100/month. Not terrible if you really utilize it, but it’s something to consider.

RhoSync could be very beneficial if your mobile app is primarily concerned with data from a web app, and you need to be able to perform a two-way sync with offline activity support. You have to define basic data connectors for the types of objects you want to sync, but you would have to do that for nearly any sync solution anyway. The possibility of integrating it easily into their framework makes it a nice bonus.

The fact that it doesn’t produce native device code for you to work with (as far as I can tell) is unfortunate for flexibility, but they have obviously gone to great lengths with their framework code to eliminate the need for that. I haven’t found anyone online complaining about that missing “feature,” so I wouldn’t consider it a real problem at this point. If you really want to be able to work with your native app code that much though, this probably isn’t the option for you.

Verdict: Great for web developers fluent in Ruby who want to build mobile apps for their web applications. It is powerful, but requires significant special knowledge for best results. May be a good choice if uniform cross-platform deployment is very important to you. May not be a good choice if you are terribly intimidated by shell commands and/or aren’t familiar with Ruby or HTML, or you simply don’t need the cross-platform singular deployment option.


PhoneGap

Update 7/17 @ 9:25pm: Brian LeRoux from the PhoneGap project informed me that much of what I wrote about PhoneGap originally was not correct. This has been fixed, with apologies to the PhoneGap team for the misinformation.

PhoneGap is another cross-platform mobile development framework, and is the only one of all of the tools mentioned here that supports Palm. It is similar in some ways to Rhodes. It uses Ruby during some of the package building processes, but the actual applications are not written in Ruby, and therefore they are not dependent on a Ruby VM or runtime interpreter to execute on the mobile device. Instead, apps are written using HTML, CSS, and Javascript, which is then wrapped into native app code and displayed using PhoneGap platform libraries using the device-specific browser object.

Apps are completely self-contained and don’t just pass off local HTML to the actual phone browser; they use native components (e.g. WebView) within the app to render the HTML using whatever browser engine is available. The app content is not actually converted into native UI objects individually, such as inputs, buttons, and lists, but instead only displayed as web code. This post shows a quick sample app for Android.

While that functionality alone can be achieved simply by creating a mobile-friendly website, PhoneGap adds on to this by providing a large number of Javascript-based interfaces to the phone hardware (like the accelerometer, GPS, and camera), otherwise unavailable to browser-based apps and a pure WebView approach. And of course, having your own self-contained app is generally more professional than forcing people to browse to a mobile website URL.

Jan Piotrowski (@Sujan), who has become very familiar with PhoneGap and the other frameworks listed here, puts it this way:

Phonegap basically is a collection of WebView wrappers for different platforms. You have all the source files for these wrappers, so you have full, absolute native code access. The only thing that is hard is to make this native code functions available to the HTML/JS part, but that’s what the wrapped APIs do.

PhoneGap is also integrated pretty cleanly into your application code, and it is possible to write your own native code alongside the PhoneGap-powered app code. This could be useful for extending the functionality of native hardware interaction, for example, or accessing external data on the device. While the main app is designed to be all HTML, CSS, and Javascript, you have some flexibility.

Here’s PhoneGap’s self-description:

PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.

Strengths

  • Free (entire framework is open-source)
  • Ability to deploy a single codebase on multiple platforms
  • Interfaces with device hardware such as camera, GPS, and accelerometer using Javascript
  • Integrates with native source code (app-based web browser object)
  • Widest major platform coverage of all tools at this time
  • Apps built using extremely common web languages

Weaknesses

  • Application is rendered using platform’s web browser engine, not individual native UI objects

Development Requirements Summary

(Official setup instructions are here per device)

  1. Install Ruby
  2. Install GNU make (usually only required for Windows)
  3. Install Java Development Kit (required for Android and BlackBerry deployment)
  4. Install Android SDK (required for Android deployment)
  5. Install iPhone SDK (required along with Mac for iPhone deployment)
  6. Install BlackBerry JDK (required for BlackBerry deployment)
  7. Install PhoneGap

Deployment Requirements Summary

(Official deployment instructions are here per device, see tail end of each device’s details)

  1. Build app for desired platforms
  2. Sign app packages for desired devices

This is another short deployment instruction list, but once again it’s actually a bit more complex than that depending on your target platforms. Check out the docs for more details. Because PhoneGap is a library that you include in your code, and not a whole development environment or special application, the deployment process for any given platform is very similar to what you would have to do without PhoneGap.

Overall

It’s easy to use, built using everyday web languages, extremely cross-platform, and it allows device hardware access. This makes it a great choice unless you are looking to take advantage of all possible native UI objects. Because it renders the main app in a browser engine component, you miss out on some of the native look-and-feel that is possible with other options. You can write your own native code alongside the main app, but if a fully native UI is a primary goal, then this approach is not efficient.

Verdict: great if you want a fast, versatile framework to build an app, and you are familiar with HTML, CSS, and Javascript. However, not the best choice if you aren’t okay with your application being rendered in a browser component.


Appcelerator Titanium

Appcelerator’s Titanium platform is a very powerful and feature-complete solution. It is similar in some ways to Rhodes and PhoneGap, but the implementation is a bit different. Titanium primarily uses Javascript and JSON code to as the application language, though it can make use of Ruby, Python, and PHP scripts. Like the other two, it aims to be a complete self-contained library that removes the need to write any native platform code (although they provide a way to do so if you want to extend the functionality). Titanium currently supports Android and the iOS (iPhone/iPad) platform, but they have planned BlackBerry support in the near future. Their website is easy to navigate and getting started with development is straightforward and simple. Here is their description of the platform:

Today you need to be in three places at once: Online, On-phone, and On-desktop. Titanium empowers you to create immersive, full-featured applications that go beyond browser boundaries and stick with your audience whenever and wherever they are. Once built, Titanium-based applications can be tested, packaged, and distributed through the Appcelerator Network’s cloud services. The Titanium platform is open source, so you may also access the source code to the complete application at any time for your own use.

Strengths

  • Free (entire platform is open-source)
  • Ability to deploy a single codebase on multiple platforms
  • Compiles to truly native application code, not HTML5
  • Works with emulators, no phone required
  • Framework has its own development environment
  • Generates real native source code as part of the build process, accessible to developer
  • Interfaces with device hardware such as camera, GPS, and accelerometer
  • Very large library of APIs for all kinds of activities and data access
  • Allows custom plugins using native code per platform (Java/Android, Objective C/iPhone)
  • Uses Javascript/JSON for primary language (strength if you know Javascript)
  • Supports Ruby, Python, and PHP scripts for broad developer coverage
  • Good example documentation and video tutorials
  • Has desktop component like Adobe AIR, but requiring “1/10th the memory“

Weaknesses

  • Uses Javascript/JSON for primary language (weakness if you don’t know Javascript)
  • Of all of the established multi-platform frameworks being reviewed here, this covers only two platforms so far

Development Requirements Summary

(Official development instructions here)

  1. Install Titanium Developer
  2. Install SDKs for target platforms (Mac required for iPhone development)
  3. Install the Java Development Kit (required for Android deployment)
  4. Start the Titanium Developer application and go nuts

Deployment Requirements Summary

(Official deployment instructions here, see device-specific sections)

  1. Package app for desired platform(s) with proper key(s) using Titanium Developer application

Overall

Titanium is a relatively new player (it’s only been out of beta for a few months), but it looks incredibly well-built and it takes care of the two most popular app-driven platforms, with a third (BlackBerry) on the horizon. It appears to have a lot going for it. Perhaps most importantly to developers, it actually produces full native code for each device before building the end product. This is a great benefit in that, unlike Rhodes, it doesn’t run all of your code through an interpreter. It has a lot of documentation, a lot of example code, and a great “Kitchen Sink” sample application with full source to get you started.

Verdict: Rhodes is probably tempting to many of you, but if you don’t know Ruby, Titanium and its Javascript foundation could be much simpler. Plus, the native device source generation is a great feature. If you need all the platforms that Rhodes provides, you might try that out; otherwise, Titanium gets my vote for ease, simplicity, and great documentation with examples.


WebView

Depending on your needs, you may even be able to use the built-in WebView object on Android, or UIWebView object on the iPhone. Windows Mobile has the WebBrowser class, though I am not sure how truly similar this is to the WebView/UIWebView.

John Coryat over at the Android Developers discussion group educated me a bit about this tool. A WebView object is essentially just an in-app web browser. You provide a web page source, and it displays the exact same thing that your mobile device would display if you were using the dedicated mobile web browser instead of your own app. However, WebView offers a distinct advantage over the “pure browser” approach, because it allows interaction between the web page content and the native application code, to whatever degree you want to write code to support. The PhoneGap platform mentioned above makes heavy use of this. Even the official Gmail app from Google uses WebViews in some places. It can be a powerful tool if used correctly.

However, a WebView doesn’t provide any built-in interface between your HTML/CSS/Javascript code and the phone hardware. If you need that, then you would have to write your own code to support it. In this case, you would essentially be creating your own version of the PhoneGap framework from scratch, as this is exactly how PhoneGap works. You would probably be better off in that case just using PhoneGap instead.

The Android API has the following description for WebView (iOS and Windows Mobile implementations are similar):

A View that displays web pages. This class is the basis upon which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.

Strengths

  • Free (included in SDK source)
  • Renders HTML/CSS content as directed without any extra work for the developer
  • Ability to interact with other app code through Javascript
  • Highly customizable for each app, use as many or as few features as you want
  • Requires no 3rd-party libraries or non-standard development practices

Weaknesses

  • Not all platforms have fully developed HTML5/CSS3-compatible views
  • Differences in rendering engines (WebKit vs. Trident vs. BlackBerry browser) may change appearance across mobile platforms

Development Requirements Summary

  1. Just use it, it’s already in the native APIs

Deployment Requirements Summary

  1. Nothing special required

Overall

Taking the WebView approach is quite different from any of the previous options. It eliminates the need for any non-native code, which gives it simplicity in its own way. If your project is not that complex, using a full framework may be overkill. If that’s the case, you may be able to accomplish your goal with a simple WebView-style object and a little clever Javascript code. It’s not easy to completely integrate app code with web page code in a complex way, but if your app isn’t complex, this may be the way to go.

However, using only WebView also means that whatever else you want to do with your app will be all native code. If you are writing for Android and have trouble with Java, or writing for iOS and can’t navigate around Objective C, then taking the WebView shortcut might be a bad plan.

Verdict: inherent availability and HTML/CSS rendering capabilities make this a good option if you are comfortable in the native device language and you can build the rest of the required app features yourself. It doesn’t make the development process much easier though, so if that’s your primary goal, consider one of the other options.


Application Markup Language (AML)

Application Markup Language is designed to fill a niche that is not easy to fill with any of the other tools mentioned above. You can do it with those tools, but it isn’t easy, and I need it to be easy. AML is designed to let you build part of your application using native code—exactly how much is up to you—and then pull the rest of it from a dynamic external source, without any break in visual style or performance sacrifice (other than the obvious one of accessing data over a possibly slow network).

Application Markup Language, or AML, is a simple XML-based language that allows you to easily build a clean, functional, native application for your mobile device.

Now, granted, this project is still so young that the test code I have written isn’t even online yet, but I have enough working code (see the Examples page for screenshots) that I am confident of at least the level of success I need, and possibly well beyond that.

AML has three main use cases, each of which is appealing in its own way:

  1. You want to build an app that is fully native, and completely defined by and executed on the mobile device, but you want to escape the native code logic and layout design process as much as possible. In this case, you would just be using the AML library and scripting language as a shortcut, though some of your own native code would still be required.

    This is the “lazy programmer” use case. (All the best programmers are lazy, right?)

  2. You have a modular web application that is constantly undergoing revisions and incorporating new modules. You want a mobile version of said application, but you don’t want to have to update it, rebuild it, and push new versions to all your users every time you get a new application. You also want to avoid the fragmentation that would inevitably occur if every web app module ended up with its own stand-alone mobile app.

    So, you use AML to build an app that provides centralized and secure local data storage and an authentication mechanism against your web app user table, establish some coding guidelines, and then have each module provide its own bit of AML as it is built. The app rarely needs updating, but still grows along with the web app because the web app code is providing the AML. Most importantly, the mobile app looks completely native because, to the end user, it is native. The AML library is interpreting the markup into device objects. This is the “growing web app” use case.

  3. You want a mobile version of your website, but you want it to look and feel native on whatever device is being used. You could just build a mobile version in HTML5/CSS3, and that might be the best solution. But for data-heavy sites that might fit well into an actual mobile app instead of just a website, you can go a different route and build your mobile site in AML instead, and use an AML browser to view it natively. This is the “AML browser/WML revisited” use case.

    4. Use cases #2 and #3 are my personal favorites. As for #3, I plan to build an AML browser as the first proof-of-concept AML app, even if it never sees widespread use (which it very well may not). The WAP/WML standards were designed a decade ago for cell phone browsers that are positively ancient by today’s standards, but they were put there to fill a valid need. That need is no longer here, but there may be a market for something that is a little more modernized.

    HTML5 is coming along great on mobile devices, especially tablets, but some users don’t do so well with the relatively small screens that are on many mobile phones. The text is too small, or the input is too precise. People want small phones to stay small, because they’re more convenient that way. But they want lots of content available at the same time. Data presentation and visibility is always a trade-off. Pinch-zooming is awesome, but it gets annoying if you have to do it all the time. What if browsing some mobile websites could be as easy as browsing through your phone settings, or your contact directory? Now that would be a pleasure to use. If an AML browser took care of the device end, web developers could simply write AML markup and automatically feed it to visitors depending on the user agent.

    On top of that, a single block of AML content can describe an arbitrary number of pages, so you could send the entire non-dynamic (i.e. no search results or data object details) portion of an AML-scripted website all in one HTTP request, and browsing between those pages would be instantaneous.

    As for use case #2, that is the reason I started this project in the first place. I already have a web app being built in exactly this way. I don’t want to simultaneously develop the entire diverse feature set on the web and on the mobile device separately if I can help it. I also don’t want to have to go back and make changes to the app every single time there is a new web app module created. So, AML was born to solve the problem. If you’re interested in the features I have written and still need to write, you can check out the Roadmap page for more info.

    Strengths

    • Free (entire library is open-source)
    • Code library is relatively simple and easy to read if you are familiar with the native platform language
    • AML script rendered to 100% native objects created by native AML library code
    • No runtime interpretation from a different scripting language such as Ruby, Python, etc.
    • Easy to modify or extend the library within your own apps if desired

    Weaknesses

    • Requires knowledge of native platform language to incorporate into your apps
    • Does not cover the complete feature set of the native device, only a subset
    • Currently Android-only (iOS and Windows Mobile planned)
    • Currently very early stage of development

    Development Requirements Summary

    (NOTE: No available download currently, goal is to have code up by the end of 7/18/2010)

    1. Install desired platform SDKs
    2. Download AML library code for desired platforms
    3. Extract files into relevant app folder structure

    Deployment Requirements Summary

    1. Follow official SDK build/deploy instructions for desired platforms

    Overall

    I like AML, but that’s because it’s my project. I have already come up with my own uses for it. I know that other tools will be vastly more beneficial in many cases. I was greatly impressed particularly with Titanium, and if I come up with an app idea aside from the needs I already have, I’ll probably try using that. I understand that what I’m trying to accomplish can, with enough effort, be done using raw native code or some of the other frameworks, but AML’s purpose is to make it easy—to fill a hole of missing simplicity in the mobile development landscape.

    Verdict: AML can be a great solution for specific kinds of situations, as mentioned above. If your app fits into one of those categories and/or you think you can use AML to meet your need, then go for it. If you’re building a game, this is probably the wrong tool. If your app is not dependent on very dynamic data presentation from a remote source, then there may be easier solutions (perhaps Titanium).

    Comparison Table

      App Inventor DroidDraw Rhomobile PhoneGap Appcelerator WebView AML
    Mobile Platform Compatibility
    Android Yes Yes Yes Yes Yes Yes Yes
    iPhone/iPad No No Yes Yes Yes Yes Planned
    Windows Mobile 6 No No Yes Maybe No Yes Planned
    Windows Phone 7 No No Maybe Maybe No Yes Planned
    Palm No No No Yes No No No
    BlackBerry (RIM) No No Yes Yes Planned Weak No
    Symbian No No Yes Yes No No No
    Development Environment OS Support
    Windows Yes Yes Yes
    (no iPhone)    		 Yes
    (no iPhone)    		 Yes
    (no iPhone)    		 Yes
    (no iPhone)    		 Yes
    (no iPhone)
    Mac Yes Yes Yes Yes Yes Yes Yes
    Linux Yes Yes Yes
    (no iPhone)    		 Yes
    (no iPhone)    		 Yes
    (no iPhone)    		 Yes
    (no iPhone)    		 Yes
    (no iPhone)
    Framework Features
    App language Visual blocks n/a Ruby/HTML, Native HTML/JS, Native Javascript, Native HTML/JS, Native AML, Native
    Native code access No n/a Yes* (extensions) Yes* (extensions) Yes* (extensions) Yes Yes
    Native look & feel** Yes Yes Yes No Yes No Yes

    *The native device code for all of these frameworks is easily available, since they are all open-source. However, for some of them, you will not normally be writing any code in the device’s native language. You would only need (or want) to work with that code in the event you need to create your own library extension to accomplish something not currently possible with the available framework code.

    **By “Native look & feel,” I am referring to the usage of individual native UI components such as input buttons, text boxes, lists, etc. While a WebView itself is a native component, it simply displays HTML, and if that’s where most of the app is running, then I don’t count it as truly native.

    Well, there you have it. If you disagree on any points, or you feel I’ve left anything out or compared unfairly or incorrectly, please let me know in the comments or on the Feedback form. I’m looking forward to the responses!