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

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.

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.

Deployment Requirements Summary

Connect phone to computer

Within App Inventor, click Package for Phone

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 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

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

Deployment Requirements Summary

Generate XML layout content

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’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

Deployment Requirements Summary

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.

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

Development Requirements Summary

Install Java Development Kit (required for Android and BlackBerry deployment)

Install Android SDK (required for Android deployment)

Install iPhone SDK (required along with Mac for iPhone deployment)

Install BlackBerry JDK (required for BlackBerry deployment)

Install PhoneGap

Deployment Requirements Summary

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

Build app for desired platforms

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’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

Deployment Requirements Summary

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

Weaknesses

Development Requirements Summary

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

Deployment Requirements Summary

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 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:

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.

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.

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.

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

Deployment Requirements Summary

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!

76 comments

Thanks for the heads-up! But could you be more specific? As far as I can tell, the ones that are duplicated are left in on purpose (since they apply to both frameworks). Which one(s) do you believe should not apply to PhoneGap?

I am working on a similar thing (thesis on “mobile cross-platform applications”) so am getting quite familiar with all the cross-platform solutions you mentioned. Sent you some information on Phonegap via Twitter.

I’m writing a thesis on “mobile cross-platform frameworks for enterprise apps”. I’m very interested in your thesis as a point of reference ans also in its results. Is it finished yet? Has it been published, to I can reference it? Can I get a copy somewhere?

As far as I know, DroidDraw is the only major player in this arena. There is supposed to be some kind of a graphical UI editor available in the Eclipse ADT plugin (which you have probably installed), but I don’t know anything about it. Check out this link for a little info:

I am new in iphone development. I have one task in phone gap application in iphone. I have created one UIViewController in that phone gap application from that i want to call the values of the UIViewController in phone gap application.

IN simple words i want to get UIViewController values in phone gap controller by the custom user plugin..

1.) you can write native and use as much of it (or not) as you want
2.) phonegap utilizes ruby scripts but DOES NOT bundle nor run with the ruby vm
3.) phonegap IS NOT built on ruby. it is built on the native SDK’s per platform.

I apologize for getting that wrong (and on a significant level, not just a little detail, no less). I have updated the article and removed the things you pointed out, and I will be re-researching your platform.

Thanks for the recommendation! I have actually already had one of the developers from appMobi contact me about the very same thing not long ago. That’s two votes for the same tool, so I will definitely be looking into it. I’m wrapping up a week-long trip, but when I get back to my regular routine, I’ll check it out.

You were really good about pointing out that you can avoid Ruby if you want to with Rhodes (you could just write your app in HTML/CSS/JavaScript as other frameworks allow). But as you pointed out then you miss out a lot of the power of Rhodes.

To be specific that power is the availability of the Model View Controller pattern, which is so dominant for every web language. Rhodes is the only smartphone framework with MVC.

Our experience is that just about every enterprise app needs sync. And just about every web developer (which is our target audience) appreciates the value of MVC.

For sure it is a pain to install all the device operating system SDKs, regardless of the framework you use. This is why we are so excited about the RhoHub Development as a Service for mobile. Something like it is long overdue in the mobile world.

Again, great article. Would also love to brief you on RhoHub 2.0 coming out in two weeks.

Thanks! I’m glad you like the summary. I noticed that nobody else had the MVC thing going on with their frameworks, and for those able to take advantage of that approach with Rhodes, it will be a great benefit.

I’d be interested in RhoHub 2.0 if you have some resources available. Even what you have up now certainly makes the process simpler than doing it the normal way.

[...] Importance of Multiple Options I recently finished up an article summarizing the differences between a few of the mobile application development frameworks that are in existence today. I covered three major players, two individual platform-specific tools, [...]

I’m still not with you on some points:
“Native code access”, “Native look & feel” ans “Base language”.

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 harder is to make this native code functions available to the HTML/JS part, but that’s what the wrapped APIs do. So you can copy this – and it has been done by a lo of people for differenc´t functionality.
If you see it this way, Phonegap is stronger on native code access than WebView.

