I am an Android developer and enthusiast with over 10 years of Java development experience. I'm big fan of good design an appreciate well though usability design in applications. Juhani is a DZone MVB and is not an employee of DZone and has posted 110 posts at DZone. You can read more from them at their website. View Full User Profile

Multi-platform Frameworks Follow Up

  • submit to reddit
My previous post about multi-platform frameworks started a very interesting discussion. Big thanks to everybody who contributed into the discussion. The discussion wasn't only limited to the blog comments so here are few other places worth taking a peek.

The CommonsBlog
Mark Murphy over at The CommonsBlog wrote a rebuttal to some of my arguments. His arguments are worth checking out:
UX Strategy Vs. UX Tactics.

Another interesting discussion took place in my blog's G+ post at:

Alan Knitowski from Phunware
Alan Knitowskini wrote a long and well argued comment to the original post. Unfortunately the Blogger engine didn't want to cooperate and the second part of his comment never never appeared in the discussion thread. It think this comment can be very valuable and I wanted to post it in its whole.

So here's Alan's comment in its whole republished with his permission:

Hello everyone,

I am the CEO of Phunware (www.phunware.com) and I am happy to chime in on this issue with some very real world and practical thoughts over the past 3 years of running our business.

These thoughts are by no means random and are completely based on the empirical data that we've been able to put together across tens of millions of app downloads consuming billions of minutes of app usage in more than 100 countries and 10 languages worldwide. They are also based on building hundreds of apps for the largest and most important brands in the world at transaction scale, including CBS, NBC, ESPN, Univision, Discovery, Turner, HomeAway, NASCAR, NHRA, Sony, AMD, YouSendIt, Samsung, Freescale, McDonald's, The Grove, FUNimation, OWN, E! and the NFL amongst many others.

The punchline of our very real world experience is that all of these write-once-run-everywhere mobile app frameworks such as Appcelerator, Titanium, Adobe AIR, Phone Gap and the like simply DO NOT WORK. At all. Sure, they can work in marginal use cases for the overly simplistic or the feature weak engagements, but if you are trying to build real mobile experiences that challenge the processing power, memory and resolution capabilities of the best mobile devices and OS's on the planet, then they simply SNAP. They break. They crash. They simply can't keep up with the demands of the real world for large brands and large audiences and communities when engaging with vibrant content at transactional scale.

Our Phunware Labs team has tried to build out apps using all of these systems as a means to see what they could and could not do in the real world. To date we have launched exactly *nothing* that we have ever built in these experiments. Not only is the non-native UI/UX and look/feel underlying the apps fundamentally miserable, but also the associated maturity, stability and capability of the platforms simply can't handle anything demanding in a normal feature set.

These systems are seductive and sound amazing. Just write things once and they will work everywhere. Wow. Amazing. What a cost savings and what an operational deployment and support savings. Until it isn't ... and until it doesn't. False hopes and false promises to those that haven't realized the underlying pain that they're about to put themselves through from those with snake oil to sell. If I were to use whack-a-mole as a relevant analogy, then using these systems is like putting your face through the hole and then getting kicked ... and kicked hard. Rinse, lather and repeat.

Unfortunately, in their effort to be all things to all platforms, their systems were dumbed down to the least common denominator of the worst possible platform and thus deliver apps that are average everywhere and exceptional nowhere. Save money on the budget? Nope. You just maximize the amount of pain trying to force them to work and then watch them snap in the real world when trying to care for them afterwards. Ultimately the idea that you need to be on all platforms is even more alarming as all of the platforms aren't even viable or relevant yet. Maybe they will be and maybe they won’t, but why focus on them all when all of them just aren’t needed right now?

From our unique perch, and based on the brands that we work with daily (both large and small and both public and private), we have yet to find that even one of our customers is shooting for being “average everywhere” on mobile. None. They all want to be exceptional and they have all realized the hard way that they got what they paid for and not much else. Unless the goal was a “forklift upgrade” with a “redo” attached.

We believe that in order to be exceptional, you have to actually do the "hard stuff". The "other IOS" as well ... as in the Internet Operating System of Cisco and the core switching and routing fabric on the cloud based server side to control good and bad 3G, good and bad 4G, good and bad Wi-Fi or no network at all. The client *and* the server are critical to having great apps. One without the other simply doesn't work ... and it especially doesn't work when you try to ignore the actual hard problems that require close attention.

With all of this said, we are by no means religious about our viewpoint. We are also completely technology agnostic. However, we are also practical, realists and operators. We build exceptional mobile experiences that simply work and that set new standards for the categories that they enter. And after a lot of work in this area, we have seen that for right now, exactly none of these systems can handle what is needed. None.

If you want to see my Business Insider article entitled "The Delusion of Write-Once-Run-Everywhere Mobile Applications", please check out this URL:


I will apologize in advance if anyone does not particular care for this viewpoints or the data sets that I have provided, but at the end of the day, the data is what it is and a platform cannot be something other than what it really is. Time to call a proverbial spade a spade.

Alan Knitowski
Phunware, Inc.
Published at DZone with permission of Juhani Lehtimaki, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Shai Almog replied on Wed, 2012/04/11 - 4:00am

I'm a founder of a framework not mentioned here and radically different in architecture than all of the above (am I a "snake oil salesman" if our product is free and open source?).

Our product offers a highest common denomintor approach for UI development (90% of the problems in such frameworks), since we use a lightweight Swing like architecture with full support for heavyweight native code embedding. 

We worked on this framework for 5 years as part of Sun Microsystems and left when neither Sun or Oracle allowed us to  ship ports for iPhone, Android & Windows Phone 7. So the framework is effectively remarkably feature complete and used by major development shops around the world and most major operators/manufacturers.

Telmap is a GPS application maker (recently bought by Intel) who based their entire solution around a relatively old version of our solution. They love the solution and claim to huge savings in manpower and no sacrifice in functionality.

Unlike others, since our framework is lightweight it is deeply customizable in a very cross platform way. You can still get native platform specific features and idioms by leveraging our API and visual tools. The savings in maintenance alone are stagering. 


One of the biggest issues with such frameworks is that people see them strictly as a means to save and start cutting corners all around. The best solutions leveraging our framework have spent a great deal of money on QA, user support and UI design producing distinctive feels for all platforms. They used the savings to create better products overall.

Paul Bizannes replied on Wed, 2012/04/11 - 11:32pm

Testing is a part of the development process which seems to have been left out of this discussion.

One of the problems with frameworks like lwuit not mentioned here is that they are not amenable to current automated testing frameworks, like Robotium for Android, which in turn creates extra work for testers.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.