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.
Excellent post. It doesn’t come across as negative at all to me, but does a very good job laying out some of the details developers are interested in when choosing the mobile framework to use on a particular project.
I do have the itching feeling that some of these reflections will have to be updated soon though
Negativity? I do not see this as negative at all.
It’s on Objective (see I can make a pun too) sight on everything’s out there now.
Each and everyone of them are tools in development. We cannot expect to have a perfect framework so fast (there’s no such thing anyway).
Appcelerator is the only I haven’t tried, but I share the opinion ob both PhoneGap and AIR. Being an plattform enthusiast I really believe AIR can make the cut in the future, but we’ll have to wait.
I understand that having a framework that works for all the platforms would save lots of time and money, for right now, this day, I really prefer to create native apps exploding the features of every OS with care.
A great example of that are Fourquare or Facebook apps for iOS and Android. Different and similar, native and adapted to what the device can do.
Definitely for new projects starting right now, there are issues with these cross platform tools. However, all platforms seem to be working on improving these issues.
However, I’ve seen the other side of companies who have large complex mobile apps that they must maintain code across multiple platforms. As it’s not just building the apps initially and porting them to other platforms, but maintaining them as new features keep getting added. The result is their apps aren’t always in sync in features and it can really get messy. Some companies this means having multiple mobile teams, costing them 2 times to 4 times the cost (depending on how many platforms they support) compared to how much they could save if they used a cross platform tool.
So I do agree that these cross platform tools need a lot more work, but at the same time, I think using these tools can save a company a lot of time and money.
Very good sum up of the pros and cons of these 3 frameworks. Didn’t know that the others didn’t provide on-device debugging. I guess it’s back to the alert()-style debugging. I really enjoy debugging inside of Flash Builder on my device, it’s a real timesaver.
Adobe AIR is evolving really fast and i don’t think performances will be so bad in the end.
Talking about timesaving, code re-use is also a big feature. I did re-use much of my web app (Flex) for my Adobe AIR app that saved me days of dev. I don’t believe you can re-use existing JS code with PG and TT as it used as “pseudo-code” somehow (maybe i’m wrong on this point)
Keep the articles coming
Fabien
@Joseph: Oh, I’ve been listening to the pre-release chatter. It sounds like big things are coming for Air.
@Matthew: I agree that the theory of these tools can save companies time and money, and that in a lot of cases, it will. I just wanted to warn those wandering into the mobile development world that its not quite as easy to create a quality user experience universally with a framework. I wanted to make others aware of the sacrifices that are made in other areas for the sake of multi platform compatibility.
@Fabien: Code reuse will be easier in PhoneGap as it really is pure HTML5/CSS3/JS to create all your content. Appcelerator on the other hand uses a Javascript SDK to create native components and layouts. Its code doesn’t really lend itself to being used in other situations. That said Appcelerator also offers a Desktop SDK to allow for porting your code to even more platforms.
Regarding JavaScript debugging an “They have no ability to debug on a device”:
You’ve got and JSConsole (the later I developed to connect a desktop console to a real device) – both are two way consoles for debugging.
@Tony I agree…an excellent summary.
The only change I would offer is that Phonegap does in fact provide access to native components across platforms via API including: camera, accelerometer, compass, contacts, file and more as seen here: http://docs.phonegap.com.
@Remy I’m definitely going to check out JSConsole…slick.
@Remy: Thanks for the heads up! Corrections were made in the appropriate sections above.
@Brett: Maybe I should been more clear. By components I meant UI components. All the frameworks support a wide array of mobile API functionality, but not many actually support the use of native UI components, like Android spinners or iOS Date Pickers.
@Tony Ah…my bad.
Great article. Each of these options is still not really very good at what they claim to do, and, having tried all three, I’ll admit I find working in them all to be unsatisfying. Each has a fatal flaw. Air? Needing a 16MB plugin for your app that keeps updating. Users will frequently give you a one-star review just for requiring the Air runtime. Plugins suck. Titanium? Buggy example code, not future proof (can’t rely on your old code to compile next week as it keeps changing) and “feels commercial”. Phonegap? Few features.
One point I think you got wrong is that Phonegap only exposes regular HTML/JS/CSS with no native capabilities. In fact there is a rich set of native commands such as gps, orientation, camera, playing sounds, contacts, filesystem, db etc.
Keep up the great work, I always read your blog posts with great interest.
@McFunkypants: I too have received the evil “Adobe Air 1 star” rating before. Its one of the big reason I’m taking a stab at doing my fitness calculator app (Repper) natively.
See my comments to Brett above for PhoneGap. Again, I was referring to the fact that PhoneGap has no native UI components.
I’ve made a few adjustments to the article. Thank you all for the suggestions and notifications!
Very informative post, thanks. I was wondering whether any of these very, very young alledged cross-platform mobile frameworks would be able to deliver.
I don’t share your views on JavaScript though, IMO a language doesn’t need classes or types to be usable. I’ve never produced clean code as quickly as with JavaScript, Lisp and Clojure. Just don’t try to do traditional OOP with JS, that’s a mess.
[...] application and its execution everywhere. This is not completely true, Tony Lukasavage in a recent blog post analyzed strengths and weaknesses of these frameworks considering all of them far from being the [...]
[...] Tony Lukasavage asks an interesting question: Are you actually saving time with mobile frameworks? [...]
I like your analysis. The pertinent points I take away from this are.
“Silver-bullet” solution providers sacrifice platform specific API depth and stability for coverage.
It is perhaps pointless to expect a unified high-fidelity solution that covers all platforms while players are battling for market dominance and continue to seek to distinguish themselves through unique API’s.
The eco-system for each platform is currently rich enough and has sufficient populations to create the gravity or inertia that discourages migration across multiple platforms. Assuming resourcing of application development is relatively constant for an app-provider, the only motivator is when market dominance by an application in one platform plateaus, it will naturely migrate to the other to continue drive license sales forward.
Very interesting read savage man! I’m really digging into dev possibilities for mobile and am really skeptical about ‘write once, run everywhere’ ideologies. It’s only ever really worked for environments that come with a runtime of their own, like java and flash. Still, tools like appcelerator look tempting. I just hope it won’t turn out to be 1 of those huge mistakes I made when picking tech for a project….
Thanks for the useful posts you’ve made on the subject of mobile frameworks. My dev experience over the years has relied heavily on frameworks as I worked in the C++ and Java world and things like ACE and TAO by Doug Schmidt (all to do with comms programming across different OSes) were absolutely invaluable.
However having moved onto PHP and HTML and the frankly painful javascript the idea of building apps on phones with javascript is not an attractive proposition, with or without frameworks. I am looking mostly at using phonegap as it seems better placed for integrating other components I’ll need going forward such as scanners and push notifications.
Keep up the good work,
Shaun O’Hagan