Also the native look and feel of the web view is basically not there, as it isn’t with Phonegap. You have to make the HTML look like native interface, but this is never going to work as good as the original.

Yeah, and as I see it the base language of the WebView isn’t native, but HTML/JS for the application. So yes, the WebView is done in native code, but the application itself is done in HTML/JS. Perhaps you should distinguish these two types.

Sorry if this sounds nitpicky, but it’s a complicated thing and still very much in progress, with lots of misinformation floating around.

No problem about being nitpicky. It is important to be so when there are many little details in question that may change someone’s framework usage decision.

I have added a little more clarification (and quoted your comment here), and changed a bit of the language in the comparison table. Hopefully there won’t be any more confusion, but please continue to let me know if there is.

Sorry, it looks like I missed the most important bit to respond to. Rhodes for provide native code access. It’s not done by allowing you to edit generated underlying Objective C (or other language) code (which is of dubious value since you lose the ongoing benefit of working with a framework once you do those edits). In the rare cases that we don’t expose an API for what you want to do, we allow (encourage even) you to create your own Rhodes extension. Our latest webinar covered this (up on our vimeo channel) and it’s in the Rhodes Developer Reference.

This approach is much more amenable to utilizing the full lifecycle benefits of the framework than treating the framework as just an initial code generator. That “native code access” box should definitely be green for Rhodes.

Sorry for the confusion. I believe I understand what you mean, and I have adjusted the comparison table at the bottom as directed (with a bit of extra info below it that should have been there in the first place). Thanks for the clarification!

[...] 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). [...]

Pretty comprehensive write-up, hopefully it will be helpful to folks. Couple clarifications about Titanium (Appcelerator is the company, Titanium is the product):

- PHP, Ruby, and Python code can only be written for Titanium Desktop apps, not mobile apps
- Your app’s JavaScript code is interpreted at runtime on the device (otherwise dynamic language features would break), but any calls to Titanium APIs are passed through to our native layer, which makes the performance of these functions almost 1:1 with invoking them directly.

[...] I’m really impressed with this open source library. It’s event based javascript as well, with proxies and stuff to turn completely native. It makes so many things extremely simple that are usually a pain in the ass to do natively on both platforms. It’s still kind buggy and only supports iOS and Android at the moment, but the native builds really feel native. I like their approach to the cross-platform issue, where they try to keep things as unified as possible, but don’t let that limit themselves, so they also take advantage of each platform’s individual features. They have a module SDK so you can stick actual Objective-C or Java in there if necessary, and apparently they’ll be launching a module marketplace soon, along with Blackberry support. Here’s a great overview of the different cross-platform options. [...]

what a great article , thank you. I am new to the app development world and am a bit confused over the terms native feel and look. iby understand of your article and the responses are that html code can be made to look like a native app (i.e in phonegap) but does that include drop down menu’s which are part of the iphone user experience? also which is better to program a app which enables the user to purchase items through an app – phonegap or rhomobile? i understand this is a very generic question to any tips / hints would be useful.

Glad DroidDraw was useful for you! What I was referring to was line breaking if your text was too long for the size of the TextEdit. Currently DroidDraw doesn’t allow you to enter line breaks in the text affiliate programs
(maybe in the future)
Thanks

Hi, thanks for a great work! It is impossible to put all the facts 100% accurate but it gives a very good overview of the available options.
Shame on the Phonegap guy by being rude, wtf. Your overview of Phonegap is by far much better than theirs on their own site.

Hi, regarding Appcelerator. It i stated that: “Generates real native source code as part of the build process, accessible to developer”.

While making an app for Android I’ve only found some system java and class files. I can’t find any native code generated from the js used for the app. Furthermore unzipping the apk file you can find the original js files used. So I don’t know how native that can be…
I guess all run on the webviews.

