I’ve been wrestling with this question for some time, and I thought this post may help sort out my thoughts and opinions while giving you some important insight. Are hybrid mobile apps going to become the developer’s choice anytime soon? The debate can be pretty heated as companies choose one technology over the other.
Hybrid, the Unlikely Union
Let’s get the definitions straight before we begin. A hybrid app is one of those mobile apps that uses a native web view to display HTML, CSS, and JS “web” apps. They’re only sort-of “web apps” because they are run locally, though they often pull data from online sources via AJAX requests. So, you have this HTML/CSS/JS app running inside of a natively-compiled stand-alone web browser of sorts on your phone. One such example is PhoneGap. Because the logic bits of the app are written using web technologies, you can often develop once and deploy on multiple platforms, so long as you’re using supported markup. You’re killing multiple birds with one stone.
Hybrid is the Bee’s Knees
As I mentioned above, hybrid technologies are great for developing cross-platform apps. Seriously – since iOS, Android, and even some Blackberry devices are both running Webkit most, if not all, your html, css, js is going to work remarkably similarly on both platforms. It’s pretty enticing. From your and your client’s perspective it’s a pretty easy sell. For one round of development you have the potential to hit many more users. It’s pretty cost-effective. Pretty soon you’re singing the praises of your decision and you’ve decided that from now on hybrid apps are the bee’s knees.
The Gateway Drug
I’m not going to lie – I immediately fell in love with the idea because my background was primarily web development. I can take my existing toolset and apply it just a little bit differently to come up with something like an iPhone app that I’m sure everyone would want to buy. I’m getting ahead of myself. If it wasn’t for tools like PhoneGap and jQTouch, it would have been much longer before I got into mobile development. Now there are libraries such as Sencha Touch and jQuery Mobile to aid development. It’s an exciting industry to be working in. It’s not that the web is old and tired, but mobile development is something new and exciting. I can’t wait to see where we’ll be in just a few years from now. It’s getting that good, that fast.
Native Apps, the OG Tech
So far I’ve been discussing the benefits, and singing the praises of developing hybrid apps. So what about native ones? Since I’m really only familiar with Cocoa Touch, I’ll write from the perspective of an iOS developer, though many of these points will apply to Android. There is something to be said about the quality and performance of native apps. Native apps are going to perform better than hybrid apps, no doubt about it. When you read that, you’ll probably first think about number crunching, but I encourage you to think about it from another perspective: responsiveness. I’m talking about the speed at which things happen on the screen when you need them to. Does the next view load and transition instantaneously? How about animations or actions attached to button presses? Hybrid frameworks have come a long way, but native still wins this race, hands-down. When your app responds immediately to touch events, that’s awesome for the users’s experience because that’s how apps should work.
I think there’s also a certain level of sophistication in native apps that can’t quite be reached by hybrid apps. You can do quite a bit (even impressive) things with html/css/js but it only goes so far. At some point you hit a wall. More on this later.
Sticking Points
About a year ago, I chose to switch from jQTouch to Sencha Touch for hybrid app development. Overall, the end results have been very pleasing, especially compared to pre-Sencha Touch days. This framework takes care of most of the heavy lifting, from UI to data management. In many ways Sencha Touch looks and feels very similar to a native app. It mimics many of the same user interface and behaviors as its native cousins on both iOS and Android. It really is the best-of-class frameworks for hybrid apps. Beware, however, that it’s not an entirely pleasant experience.
The Mobile Web Darling, Sencha Touch
I’ve run into too-many-to-count issues with Sencha Touch relating to tweaking the layout, screen rendering, and general UX problems (I never said it was perfect). I’ve discussed some of these with fellow developers. Typically I describe it this way – It’s not too bad to work with until something that should work out of the box, doesn’t. I’ve spent far too many hours trying to debug and fix some very basic problems. Case in point – rotating the device causes rendering errors. A good number of developers have also experienced some major Android incompatibilities, especially with the HTC Sense UI. Ever seen a text form field duplicate itself elsewhere on the screen when given focus? Work with Sencha on Android long enough and you’ll see what I mean. There’s no clear fix for that, nor is that mysterious field controllable by the DOM – it’s all at the OS level. How about crashing Android devices when you scroll the screen content too much? Just sayin’. I will give Sencha some credit, though. Touch works much better on Android than it did a year ago, and many of the most significant problems have been addressed. Also, customizing the UI isn’t too terrible. Most of the time.
The “Others”
I’ve read enough about others’ experiences with jQuery Mobile to know it’s not up to par like Sencha Touch is. I skipped over it a while ago, and don’t have immediate plans of working through another framework’s growing pains just yet. I guess this post isn’t quite fair enough to Sencha because it’s really the one I know most about. So let me reiterate – others have been saying Sencha Touch really is the best one out there. And truth be told – Sencha Touch can produce some really good apps.
The problem you’re going to run into with these “web” frameworks is going to convince your client and end users that the app is undetectably different than native apps. That means they should be just as fluid and work just as seamlessly as native apps. Most of the time I don’t see that parity. Animations can be jerky, the UI looks mostly native, but you can tell the difference. When it comes down to it, there are simply things you can’t do with web technologies that are pretty commonplace with native libraries. It’s not really JS’s fault, but DOM manipulations are expensive. The more DOM you’re manipulating, the more the responsiveness is going to suffer. Remember when this was a real problem on desktops several years ago? Well, it’s the same on mobile now. It’s frustrating.
Here’s one place hybrid apps tend to really fall behind – interacting with core OS services. HTML5 offers new support for basic features such as address book and some media-related tasks, geo location, etc, but only to a point. As you develop enough hybrid apps, you start to get the feel for things you can and can’t do. PhoneGap has done a great job of providing a good native API and a set of helpful plugins, but it does not solve every problem. New plugin needs still require a native programming to interface with your JS. It gets a bit sticky
Native Learning Curves
The learning curve kept me from iOS development initially. If your only prior experience was most web technologies, it’s understandable. There is a bit of a steep learning curve if most concepts core to Objective C are new to you, but be assured it’s not impossible. It just takes work, as it does with any new language and/or framework. My experience shows that once I started picking up the generalities, the specifics started to fall into place. It gets better. Seek the help of programming books and Stack Overflow. Study at sample projects (Apple and Google both provide them) and understand them.
Finally, Stand
If you’ve read this far, congratulate yourself. I’m not normally this long-winded. Or am I? Anyhow, where do I stand? Which is better? Both. Well. Sort of. I mean, I think if you have the chops for native development and the help of a good designer and UX colleague, do it. I believe that at this point of time, you are going to get the best results from developing native apps, especially on iOS. Hybrid apps, in my opinion, are going to be the most obvious choice when clients are wanting cross-platform apps on limited budgets. I don’t mean this to imply native apps are prohibitively expensive. Rather, hybrid apps do allow you to perform a bit of a shortcut by only having to write one codebase for multiple platforms. The question of whether or not the tradeoff is worth it. Do you feel you can create as quality of an experience with hybrid apps as with native? That’s for you to answer, and then to explain to your clients. You may be of the opinion that native apps are most ideal (that’s how I feel), however sometimes the decision isn’t yours – directly or indirectly.
I’ll probably get some flack for this. Remember, use the right tool. Sometimes that’s determined more by budget than technology. A client looking to develop a low-cost app for iOS, Android, and Blackberry will not get quite the same experience as if the same app were developed separately for each platform. Remember – you pay for cutting corners. Some people are OK with that.
To answer the post’s title question? Not yet. I think there’s still plenty of catching up to do, however I don’t have many hopes for full OS-level integration for web technologies (remember, the web is platform-agnostic).