Adobe Acquires Nitobi

So if you haven’t heard yet, Adobe acquired Nitobi, the company that is responsible for PhoneGap. This was announced at Adobe’s big MAX conference. If you are unfamiliar with PhoneGap, then this post is going to be wildly uninteresting to you. At a high level, they provide a cross platform mobile development solution that leverages native webviews with HTML5, CSS, and Javascript to create native mobile apps.

Not Hard To See Coming

Well, for one thing, Adobe was obviously hedging its bets on Flash/Air’s viability in the long term with mobile when they started introducing HTML5 capabilities through Edge. I mean, if Adobe’s planning to offer interactive, Flash-like development with HTML5, who is going to believe that Flash itself has a real future with mobile? Or as Gizmodo put it, Adobe Edge may become the beginning of the end for Flash. Yeah, it will likely always exist, but it is not the de facto standard for delivering interactive web (or mobile) content anymore.

And of course there’s the whole Adobe Air for mobile thing. Android was obliging enough to make Air a first class citizen. Install Air, run Air apps… simple. And while the Adobe Air install is a bit hefty, it’s hardly something worth worrying about with today’s storage capabilities on mobile devices.

“Flash has been labeled an outlaw and Air is smuggled in like an illegal immigrant”

The more harrowing journey for Adobe has been iOS. Basically, Flash has been labeled an outlaw and Air is smuggled in like an illegal immigrant. There’s been a staring contest between Adobe and Apple for a while now, but I think it’s safe to say Adobe blinked. Apple has continually proven that is has the most marketable mobile devices available, and has done so without any back pedaling on what they will and will not allow (minus letting 3rd parties build apps).

Something had to give if Adobe was going to get a real foothold in the mobile world, and it obviously wasn’t coming in the form of their current solutions. Enter PhoneGap…

But PhoneGap is not Without Its Challenges

Image by

PhoneGap fills a lot of holes for Adobe, but its going to need a lot of help itself. I think PhoneGap has gone about as far as it can on its own. It has achieved its goal of abstracting most native functionality for many different mobile platforms, but starting developers are wanting more.

PhoneGap has no user interface components. This is not fun for new developers… or veteran ones for that matter. You need to build everything from scratch or go out and find a UI framework that works for you. The 2 front-runners, Sencha Touch and jQuery Mobile, bring their own glitches and idiosyncrasies. Also, now you find yourself learning 2 frameworks that have a noticeable lack of cross-over documentation.

There’s also a seemingly purposeful lack of direction in terms of tooling and best practices. New developers, often web developers, are left to their own devices to find the workflow that works best for them. There’s no sanctioned IDE or set of tools suggested from PhoneGap to build your mobile apps. Infinite flexibility can be a real drag when you just want to know the most effective way to get things done.

But let’s put this even more plainly…

What are the pros and cons of PhoneGap?

And what are the pros and cons of Adobe?

Anyone else seeing a pretty clear yin-yang thing going on here?

So What Does It All Mean?

Well, for one thing, it means PhoneGap is becoming an Apache project. Yep, they are donating PhoneGap to Apache, which puts them one step closer to their altruistic goal of PhoneGap itself becoming obsolete. PhoneGap’s own Brian Leroux stated in his PhoneGap 1.0 presentation that:

“The purpose of PhoneGap is for PhoneGap to cease to exist”

Why, oh why, did Adobe buy it then? I think it’s because they want to be your one stop shop for purchasing IDEs, frameworks, professional services, etc… Adobe is likely banking on the ongoing popularity of PhoneGap and web-based native mobile development. “Web-based native”… sounds a little like an oxymoron, but whatever.

A Match Made in Heaven, Right?

Sounds like a perfect match. The 2 companies seem to complement each other very well. But…

There’s just a few questions I still have regarding the acquisition. Rather than drone on any longer inserting my own conjecture, I’ll just list my questions here and leave them as talking points for you, my readers.

“I can already hear the `It’s back to AS1` complaints starting…”

• What happens to Flash/Air for mobile? It obviously won’t be forsaken, but this can’t sit real well with developers who have so far devoted themselves to this workflow.
• How does Adobe deal with the inevitability that current developers will revolt against using Javascript? I can already hear the “It’s back to AS1″ complaints starting…
• Does Adobe even have any interest in getting existing AS3 developers using PhoneGap? I know they are saying that they weill support both solutions, but come on, someone is gonna get more love than the other.
• How long until we finally see a defined workflow and IDE for PhoneGap. Is Dreamweaver integration the best we get?
• What will the PhoneGap guys do next? They are actively working to put themselves out of a job, so I’m curious what the next move is.

What’s Next?

I have no clue, but it’s sure to be interesting. I’m hoping for good things on both sides as it’s only going to make mobile development in general more exciting.

Will Adobe’s ability to create great tools translate to mobile success? Will PhoneGap’s strict adherence to the open web model jive well with Adobe’s history of closed, proprietary tools? Will the inevitable merge of the open web and existing Adobe community be a bumpy one?

Stay tuned…

CORE

For the sake of not repeating myself I’m going to refer to the phrase “code once, run everywhere” as CORE from here on in. Who knows, maybe it’ll catch on. And on to the blog post…

So as you may have heard by now, I’ll be starting my new job as an Appcelerator platform evangelist on Monday. If you’ve read some of my past blog posts, you’ve probably noted that I’ve been pretty critical of cross platform mobile solutions. From a developer’s perspective, we are expecting the coveted CORE, but are often left wanting.

What you’ll quickly find in the world of mobile development is that cross platform does not always equal CORE.

Rather than bemoan the shortcomings of each mobile framework, I’d rather talk about something I heard say during the Appcelerator online training videos. He stated that Appcelerator does not aim to be a CORE technology, but instead a “code once, adapt everywhere” one. Not quite as sexy, but perhaps an even more intriguing philosophy. Let’s discuss why.

Web Based vs. Appcelerator

For a quick summary of how Appcelerator is fundamentally different than web-based cross platform mobile frameworks, read here.

Aside from near-native performance, what’s the biggest advantage of using Appcelerator over web based mobile frameworks like Phonegap or Rhomobile? Its ability to use the device’s native UI components. And no, I don’t mean it has UI components skinned to look like native components, like many of the web-based solutions. I mean it actually uses the platform’s native, performant UI in the app.

With native UI we can build apps that are indistinguishable from apps built with Objective-C or Java. The look, feel, performance, and behavior will be exactly what is expected of the given platform. Plus, we don’t have to build them ourselves.

To achieve this level of quality, though, you need to be willing to adapt your app, not just design for the lowest common denominator, as is often the mentality with CORE apps. Sure, you can use the iPhone’s slick Navigation Controller bar on all versions of your app, but is that what Android users are expecting? Nor would an Android Spinner be befitting of an iPhone app.

You see, in some cases, CORE apps come at the expense of the most important factor: the user experience.

Why Bother?

Many people, particularly proponents of web based mobile development, are of the opinion that native UI components are not necessary to deliver a high quality user experience. I agree, in certain circumstances. Games, novelty utilities (think Flashlight), and otherwise simple apps are good examples that probably don’t benefit much from a native experience.

In my opinion, though, it’s a necessity for more complex apps, particularly ones leveraging native APIs, to use the UI that is familiar to the device. They need to work in a simple, intuitive manner as mobile users can be quick on the trigger in deeming an app unfriendly. Those who have spent time developing for multiple platforms understand that the users of each platform have different expectations.