Yes, I suspected that the comparison table will be incorrect on this. It says Appcelerator have “Native look & feel,” which he further comments on: “[by stating this] I am referring to the usage of individual native UI components such as input buttons, text boxes, lists, etc.” The only way this statement could still hold true is if Appcelerator would then generate native UI runtime from JavaScript — anyone knows if that is the case??? (also I’m not sure about Rhodes and the rest…)

Hi,
You have said that RhoMobile applications “runs entire app through bundled RubyVM interpreter”. Is this true? I haven’t read this anywhere except your article. I thought RhoMobile created native code from Ruby code using the concerned platform’s SDK. Please correct me if I am wrong?

The executables contain an embedded Ruby interpreter, a lightweight web server, and a simple shell with a native HTML rendering component that is used to display the content. These components are all executed from within a self-contained application, so the user doesn’t need to depend on an external runtime component. This approach also ensures that Rhodes applications fully conform with Apple’s draconian App Store requirements, which broadly prohibit conventional interpreters.

Rhodes does in fact contain an implementation of Ruby. However, it embeds a mobile optimized Ruby 1.9-based intermediate bytecode executor that operates on precompiled Ruby code. Also, for good measure, we have eliminated the ability to do dynamic creation of code (such as removing “eval”). We want to make sure that application developers can only create applications with behavior that is known a priori.

I believe the statement about the Ruby VM interpreter is correct, but I might be misinterpretering (heh) something.

Great article. But, a quick question on AML use case #2. I have read about Apple rejecting apps for interpreting and generating native code on the fly (e.g. Briefs prototyping app for iPhone giveabrief.com). So, will the use case #2 not result in app rejection?

To be honest, I’m not sure. It’s a valid concern though. I think it might depend on how varied and how possibly different the behavior can be based on the AML markup. After all, what is any dynamic app if not something that interprets dynamic data into native code? Business-logic apps would be largely pointless in many cases if they didn’t change behavior based on unknowable future changes in data. I have to imagine there is some middle ground where you could still use AML in an official iPhone app. However, I’ve never tried to get an app approved before, so I’m not really sure.

There are always non-official distribution venues for jailbroken devices, too, but of course that greatly shrinks the target market size. I certainly hope that wouldn’t be necessary.

For what its worth, we do include a Ruby 1.9 intermediate bytecode executor that runs your controller code. It is not strictly speaking an “interpreter” since it doesnt use high level languages. But it is a native app and all of the device capabilities and user interface are not executed by the Ruby executor (just your controller business logic that you write in Ruby).

Hay, just wanted to show you guys the capabilities of app inventor, all of my apps were created using app inventor. Go to my website http://www.swelloapplications.com/ and click the android guy and it will take you to see them, if you would like. Also if you have any questions on them feel free to contact me via the contact us on my website!

I can’t blame you for saying so. Perhaps “cryogenic stasis” would be a better way to put it. All of my effort has been elsewhere for the last nine months, and the original impetus for AML was a work project that has been slipped out until further notice. As much as I’d like to work on it more, there are too many other things higher on the priority list to devote time to this. All the code is available if you’d like to contribute though…

very nice article that in part reflects my thoughts about the subject. my conclusion was very near as well, but i thought about using an extended html(5) rather (ie. with data- attributes) than inventing a new markup language

[...] a programming language not too difficult to comprehend like html, css, javascript. There are plenty of cross-platform tools out there but they have their drawbacks. At the end of the day I settled on something I used back [...]

In summary, it is a cloud-based dev platform that does mobile (all important platforms) and desktop on an equal footing. It’s got an IDE that does drag-and-drop / wysiwyg UI bulding as well as code editing. I guess you could describe it as Visual Basic in the Cloud, but Javascript not Basic. Widget based like VB was, extensible. Open Source with free platform offering.

[...] 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 [...]

Resources

AML Discussion

AML Donations

Feeling generous, and want to help me get more hardware to continue developing this library on multiple platforms? I have a Droid already (actually a Milestone on AT&T), but I could still use an iPhone and a Windows 7 Phone for testing. Help if you can, don't if you can't or just don't want to.