A shorter version of this article first appeared in issue 238 of .net magazine – the world's best-selling magazine for web designers and developers.
XVT, wxWindows, Gtk, AWT, SWT. These ring any bells? They're just some of the toolkits which promised use the ability to write code on one platform, and produce applications that will run seamlessly on Windows, Mac and X Windows.
Some were better than others; but they all had one thing in common:
Applications written in them sucked.
To their credit, it is the one place where the cross platform promise actually worked - applications written in them consistently sucked across platforms.
Before you point out some obscure application that was half decent, I'm talking about great applications. There has never been a single, commercially successful, great application written using a cross platform toolkit.
And now we’re being offered these promises to develop “write once run anywhere” apps for iOS, Android and Windows Mobile. Sure, it's a cost effective way to have presence everywhere, but here's why it will let you down.
1. An embedded web view is not a web browser
Most mobile cross-platform toolkits rely on HTML5 to provide the bones of your app, with the app essentially being rendered in an embedded web container. This ignores an important point: yes, the web is a platform agnostic platform, but when using web apps, we tend to use the browser's chrome for navigation. This is why it is familiar to us.
However, when a cross-platform mobile app is embedded in a web container, the app's HTML is responsible for navigation. Gone are our familiar controls and instead we get a navigation system typically modeled on the dominant platform's look and feel.
2. The resulting navigation will be a compromise
So, you're using HTML and you've decided to hand code the navigation. Here's how that typically goes. The majority of users are (let's say) iOS users; so we'll develop it with a black tab bar at the bottom and mimic the iOS tab bar style.
The iOS user hates it; you haven't managed the subtle change in colour when the tab is tapped, or the jump to the topmost screen when double tapped.
The Android user hates it because he's either never seen it, so it is unfamiliar, or worse, he knows that it's an "iPhone-like" interface and isn't happy about it being foisted upon Android users.
In days of yore we might have had a PC at work and a Mac at home. We might have needed to use certain tools in both; this was the lure of having an application run on both; but with our smartphones life is different. The vast majority of users have a single phone. Users want consistency with other apps on their device, not consistency with another version of your app on another platform they have no intention of using.
When a toolkit is released to work on multiple platforms, the toolkit vendor does the heavy lifting of making sure something works on all platforms. This actually means that at best, they can implement 'lowest common denominator' functionality. If feature X works well on Android, but cannot be done elegantly on iOS, it won't make it in.
This is fine if your app functionality is basic; but what happens if you need something not easily done within these confines? Well, this is when the toolkit starts to hinder your progress, not help it.
You may find some nice 'extensions' for the toolkit which make feature Y easy to do on iOS; but now you've just starting writing platform specific code, and all the promised advantages have gone.
5. Too good to be true
Apple, Microsoft, Google: the largest software companies in the world, employing the best brains, who've put a great deal of effort making their platform experience amazing for their end users. And you think a toolkit and some fancy JavaScript can do a better job?
The lure of being on every platform with one click of a mouse will be music to the ears of CEOs and CFOs; the simplicity of that statement hides the reality. It doesn't admit to the substandard resulting app; bad reviews will make the CEO's blood boil, and the CFO will not be happy that he's to pay for a ground up native re-write. Do yourself a favour and arm them with the facts.
Developing natively on each platform gives you the fastest possible app, full access to the device's capabilities, and frameworks to ease development; native SDKs are the only way to guarantee the best user experience.
Head over to Creative Bloq for 25 pro mobile website design tips!