I don’t want a navigation bar in my Android app. I want my tabs at the bottom on iPhone, the top on Android. I want to press my menu button on Android to get my app’s options. I want my system buttons to look familiar. I want to pull to refresh on my iPhone.

Let me be clear that both Appcelerator and web-based frameworks have the ability to adapt their apps to supported platforms. And I don’t just mean churning out a basic app, I mean creating a high quality, native app. Depending on your point of view, however, one may be much more appealing than the other.

Attending to the UI (Web-based)

With web-based solutions, the app exists in a web view container. This means that you are effectively building a native app that consists of only a web view which hosts a web application. You have no native components with which to work. This leaves us with 2 options for building the UI of the app (super quick assessment coming):

1. Use a 3rd party framework like jQuery Mobile or Sencha Touch
   • Pros
     • Lots of functionality and UI components
     • Speeds up development process
     • Some, like Sencha Touch, have a very native look to their components.
   • Cons
     • Web based framework UI is generally less responsive than ones created natively or with Appcelerator on mobile devices.
     • Additional learning curve for the added framework
     • You are even further removed from the native app. You now have a UI framework which sits on a native web view wrapper which then becomes a native app. Lots to know and lots of places for things to go wrong.
     • Frameworks like Sencha Touch are limited to webkit based web views (iOS, Android, BB 6.0+). This essentially removes the biggest advantage of web based frameworks, which is their compatibility.
2. Create the UI yourself with HTML/CSS/JS
   • Pros
     • Totally customizable for any platform
     • Its easier to manage performance and UI inconsistencies when using code for only what you need to achieve
     • No additional learning curve beyond basic web dev and understanding your web based framework of choice.
   • Cons
     • Much slower to develop, as you have to build your UI from scratch. The styling of the UI to look native all falls on you or external resources you can find.
     • Even for seasoned web devs, managing cross platform mobile CSS can be a daunting task.
     • All cross browser inconsistencies become your job to address, unless you use a light JS framework like xuijs or zeptojs.

So as you can see, web based mobile development encounters many of the same issues that traditional web development does. And the problem is compounded when you are trying to make these web based solutions look, feel, perform, and behave natively.

Attending to the UI (Appcelerator)

Appcelerator apps are built differently. The extremely short version is that Appcelerator Javascript code is mapped to native symbols of the target platform. Any code that can’t be mapped to a native symbol is run through a Javascript interpreter. , CEO of Appcelerator, does a much better job of explaining it in this StackOverflow post.

What this means that there are no 3rd party tools or special code necessary to create totally native components. You want a button that has native appearance and behavior on both iPhone and Android?

var button = Ti.UI.createButton({title:'test button'});

There you go, an Android and iPhone button respectively. How ’bout a table view populated with sample data?

var data = [{title:"Row 1"},{title:"Row 2"},{title:"Row 3"},{title:"Row 4"},{title:"Row 5"},{title:"Row 6"}];
var table = Titanium.UI.createTableView({data:data});

Yep, it’s that simple. The iPhone table will even have the bounce scrolling users expect. You have the same simplicity that web based UI frameworks solutions provide, except you are additionally getting native look, feel, performance, and behavior. The components are even designable as you would expect them to be.

The one drawback to this simplicity is that without careful attention to your code, you can end up with a mess of interlacing UI and logic. Android has XML for layout, iOS has .nib/.xib files, web based solutions have HTML/CSS. Appcelerator, for the time being, relies solely on your Javascript code. Javascript MVC frameworks, like PureMVC, and attention to best practices (as mentioned in the online training videos) can mitigate this risk. There are even some vague rumblings of a more declarative syntax for UI design in the future…

Adaptation

So now that we know how UIs are built in both Appcelerator and web-based frameworks, how do we adapt them in such a way to deliver a native user experience? Despite the differences between the frameworks mentioned so far, the solution is fairly common among all frameworks.

While I will confidently say that Appcelerator has the abstraction that delivers the most familiar and device-specific experience, it too needs to account for usability that is not necessarily CORE. And even saying it is not CORE can be a bit of a misnomer as the same code base can be used by multiple platforms. It just requires the clever and judicious insertion of platform specific code facilitated by your mobile framework’s device identification APIs.

Let’s take a quick look at how Appcelerator identifies your device and can act on the information:

var osname = Titanium.Platform.osname;
if (osname == 'android') {
    // android specific code
} else if (osname == 'iphone') {
    // iphone specific code
} else if (osname == 'ipad') {
    // ipad specific code
}

For a more in depth example of how you can use this logic to create truly cross platform components and functionality, check out the 6 minute screencast “Forging Titanium: A Cross-Platform Navigation Controller.” Or just watch this:

And for reference, let’s look at PhoneGap’s adaptation method as well, just to show the similarities:

var platform = device.platform;
if platform == 'Android') {
    // android specific code
} else if platform == 'iPhone') {
    // iphone specific code
} else if platform == 'BlackBerry') {
    // blackberry specific code
}

Very similar indeed, but you need to consider the 2 prior “Attending to the UI” sections before calling them equal. Its the frequency with which you are required to apply this and other types of adaptation that affects the maintainability of your app as it grows.

Minimizing Adaptation

It doesn’t take an expert software engineer to see that conditional checks on the device’s platform throughout your code isn’t ideal. It gets harder to maintain the more conditionals you include. It becomes apparent that we need our development framework to do most of this work for us.

In the case of Appcelerator, the need for conditional adaptation is minimized by the fact that you can utilize native UI components. Look back at our examples of the buttons and table views. There was no conditional code, no special handling. You get system specific components with no extra effort.

You really only need conditional code when you want to leverage native components that don’t have an equivalent on your other target platforms. For example, if you haven’t already, check out the Cross-Platform Navigation Controller video above. It shows how you can use these conditionals to create navigation code that you can use seamlessly between iOS or Android.

Web based platforms also do a great job of creating an abstraction so that you don’t need to use conditionals for each supported platform. The problem, as discussed earlier, is that these abstractions don’t represent actual native components. They most often represent HTML/CSS/JS that are attempting to mimic native components. Worse yet, sometimes they are components that have no relation to existing native components, yet find themselves in native apps. As I said, this is a point of contention among mobile developers, and I’ll leave further discussion for the comments if necessary.

What web based frameworks can’t give you in native components, they provide in CSS, often applied dynamically via Javascript. The use of CSS is a double-edged sword. On one hand, you have a method of styling that not only allows you to skin your whole app, but also affords you the opportunity to gracefully degrade the styling based on the user’s device. This is why web based solutions typically support more platforms than ones like Appcelerator. Add all the bells and whistles like rounded corners, drop shadows, webkit transitions, etc… and if the device doesn’t support them, they will disappear without interrupting the user experience.

On the other hand, unless you are a CSS wizard with existing knowledge of CSS3 and how it applies to mobile, using it can be difficult. You can find yourself with mountains of CSS attempting to mimic components that are created with a single line of code in Appcelerator. For example, here’s a shiny iPhone button in pure CSS:

input[type=button] {
  font-family: "Helvetica Neue", Helvetica, sans-serif;
  font-size: 1.3em;
  font-weight: bold;
  width: 97%;
  height: 50px;
  border: 3px solid #282726;
  background: -webkit-gradient( linear, left top, left bottom, from(#e2e2e2), to(#8c8a88), color-stop(0.5, #acadae), color-stop(0.5, #82807e) );
  margin: 0 0 3px 0;
  text-shadow: 0px 1px 0 #cecece;
  -webkit-background-origin: padding-box;
  -webkit-background-clip: border-box;
  -webkit-border-radius: 8px;
}
 
input[type=button]:hover, input[type=button].cancel,
input[type=button]:active, input[type=button].cancel:active {
  color: #fff;
  text-shadow: none;
}
 
input[type=button]:hover, input[type=button].cancel:hover {
  background: -webkit-gradient( linear, left top, left bottom, from(#aaaee5), to(#10006d), color-stop(0.5, #1F3B97), color-stop(0.5, #081f6f) );
}
 
input[type=button].cancel {
  background: -webkit-gradient( linear, left top, left bottom, from(#5c5c5b), to(#1e1b16), color-stop(0.2, #1e1b16) );
  margin-top: 6px;
}

It does the job, but man, it is really cumbersome. Again, this is all a factor of wanting to create a native experience. Some will contest that it does not need to be this complex, that as long as the UI is uniform it does not need to conform to the native expectations. This mentality, though, is typically only held by those who back mobile frameworks that are incapable of delivering that native experience. As the local radio sports caster in Pittsburgh likes to say, “Not hatin’, just sayin’.”

Summary

You can’t beat web based mobile development for platform compatibility. Every mobile device has a browser that supports HTML/CSS/JS, right? You can create UIs that work on many platforms and degrade gracefully to handle lower end devices. Quality, usable apps are totally possible with these frameworks.

But the user doesn’t care how compatible your app is. They just want it to work, as they expect it to, on the device of their choice. In this respect, Appcelerator is unparalleled in the realm of cross platform solutions.

I have a strong suspicion that web based mobile technologies are only going to get better. I mean, let’s face it, the web isn’t going to be disappearing anytime soon. It will get faster, more functional, and closer to the expectations of the mobile user, just like desktop web browsers. And I, as a soon-to-be Appcelerator employee, welcome this.

As web based mobile development ups it game, so shall Appcelerator. Whether you’re an Appcelerator, web based, or native developer, it’s an exciting time… no matter what side of the fence you’re on.

Update 7/29/2011

Searching for the Silver Bullet

So if you haven’t already figured it out, I’m gunning to decide once and for all on a cross platform mobile development framework. While all the Flash gurus I know are singing the praises of the latest versions of Adobe’s mobile platform, I don’t have the patience for an official release and docs to surface. That leaves me with two options among the frameworks I’ve evaluated: PhoneGap and Appcelerator.

If you are interested in my past evaluations, check out these prior posts I wrote:

• A Deeper Look at Appcelerator and PhoneGap
• PhoneGap is Web-based. Appcelerator is Pure Javascript
• Appcelerator vs. PhoneGap vs. Adobe Air

Now judging by those past comparisons, it’s pretty clear that each framework has its place. It doesn’t have to be one or the other. Or does it?

I’m Only One Man

There comes a time after evaluating platforms, tools, and anything else when you have to make a decision. Especially is you are an indie developer like myself. You can end up diluting your potential impact on your target field by trying to be a jack of all trades, master of none. It turns out its a lot more effective to be a jack of all trades, master of at least one.

So I keep circling back to “Appcelerator or PhoneGap?” I’ve done the technical comparison and neither is the wrong choice in any respect. Both have incredibly intelligent people spearheading their development, great productivity tools, and continuous updates and improvements to their framework. So what does it come down to?

• Which one do I spend the most time in?
• Which one do I start pouring my effort into?
• Which one do I start contributing back to?
• Which one do I think is looking out for me, the indie developer?
• Which one, if it went belly up today, could I continue to use and bend to my needs?

As I asked these questions of myself, I found that I was leaning towards PhoneGap. I will say, though, that this is in no small part to how strong the PhoneGap crew’s Twitter presence is. Here’s a list of PhoneGap people to know. I am a Twitter junkie () and being able to ask questions and get near-immediate responses definitely swayed my thinking. They do, in general, with their MIT/BSD license and github’ed everything seem like they side with the developers more than their competitor in this case.

But damn are the native UI components and pure Javascript interface of Appcelerator sexy. I’m not a web developer by trade, so the pure JS appeals to me more than needing to know the finer points of the HTML/CSS/JS stack. And the tools they have are top notch. But that’s where my decision started to be made…

Making My Decision Easy

I just needed a definitive nudge in either direction really. Something the resonated with me and said, “This is the framework you should be using.” Appcelerator gave me that nudge, but not in their direction.

I just received an email from Appcelerator touting their new official release of their Titanium Studio. Its a great piece of software that allows you to create an Appcelerator project and deploy it to multiple mobile platforms. Sounds great, right? I thought so too, until I read on.

Upgrade to Titanium Indie or Titanium Professional to get a full mobile debugger.

Just for reference, that means $49/month for the Indie subscription and $199/developer/month for the Professional subscription. So at its cheapest rate, I’ll be expected to pay almost $600 a year just to debug my mobile applications. That is not something I’m willing to pay.

On the other hand, PhoneGap is currently working with the author of , , to incorporate it into the PhoneGap project. Yes, that’s right, they are working to integrate mobile debugging into their framework for free. Pretty clear to see what an OSS supporter like myself is going to like.

Cheap Bastard

I know what you might be thinking, “Damn, he’s a cheap bastard who isn’t willing to shell out cash for decent software.” Well, yeah, and I’ll bet a lot of my readers are pretty much the same way. But it goes beyond that. It feels a bit like a bait and switch.

They offered Titanium Developer as a means to developer Appcelerator projects in the past. Then they tell everyone that Titanium Studio is the future, so that’s what you need to be developing in if you want to stay on the roadmap. Then they effectively pull the plug on Titanium Developer, make Titanium Studio an official release, then start charging for what I consider to be basic IDE functionality. Seems a little uncool.

EDIT: Kevin and Scott (see comments) are right. This wasn’t a “bait and switch”. Titanium Developer did not have this functionality, therefore it is not deceptive that the official release of Titanium Studio does not either. I will miss it, but it was not at all deceptive.

Soooo…

As you might imagine, my personal cross platform efforts will be using PhoneGap. That’s not to say I won’t be involved in Appcelerator development. I still think its a great way to develop iOS based apps when you or your team is lacking in Objective C and/or XCode experience. Its fast, effective, and Appcelerator nailed the iOS platform. They just rubbed me the wrong way at a critical time in my decision making process. I encourage anyone reading this to not let my assessment make your decision for you as I think Appcelerator is a good fit for many.

PhoneGap is the answer to almost all the questions I posed in my list above. I just really like the team and the open nature of the project. Plus, it lets me sharpen my web developer chops (Appcelerator dev is not web dev) while working in my primary focus of mobile development. It’s just a very good fit for me and the guys I work with on a regular basis.

In the End

Its all up to an educated choice that plays to your personal strengths and proclivities. In this case, both frameworks kinda did. But due to an intense focus on community from PhoneGap, they are going to continue to win over developers like me. Who knows, though, I’m a cheap bastard. Maybe there’s no money in catering to developers like me.

While everyone needs to pay the mortgage, I somehow get the impression that the PhoneGap crew will be OK with it if they all aren’t millionaires. They strike me as guys who strive to maintain a resonance with developers. In in that effort, I say they have excelled.

What’s The Difference?

I’ve seen a lot of confusion out there on what the actual distinction is between PhoneGap and Appcelerator Titanium in terms of programming. Both state that they provide cross-platform mobile development frameworks driven by a Javascript core.  How different can they be?  Turns out, very.

The fundamental difference is that PhoneGap is a web based solution where Appcelerator Titanium is a pure Javascript API that creates native code.  As I’ve gone over the differences between these 2 in detail before, I’m going to very strictly stick to the topic of how their code works. Since people seem to love charts so much, here’s a quick review to show the divergence between the two frameworks:

	PhoneGap	Appcelerator Titanium	Notes
Javascript API			PhoneGap’s API interacts as typical JS does in your web code. Appcelerator Titanium API is NOT web code, it is used to interact with native code.
Supports HTML5/CSS3			PhoneGap is a web app that runs in a native web browser view.
Supports Web Standards			PhoneGap looks, feels, and develops like a standard web page. It is also subject to the same browser compatibility concerns.
Supports DOM based JS libraries			JS libraries that reference the DOM, like jQuery, Prototype, or any of the new based libs will only work with Appcelerator Titanium webviews
Native Code			Appcelerator Titanium creates a truly native app via a JS API that maps to native code.
Native UI/Performance			Appcelerator Titanium performance is limited only by the device. PhoneGap’s is limited by the device’s web view.

What Does This Mean?

• Web developers will have a much easier transition going to PhoneGap than they would Appcelerator Titanium.
• Application developers without serious web development chops will likely gravitate towards Appcelerator Titanium. Why learn HTML, CSS, and Javascript when you can just learn Javascript?
• Designer work will be tougher to integrate into an Appcelerator project as all the layouts and assets are done programmatically. PhoneGap, on the other hand is effectively web development, which designers have been working with for a very long time.
• Appcelerator is always going to win on performance.
• There will be an inevitable flood of web developers calling themselves mobile developers because they are familiar with PhoneGap. Beware.
• Appcelerator has a much deeper and more complex integration with each mobile platform.
  • Pros: Native look, feel, and performance
  • Cons: Platform compatibility will be achieved more slowly. Much harder to “code once, deploy everywhere”.

Summary

The above is a hyper-condensed review of the whole story. As always, I encourage you to try both of these platforms. They both excel in many areas and offer unique features. Neither is the wrong choice, but depending on your scenario, one might be better suited than the other.

The People

As it turns out, the co-founders and core developers of PhoneGap are pretty accessible guys.  Who better to know when it comes to using a framework than the authors?  Everything from basic “getting started” questions to more complex topics from me have been addressed directly by one or more of their team.   While there’s probably a ton of people I’m not mentioning, these few guys in particular have been exceedingly helpful.

• Andre Charland ()
• Brian Leroux ()
• Dave Johnson ()
• Michael Brooks ()
• Fil Maj ()
• And the PhoneGap Twitter account ()

I’m a Twitter fiend so that’s generally where I find these guys, but make sure you also check out their and IRC.  I’ve said this before… if you are doing PhoneGap development and aren’t following this crew on Twitter, then you’re an idiot.

PhoneGap Build

So you hear about all these frameworks that do cross platform mobile development, “code once, run everywhere”, and everything just magically works.  Well… it ain’t that simple.  You’ve got SDK installations, developer & signing certificates, build chains, and custom project layouts to worry about with each platform.  While this can become a nightmare to manage, PhoneGap makes a pretty epic effort to help with their currently free, beta service called PhoneGap Build.

PhoneGap Build will allow you to give them the web code that drives your app and in return you will get App Store deployable binaries back for all the platforms listed in interface snapshot above.  You don’t have to install all the SDKs.  You don’t need to worry about any platform specific setup.  It is actually that simple.

I highly suggest setting up an account right this second, especially if you are just starting out as a mobile developer.  The time consuming, and often frustrating, nature of multi-platform testing and deployment is easy to underestimate.  When you’re learning the ropes of mobile APIs and the finer points of app creation, the last thing you want to worry about is every individual SDK’s varying degrees of compatibility.  Which leads me to my next section…

PhoneGap Generate

If you are like most mobile developers, you are a (proud) owner of the 4+ GB behemoth of a download XCode 4.  The good news is that you can build apps for iOS 4+ with it.  The bad news is that XCode 4′s default configuration settings are not compatible with PhoneGap, and it can be a bit complicated to resolve.  Here’s the bloody path I took to .

But in their constant efforts to make the build process easier on developers, PhoneGap came up with a short term solution.  Instead of hacking up your XCode 4 project files, let PhoneGap do it for you!  Enter PhoneGap Generate.  Its an extension of the PhoneGap Build site that will, given a project name, generate an XCode 4 compatible project for you.  While it’s not an ideal situation, it can save you some of the headaches I endured trying to do it myself.  Hopefully the PhoneGap distribution will have this resolved in the near future.

Cordova

Now we’re getting to the real goodies.   is without question the single biggest boost to my PhoneGap development workflow.  Think PhoneGap Build with no need for the cloud.

, in Brian Leroux’s (author) own description, is

A PhoneGap project toolchain that automates common tasks for building cross platform mobile projects with OS X.

Automate common development workflow tasks such as: compiling, debugging, testing, releasing and other things in between. As an added benefit projects generated with Cordova create a consistent, predictable, easy to understand and therefor extend software project. A number of conventions are introduced removing the need for mobile developers to relearn their tools or, worse, rebuild them for every project.

Be warned, Cordova is young and best used by those with a good understanding of how PhoneGap works in terms of project layout, building, testing, and deployment.  It also helps a great deal if you understand these concepts as they relate to each platform (i.e., Android, iOS, Blackberry, etc…) you plan to target.  And you’ll need to me comfortable with the Terminal on Mac OS.  If I haven’t scared you off yet, read on.

Basically, you can build and test PhoneGap apps for multiple platforms with simple Terminal commands.  No more creating projects in XCode or Eclipse just to conform to a specific platform.  You can choose your favorite web development IDE (Aptana for me) and do all your work there.  When you’re done, just run one simple command from the command line and it will build for iOS, Android, and even Blackberry (with a Windows VM).  Check out this short demo from Brian Leroux to see what I mean.

Yeah, its low level and it doesn’t have a pretty GUI, but man this project has massively improved my efficiency in terms of cross platform testing.  I’m hoping more people see this project and hop on board, and even contribute like I did (Blackberry support).  A tool like this can really be a game changer in terms of what a single developer can do for a mobile app spanning a multitude of platforms.

You don’t have to use Platform-specific IDEs

According to the PhoneGap docs on the “Get Started” page, I need XCode if I want to build iPhone/iPad apps, Eclipse for Android, a Windows based IDE for Blackberry, its a serious pain in the ass.  But these are web based solutions, right?  Why in God’s name would I want to endure XCode and Eclipse as web development IDEs?!  I wouldn’t, and I don’t have to.

You’ve got 2 options when it comes to developing your apps if you don’t want to use the platform specific IDEs (and you shouldn’t).

1. Develop your web code in your IDE of choice.  When its at a point you want to test it on a specific platform, copy the web code into a PhoneGap project built in the platform specific IDE.  For example, if you like TextMate, do all the web coding in TextMate and when you are ready to test it on Android, copy the web code into the assets/www path of your Eclipse Android project.  Run and test from there.
2. Use . You can do your web code in your IDE of choice and simply run ‘make debug’. In the current incarnation of Cordova, this will open your web code in the iPhone, Android, and Blackberry simulators.  Reference the for more details on usage.  In the near future I’m planning a blog post on that very subject.

The long and short of it is that the platform specific IDE workflows are not optimal for web development.  Find the tools that best suit you and your web development style, use them, and only spend your time in platform specific IDEs when necessary.  The time you save using a full featured, web-focused IDE makes up for the less-than-fun process of having to copy and paste code to platform specific IDEs.  You save even more time if you use Cordova.  Have I pimped Cordova enough yet?

The Supported APIs (per platform)

So as you probably already know, you can find all of PhoneGap’s documented mobile API support at docs.phonegap.com. What you might not be aware of is that they have done a really good job of documenting which APIs are supported by which platforms.

On a function by function basis, the “Supported Platforms” section lets you know down to the OS version which platforms support it.  The trailing “Quirks” section let’s you know which platforms may not behave as expected.  Not only that, but the “Quirks” are typically accompanied by workarounds to make your life a little easier.

If you are doing cross platform mobile development, get used to the fact that you are going to be spending time dealing with inconsistencies, regardless of framework choice.  Having documentation with this level of detail will surely decrease that time, as well as prevent you from hitting unforeseen dead-ends in your app development.  RTFM, its worth it.

PhoneGap can technically do anything

PhoneGap does its best to expose platform specific mobile APIs in a bare bones, clean, abstracted manner.  While this does create a reliable experience in development, it does leave some things you might want off the table.  The big thing, for example, is native UI components.  While “native” anything seems to be contradictory to  cross platform development, its still a common request (see Appcelerator or even this PhoneGap based solution).  So how do you go about offering platform specific functionality in a PhoneGap app?  With plugins.

Plugins allow you to write native code for a specific platform in order to extend the PhoneGap framework.  For example, you could write code for handling , then write some Javascript to hook your native code to the PhoneGap framework, then use this native functionality in one of your PhoneGap apps.  OK, I didn’t give an entirely clear account of what is necessary, so just reference the PhoneGap wiki for details on plugin development.  The wiki currently contains step by step instructions for Android, iOS, and Blackberry.  Here’s the resources you should be checking out.

• How to Create a PhoneGap Plugin for Android
• How to Create a PhoneGap Plugin for iPhone
• How to Create a PhoneGap Plugin for Blackberry WebWorks
• Jesse MacFadyen’s () collection of

They Want You!

PhoneGap is an open source project.  Very open source in fact.  As though the BSD or MIT licenses weren’t liberal enough, PhoneGap gives you the choice of applying either to your work.  As long as you keep their copyright notices in your code and don’t use their name to promote your product, you can use their code however you wish, commercially or otherwise.

How does PhoneGap benefit from this? Well, licensing like this tends to create bi-directional generosity.  By this I mean the community commonly contributes to PhoneGap and its plugins and tools.  You can go to Github right now and fork your own copy of the whole PhoneGap framework (among other things) at the .

So if you use PhoneGap and write some custom code you think others can benefit from, consider giving back to keep the spirit of open source alive.  Otherwise you’re a jack ass.

weinre

Can’t believe I forgot this one. I’ll make this brief as your best bet is to read more at its website: ().

Basically, weinre lets you debug web pages remotely. What does this mean for PhoneGap? This means you can debug your native PhoneGap apps either on device or simulator. It alleviates one of the biggest time sucks of web based mobile development, which is the silent dismissal of malfunctioning Javascript calls. But now instead of your exceptions going the way of /dev/null, you can debug and log your execution as you would any other application. Oh, and Cordova has weinre built in.

Overview

I’d like to start by saying that I think it’s important that both of these frameworks exist.  The more I worked with each, the more I found that it wasn’t a simple question of which mobile framework was better.  Both have some of the features a cross platform framework should have, and each shines in areas that the other frankly does not.  And that will be the focus of this analysis.  What are the key aspects to a great cross platform mobile framework, and how do Appcelerator and PhoneGap stack up.

Cross Platform Support

So this is why we’re all here right? Code once, run every where.  That’s what we want.  Well in this case, one of these solutions gets you a lot closer than the other.

This is PhoneGap’s bread and butter.  By leveraging web views native to the mobile devices, PhoneGap allows you to build as an app as complex and modern as you want while providing the ability to have it gracefully degrade for lower end devices, all in the same code base.  This degradation can be controlled via CSS or even dynamically with javascript and media queries.  You can use the same design and development principles that have guided cross browser development for years.  And the list of mobile platforms they support (which includes iOS, Android, Blackberry, webOS, and Symbian)  is definitely worth bragging about.

Appcelerator, on the other hand, does iOS really, really well.  Android brings some additional headaches and quirks.  Blackberry is still in the beta stage.  They are actually creating native code based on their Javascript API, so the quirks will likely always exist. Appcelerator will constantly be one step behind/removed in their efforts to integrate native functionality.  No fault of their own, it’s just the nature of their product.

This is why I think emphasis on Appcelerator being a cross platform framework is misleading.  While it CAN be a cross platform framework, it is not by nature.  I mean, how can it be? One of its main selling points is access to native UI components, something that is obviously not part of a cross platform solution.  One code base for multiple mobile platforms is totally a possibility with Appcelerator, but you will likely sacrifice a lot of what makes it great (coming in the following sections) to get to that lowest common denominator.

Defined Workflow

The product will only be as good as the tools that support, particularly when you are trying to appeal to an audience as large as mobile developers.  In this respect, Appcelerator is the clear winner.

Earlier this year Appcelerator announced that they had acquired the web development IDE Aptana. Before this point you were stuck with Titanium Developer which did the job, but was only a project deployment tool, not a true IDE.  Just this month they introduced the first version of the new Titanium Studio, an integration of Titanium Developer and Aptana.  There were a few bugs to wrestle with the earliest versions of this software, but I must say that I am loving it.  It has truly integrated the development and deployment workflow, making it more organized and efficient.  It has built in update checking for not only the studio but also the Titanium SDKs.  Oh, and did I mention that all of this is free?

PhoneGap leaves you to your own tools and workflow.  A plus for some, but I would imagine its a minus for those of us who don’t come from primarily a web development background.  They give you some direction in the Tools section of their website, but its not what you would call a workflow.  It a different approach, basically leaving the developer to determine what libraries, IDE, touch frameworks, etc… are most appropriate for their project.  This can be problematic for two reasons. 1, new mobile developers are not going to know which tools are the most appropriate and 2, there are A LOT of available touch and JS libraries out there for mobile development.  Choosing can be a project in its own rite. All that said, of Nitobi, the makers of PhoneGap, created the XUIJS library. Its what I’m using and I’m really digging it so far.

Programming Language

EDIT: Here’s a more recent and more detailed post explaining this section.

Admit it Appcelerator developers, you aren’t interested in the Javascript API so much as you are interested in NOT writing Objective-C!  Yeah, me too.

You would think this topic would be a deadlock, right?  Its just Appcelerator’s Javascript API versus PhoneGap’s use of the standard web stack of HTML/CSS/JS.  It basically the same thing… or is it?  Remember how I said in the last section that PhoneGap gives you free reign to choose whatever framework you want for development?  Well, Appcelerator doesn’t, and it is definitely to the chagrin of many Javascript savvy developers.

PhoneGap is HTML/CSS/JS.  Anything you can do with it on a normal web page you can do in a mobile browser’s web view.  This means any chunk of Javascript you find anywhere that you like can potentially be integrated into you app.  This ranges from your favorite frameworks like jQuery and Prototype, mobile  libraries like Sencha Touch, or even graphical ones like Grant Skinner’s EaselJS or one of these many 3D libraries.  Performance and device support permitting, you can use any Javascript you want.

Appcelerator’s API unfortunately is purely Javascript, is has no ties to the DOM.  But wait, doesn’t the most popular Javascript library in the world assume the presence of the DOM window and document?! Yep, that’s right, you can’t use any part of jQuery that requires the DOM (which is almost all of it) in your Appcelerator code.  The one exception is that you can still use jQuery and other DOM reliant libraries in a Titanium.UI.WebView, but you can’t use it with the actual Appcelerator API.  Annoying to me, but I can see this being REALLY aggravating  to long time web developers accustomed to using jQuery with everything.

Deployment Support

If you’ve spent any time in mobile development, you know that deploying your finished app to markets and app stores can be a truly daunting task.  There’s certificates, app signing, icons, logos, promotional images, supporting text, and the task of keeping it all organized.  It can quickly become a mess.  While both Appcelerator and PhoneGap both give you detailed instructions on how to build app store ready apps from your development environment and offer professional services, PhoneGap takes it one huge step further.

PhoneGap Build is currently a free beta service that you need to get your ass signed up for now.  While I highly encourage you to check it out for yourself, here’s the insanely easy workflow:

1. Upload you PhoneGap project to PhoneGap Build (or use its Github integration)
2. Configure your platform specific accounts with certificates and signing keys (all PhoneGap supported platforms available)
3. Watch as PhoneGap Build creates deployable binaries for each of these platforms and delivers you download links for each

Now that is the type of workflow I’m looking for! A quick note on step #2 is that iOS is the only platform that requires a certificate to get a testable binary.  You’ll want to set up certificates and keys before you deploy the the market/app store, but you can test the binary without them.

Speed of Development

All this flexibility and platform support has to bite PhoneGap in the ass somewhere, right?  Speed of development, if you can’t tell by it name, is another place that Appcelerator excels.

Appcelerator allows developers to start building an app that looks, feels, and performs like a native one very quickly.  Some of the big reasons are the following:

• Their Javascript API is infinitely easier than Objective-C, and some might also say Java (but not me)
• Tons of ready-to-use native UI components
• You are not required to adhere to the MVC architectural pattern
• The double-edged sword of loosely typed Javascript allows you to create custom components like table views and rows very easily
• The new Titanium Studio gives you one place to develop and build for multiple platforms

PhoneGap, though, is a bare bones framework.  It looks to provide mobile API support (things like location, accelerometer, etc…) across all major vendors.  The UI is left up to you and your chops as a web developer.  To that end most people are left to go find another touch framework to layer on top of PhoneGap.  Sencha Touch, jQuery Mobile, JQTouch are all popular options.  There’s even efforts to create web based “native” components.  You can also take my route and build most of it from scratch using XUIJS.

The long and short is that if you are only building for iOS, or maybe also Android, Appcelerator will likely get you from concept to completion faster than PhoneGap.

Documentation

Documentation is key when undertaking any new technology.  Both frameworks have their ups and downs here.

Appcelerator maintains a newly improved collection of there documentation on their new Confluence site.  While it is fairly comprehensive, it is also a bit jumbled, particularly the “Getting Started” section.  Its all there if you have the patience to find what you are looking for.  You’ll find installation, setup, examples, tutorials, the works.  You can also find a comprehensive listing of their mobile API here.  The problems I see with their documentation are the following:

• Its sometimes hard to tell what version of their SDK examples apply to
• Often Titanium objects have properties that don’t apply, or don’t behave as the documentation indicates
• You are sometimes left digging through the Q & A section to find the quirks for specific Titanium objects
• Examples given for Titanium objects are WAY too simplistic
• How ’bout a few more “Hello, World!” scale tutorials before you throw us at the ?!
• Im sure this will change after the Titanium Studio release gets some traction, but the “Getting Started” section is still using Titanium Developer as its chosen workflow

PhoneGap’s “Get Started” section is a thing of beauty.  In a very clean, concise layout, the PhoneGap site walks you through how to set up your computer for each individual platform you wish to develop for.  It list requirements, toolsets, and easy to follow instructions.  It helps ease the intimidation that can come with trying to develop for so many platforms. Once you get it up and running, PhoneGap’s API documentation is incredibly easy to follow.  A simple layout lists everything PhoneGap is capable of doing.  Clicking on these capabilities then takes you to the API specific documentation that lists usage, examples, device support, and any quirks that are currently known.  It takes a lot of the guess work and frustration out of the inevitable troubleshooting that ensues with cross platform mobile development.

PhoneGap definitely shines in the documentation department.  In all fairness, though, Appcelerator has a hell of a lot more to document.  PhoneGap’s lack of UI components accounts for a large part of its documentation being so easy to follow.

Community

An active and knowledgable community is one of my biggest factors in choosing any technology.  Appcelerator and PhoneGap both have a wiki and blog, and also offer these a few more resources.

Appcelerator has their Q & A section of their site.  It allows users to submit questions about Appcelerator to the community.  Users can submit answers, vote on others’ answers, and receive points and badges for participation.  If StackOverflow has taught us anything, its that people like being rewarded for participation, no matter how meaningless.  On top of this free resource, they also offer training, certification, and professional services for those looking to take their Appcelerator’ing to the next level.  I hand out on Twitter a lot, so its worth mentioning that you can get some great help and info regarding Appcelerator by following , , and .

PhoneGap maintains a connection with the community with their and on IRC at irc.freenode.net #phonegap.  They also offer professional services and training.  The core of the PhoneGap team is very involved with the community and I’ve often been found chatting with , , , and on Twitter.

Other than wishing PhoneGap had some kind of a forum system better than a Google group, I think both frameworks do a very good job of listening to and staying engaged in the community.

Extensibility

No developer I have ever known is just happy with the tools he’s given.  We want to be able to add to and modify anything we get our hands on.  Both frameworks are very extendable via modules and offer open source licenses, though PhoneGap’s option of “New” BSD or MIT license is a little nicer than Appcelerator’s Apache 2.0 license.

Appcelerator offers Android and iOS module development guides.  These allow you to build native components in their native SDKs and then be able to access them in your Appcelerator app via the Javascript API.  Anywhere Appcelerator falls short in terms of supporting any API or UI component, you are free to pick it up and make it happen.  Its not the simplest process and effectively removes the possibility of  cross platform code, but can be a strong tool for a single platform scenario.

UPDATE: In addition, Tony Guntharp also gave me this blog post detailing how modules can be developed in other languages as well: http://developer.appcelerator.com/blog/2011/04/tiphp-tipython.html

PhoneGap also supports additional modules, or plugins, to its framework in the same fashion that Appcelerator does.  You can develop native code and then write hooks back to PhoneGap to access it in your project.  Again, this undoes any cross platform compatibility unless you make the native component for all supported platforms.  There’s a guide to creating plugins found here.

Appcelerator on Github:
PhoneGap on Github:

Summary

So as I stated at the beginning, I think both of these frameworks are important and have their place in the mobile landscape.  From my personal perspective, as they both stand now, PhoneGap is the true cross platform solution.  , author of “Mobile Design and Development”, rang the point home throughout his book that the future of mobile development lies in web based applications that adhere to a structure of graceful degradation.  I initially thought he was a web developer who didn’t want to learn Objective-C or Java.  After spending some time with native development and multiple cross platform frameworks, I find myself coming to the same conclusion.

But that’s not to say that PhoneGap is the end all, be all of mobile development.  I happen to think that for iOS & Android projects, Appcelerator could likely be your best choice.  Unless you have prior experience with Objective-C, I would advise anyone with even a basic knowledge of Javascript to give it a shot before resorting to native development.  Trust me, you won’t miss Interface Builder, and outlets, and actions, and all kinds of other iOS MVC fun.  Oh, and you’re sure to enjoy the native UI and performance that Titanium uniquely provides.

NOTE: I would have liked to include Adobe Air as I did in this past comparison of mine, but I honestly have not used it in 2+ months and there have been serious changes since.  I’ve been focusing on cross platform solutions that can hit the big three mobile devices out there: Android, iOS, and Blackberry.  Soon as Blackberry supports Adobe Air you better believe I’m coming back to re-evaluate it.  I’ll take AS3 and/or Flex over HTML/CSS/JS any day.

The Short, Blunt Version

DISCLAIMER: Don’t leave me nasty comments if this is all you read.

Most of the available “cross platform” mobile frameworks are not as universally and uniformly compatible as they would be announced. There are inconsistencies that make “code once, run everywhere” very unlikely without at least some tweaking. The time spent fitting an app to one, universal mold can often force a sacrifice of even more time, quality, and usability.

Using HTML/CSS/JS for mobile development is seen as an advantage only to those who already have a great deal of experience with it. I say this from a pure language perspective as it carries the obvious advantage of providing portable, standards based code. If you don’t have this experience with Javascript, but do have the talent and/or diversity of background necessary to learn the languages to develop natively, do so.

I’m not saying you can’t build a multi-platform, high quality app with a mobile framework. I am saying that it is not quite as easy as it may appear on paper. This may seem counter-intuitive, but as the complexity of your project grows, the less effective a “code once, run everywhere” approach will be. That said, most mobile frameworks do a terrific job of making small to medium sized projects available to a large audience in a short amount of time.

For the quick feature comparison of the mobile frameworks I’ll talk about below, check out my prior post, “Appcelerator vs. PhoneGap vs. Adobe Air”.

Naivity

I approached the world of mobile development with the thought that a cross platform development framework was the one true path. I mean, how else could a single developer keep up with the plethora of mobile OSes, SDKs, and devices? And with that notion, I went forward in search of the silver bullet framework that would give me the coveted “code once, run everywhere” solution.

But as you may have expected, I haven’t found it. With my tunnel-vision focus on cross platform development I neglected to pay attention to the multitude of other key factors that can cost developers time. I also neglected the fact that deploying to every mobile device imaginable is almost never the goal of a particular app.

So what are the problems I’ve run into? How have they cost me time? Does this outweigh the potential time saved with the “code once, run everywhere”? Is “code once, run everywhere” really achievable for most apps? Let’s dig into these topics and see how they could impact your potential mobile development workflow.

Most frameworks are babies

Let’s take a look at the 3 frameworks I’ve looked at so far:

• Appcelerator – mobile SDK started in 2009
• PhoneGap – started in 2008
• Adobe Air & Flex Hero – Air for Android and the iOS packager came out in 2010. Flex “Hero” is still beta.

As you can see, all of these frameworks are very young. And with that youth comes ambition, which in turn can lead to cut corners. The competion is fierce in a new and growing market. They know what they need to stand out: features. Stability and adherence to standards aren’t quite as eye-catching as an app that can leverage cool mobile APIs like geolocation and accelerometers.

It seems that in many cases the frameworks are spreading themselves thin at the expense of solid compatibility and stability.

How “Cross Platform” Are These Frameworks?

Here’s the mobile OSes aforementioned claim to support:

• Appcelerator – iOS, Android, Blackberry (beta)
• PhoneGap – iOS, Android, Blackberry, WebOS, Symbian
• Adobe Air & Flex Hero – iOS, Android, Blackberry Playbook

Now here’s been my experience with each so far, your mileage may vary. I will try to keep it as high level as possible.

• Appcelerator – iOS is their flagship. You can tell by the very Mac-ish look to their Titanium Developer project application that this is their focus. Appcelerator does iOs very well. Android on the other hand has been a bit frustrating. Many features and even core functionality are lagging behind in Android in terms of stability. Simple things like orientation lock and layouts work well in iOS but not so much in Android. This leads to inconsistent behavior between the two platforms, which is kinda the whole point of the framework.

  I have not yet tried Blackberry development, but if Android is a production release and has these issues, I worry what I may run into.

• PhoneGap – This is the one framework I’ve experimented with so far that has a relatively uniform experience across all its supported platforms. The core functionality is there, operates the same, and with a consistent level of performance. Granted PhoneGap is an entirely contained web app and has no native UI component access, though most APIs are supported. This, though, should be the expected experience with a cross platform mobile app. Give me the same thing on every device to which I deploy!
• Adobe Air & Flex Hero – Because these mobile apps run against the Adobe Air runtime you get a nearly identical experience across the supported platforms. Flex Hero comes with a wide array of mobile components for your use, though some are notable missing. The big hitch with consistency is performance.

  Blackberry Playbook development churns out great, performant content. Blackberry made available an AS3 SDK along with the ability to use Flex Hero. Because of this forethought and respect for the existing technology, Flash/Flex developers are really enjoying this platform and I think users will too.

  On Android, Air performs OK. There’s just enough lag on transitions and load time to drive you nuts as a developer, but likely won’t be a deal breaker for users.

  iOS seems to be a sore point for some developers. The performance is reported to be less than desirable when compared with the other supported platforms. Also, the Adobe iOS packager that allows you to deploy Adobe Air mobile applications to iOS currently only supports Air 2.0, leaving out some popular APIs like camera and video. We are all familiar with the battles between Apple and Adobe and why these performance issues exist. The users don’t care though and are likely to turn away from apps that seem sluggish as these might.

So as you can see, “cross platform” and “code once, run everywhere” aren’t quite as cut and dry as we would be led to believe. I’m not saying that frameworks should be dismissed for these reasons, but they simplicity of universal deployment and satisfactory user experience in many cases is overstated.

Do You Really Need To Support All Those Mobile OSes

I could ramble on about market share, market viability, and targeted deployment, but I’ll just let these few charts do the talking and let you render your own decision:

Javascript

I’m not here to start a holy war about whether or not Javascript is quality language. We all know the effectiveness of a programming language is largely determined by the person wielding it. But let’s be honest, Javascript is no Java, C#, or even Objective-C. And with the exception of Adobe Air and Flex Hero, almost all mobile frameworks use HTML/CSS/JS as their technology stack.

There’s no classes, no types, and the available IDEs and debugging facilities are weak in comparison to its native language SDK counterparts. As I hear many of my Flash/Flex friends saying from time to time, its a reminder of all that was wrong with the original version of Actionscript. jQuery and other frameworks make it more tolerable, but its still tough sledding when you are accustomed to a more full featured language.

Debugging

This is where you are ging to spend the majority of your life as a developer. If you don’t, you’re a better dev than I. And let me tell you something: debugging sucks in Javascript. Compound this with the fact that it is pretty much impossible to debug Javascript on a mobile device and you have a recipe for may, many lost hours chasing bugs.

Let’s look at Appcelerator and PhoneGap: They have no ability to debug on a device (I’ve had suggestions to try and JSConsole). Appcelerator often refers to a “debug” function you can use, but it is simply a logging capability called debugging. With PhoneGap the suggested method of debugging is running your code against the desktop version of Webkit and using its debugging capabilities. Neither of these situation is very ideal.

Adobe Air and Flex Hero debug the way you would expect an application to be debugged. Air can do full integrated, on-device debugging in a number of IDEs (Flash Builder and FDT spring to mind). This is what should be expected. While Javascript based mobile frameworks are using web technology, they can no longer expect developer to abide by the web’s workflow. When developing native apps we want application debugging, not web debugging.

Do not underestimate the impact that poor debugging capabilities will have on not only the timeline of your project, but also the quality. In both cases, you just might be better served going the native route.

2 Layers Of Potential Bugs

We all know that Android, iOS, Blackberry, and any other mobile OS you may encounter is going to have bugs and quirks in its SDK. The same could be said of all software. If you are using a mobile framework to develop against these SDKs, you now have 2 layers of potential bugs and quirks. It can often be difficult and time consuming to determine which one is the culprit… after you’ve ruled out your own code of course!

While PhoneGap and Adobe Air suffer from this to a degree, the impact is less on these two frameworks. This is because they make no attempt to handle native components. They rely on your own HTML/CSS/JS or Flex/AS3 components respectively to serve your UI. Some see this as a drawback and taking away from the native user experience. I, on the other hand, see it as a step towards true uniformity in your app. You need to make a decision: Do I want a native or uniform experience?

Appcelerator suffers more from this situation. By taking their unique approach of offering a Javascript SDK by which you can create native components, you are given the opportunity to create a native experience without having to engage in native development. This is very appealing to many developers. I know it was to me. The unfortunate side-effect of this is that you many times will not get exactly what you would expect out of a component. Due to the need to abstract functionality in order to make one code set apply to many different mobile OS components, you may find configurability difficult. Determining whether something is misbahving in your app because of your code, your framework, or your SDK becomes quite troubling.

Summary

I gave the summary at the beginning, since I don’t know if a lot of you have the stomach for this much negativity in one blog post.  There was a lot to say and detail, but the short, blunt intro summary is my current sentiment on the state of mobile development.

Just to be clear, its not all gloom and doom for mobile frameworks.  Check out this post I did a little while back detailing all the areas where these mobile frameworks can make your life much easier.  And these frameworks are getting better everyday.  PhoneGap is quickly closing the gap (pun) between itself and the other mobile frameworks in terms of features.  Appcelerator is making some major moves by creating a community of Titans to bring more notoriety to the cause.  They are also due to release the first public beta of their new IDE, a fusion between Titanium Developer and Aptana, sure to help the current state of Javascript development.  And Adobe is aggressively garnering support for its pre-release programs for Air, Flash Player, and Flash Builder.  I believe new features along with improved performance across all platforms is going to be the fruit of this labor.

So I haven’t given up yet and will continue to actively pursue these platforms.  I may wait for a bit more dust to settle though before engaging in a large scale project with any of them.  I’m sure folks braver than I are more than able to have success doing so right now.

Overview

UPDATE: This was originally posted January 18th, 2011. All 3 platforms have changed immensely since.

UPDATE: If have updated and more detailed information about Appcelerator and PhoneGap at this link: https://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

I have been charged with deciding on a mobile framework for deploying a single code base to multiple devices (iPhone, iPad, Android, Blackberry). Naturally, I was gravitating towards Adobe Air since most of my personal work these days has been in AS3. I wanted to see what else was out there, though, and was pretty surprised that Adobe Air wasn’t my choice in the end.

In addition to one other commercial platform I did not fully assess (too expensive), I looked at Adobe Air for mobile, Titanium Appcelerator and PhoneGap. All are free to use frameworks for centralized mobile development. The gist is to be able to create apps for multiple devices off the same code base. With iPad & Blackberry support, speed to market, and the ability to use Contacts & Multitouch as my critical points, I began digging.

General Functionality

	Titanium Appcelerator	PhoneGap	Adobe Air for Mobile	Notes
Android Support				Adobe Air requires Android 2.2+
iPhone/iPad				Adobe Air creates iOS apps with the Packager for iPhone
Blackberry Phone				Appcelerator support is currently beta.
Blackberry Playbook				Appcelerator support is currently beta.
Symbian
Palm
Windows Phone 7				is a 3rd party attempt for PhoneGap.
Native UI support				PhoneGap and Adobe Air both require 3rd party libraries. PhoneGap has UIControls for PhoneGap. Adobe Air has and android-components
Native code support				Appcelerator allows module development. PhoneGap uses .
Desktop deployment				PhoneGap has 3rd party libraries on Github: &
Deploy without Mac?				Adobe Air uses the Packager for iPhone/iPad
IDE & Tools	Titanium Developer	PhoneGap Tools	Flash Builder, FDT, FlashDevelop	Appcelerator has no current IDE, but recently acquired Aptana
Interpreting	Javascript mapped to native code	Rendered in web view control	Adobe Air runtime
Community Resources	Developer Center	Docs, Wiki, , and	Mobile and Devices Development Center
Languages used	JS	HTML, JS, CSS	Actionscript3	Appcelerator also uses PHP, Ruby, and Python for desktop app development
Support	$2,189 per year per developer	ranges from $1,000 – $25,000 per year	Adobe Support	Adobe offers no professional mobile support for apps, just their products.

Device APIs

Beyond the overall support structure of the frameworks I wanted to get into the specific device API functionality. This was a little harder to track down, but the list here should be accurate as of the writing of this post. As I said earlier, contacts and multitouch were the only criticals, but I wanted to know what else these frameworks offered. I’m assuming anyone reading this far would find this information valuable as well.

	Titanium Appcelerator	PhoneGap	Adobe Air for Mobile	Notes
Accelerometer
Geolocation
Vibration
Camera				Not yet supported Adobe Air for iPhone/iPad
Contacts
Multitouch
SQLite
File System IO
SMS				All support SMS via the “sms:” URL prefix.
Phone API
Copy/Paste
Sounds				PhoneGap cannot record sounds. Adobe Air cannot record sound for iPhone/iPad
Bluetooth
Video Capture				Adobe Air cannot record video for iPhone/iPad.

Summary

That’s what I’ve got so far. Let me know if and when some of these assessments change. I’m also eager to hear other people’s thoughts. Feel free to chime in.

The long and short of my recommendations:

• Go Adobe Air if performance isn’t critical and you have AS3 experience. The tools and workflow for using pure AS3 or Flex Hero make turning out mobile apps very smooth. Watch out for performance, particularly on iOS.
• Go PhoneGap if you needed the widest range of support for devices. If you need it to run everywhere, this is your framework. Beware of the less than stellar documentation and wiki, though.
• Go Appcelerator everything else. The native UI and ability to access native code is a big win. Also, the community, IDE, and documentation are top notch. Appcelerator was my choice in the end, but that doesn’t mean its right for you.