- Installable mobile apps for smartphones (Android, iOS, BBOS...), maybe with offshoots into other platforms.
- Most or all of the presentation and functionality (interactivity and business rules) is in web technologies, mostly HTML (5 is popular), JavaScript, CSS, and all the related concepts.
- This is all contained in a (generally generic, off-the-shelf) app wrapper.
If you have been in a meeting where I actually described hybrid and presented it as a valid option, yes, I have changed my mind in just the last few months. I probably should have come around faster, but hybrid is not new, at all. I designed some really very nice products back when J2ME ruled – mostly ones that looked between than native Java. This vendor had a very slick custom browser that let them build very neat products that reacted fluidly (responsive: also not new) to the many device capabilities that were encountered.
And, if you are thinking I am talking out of school because I am attacking your specific project, or methodology, or vendor, or organization I am not. Well, maybe I am in part. But the whole point is that I am not doing so exclusively. I am not turning you in, but have found this is a trend, to the point where I'm ready to start proposing talks to conferences entitled:
Mobile Development in Crisis
A huge, huge number of apps I work on, or with, or just get to make my smartphone work, are hybrid apps. The way to recognize one is that it looks the same on every platform. Generally, it looks like iOS, which isn't right on, say, Android. And this isn't me being an elitist snob. Users get familiar with their device OS style fast, and even lay people in actual studies organizations I've worked for have done, notice when the app is wrong for the platform. That's not just dissatisfaction; these people fail to perform tasks correctly when you don't follow OS guidelines.
But it also doesn't quite look right on iOS, does it? The buttons are just not quite rendered right, the type is always just the wrong size, etc. And when you look real close, you can tell it's almost all raster images, and doesn't have the crispness of a native app. Sorta defeats the purpose of even starting on iOS, doesn't it?
Often, they are just a little more off. It looks like my OS, but not like my actual handset. Form elements, and popup backgrounds and other key items change from one release to the next (and don't even try to track skinning Android and Symbian) but these apps don't seem to notice. Because the widgets aren't native, but simulations in web technologies.
And, they mostly don't act right either. Often, the apps can't run in the background. There are lots of pages, instead of state changes and transitions. They embed features like email or maps that should link out, because they cannot because the wrapper has insufficient custom app hooks. Even interactions are just not quite right; maybe taps make things slide, but dragging doesn't.
They are SLOW. If it's got a splash screen, and it's just a plain old app with nothing exciting going on, it's probably hybrid. The splash screen is to hide the time it takes to load the giant javascript libraries, and launch the wrapper, which amounts to a browser, so it can display the content. Expect to see a lot of animated wait icons inside the app as well.
Why are They so Bad?
They don't have to be, I'll tell you again. And there is some brilliance to the concept of Hybrid development for certain types of prototyping, some internal applications, and so on.
And I was really excited when Facebook did it. They got around some key issues by using their own design language, and avoiding emulating too many controls. Of course, they have a splash screen, and it's not very fast anyway, and... well if you didn't believe my user testing reference above just look up any article about Facebook failing in mobile. It's not a /bad/ app. But it's not great, and for someone of this scale, it better be good-to-great. A lot of money and time apparently can't make Hybrid work well.
But that's a special case. Why are most so bad? Well, it's hard to say this without being mean, but that's not on purpose. So bear with me and don't be offended:
Vendors are lazy, and opportunistic.
Note, I didn't say "developers." I have worked with plenty of good developers at these vendor and offshore agencies. But the agencies themselves appear to always be in it to make a buck, and have perfected the art of getting corporations already inclined to outsource to sign wildly restrictive contracts.
Perfecting the platform? Meh. That can wait. The model seems to be just like your basic enterprise software package. Build a wrapper that sounds good in Powerpoint, can handle a very, very small amount of customization, do not worry about scale or performance, and charge a lot for customization.
Practically, it means lots of features cannot be supported past the wrapper. There's no access to the camera, for example. Or the address book, or any number of features we all expect on mobiles. These can totally be built in Hybrid, but practically are unavailable to most implementations I work with. Even popups are difficult or impossible to launch in some cases.
Customization past brochureware -- of pages with text and images, and navbars sorta like iOS means branching the code. And suddenly, there are development teams for each platform. Presentation bugs in one do not exist in others, and the same with fixes and content changes. Designs are so locked to a few variations, the HTML inside is less Responsive than a typical web page, and you may experience not just impossibly tiny type, but crazy things like stretched icons.
Oh, and did I mention it has huge security holes? I shouldn't, as I know a little more about these vulnerabilities than I am comfortable with. I know people who won't even talk to you about building secure apps if you are currently using Hybrid. It's not just impossible to fix, but you are so far from considering the answer, it's not worth their time.
Thanks, HP
You made this article easier to write by killing WebOS. I used a Pre for a long time, and actually still own a Touchpad (which is heavily used). It is the dream of Hybrid writ large. It can totally work, when the framework supports it.
Tomorrow (okay, in October) Apple could surprise us all and say they support Web developed apps with this framework, and now it's all better. But this is not where we are now, and I do not see it in the offing.
Until then, native app development is just all around better. If we need to argue that, sure we can do so. But one parting thought: if native development looks expensive, get better developers. Aside from speed, quality and getting a product to your customers that is actually worth it, I promise it's cheaper than outsourcing to 500 guys in another continent.
2 comments:
in response to "A lot of money and time apparently can't make Hybrid work well." read this:
http://www.theregister.co.uk/2012/09/14/facebook_html_5_vs_native_apps/
Good article, and good points.
As I more imply than say, there's a range of ways to be hybrid. I think FB had to go full native for the PR disaster it became, but there's no obvious reason they could not have put in more native features for the slow and bloated parts, and tweaked the way the HTML data was being used.
The only reason I never ranted about how XML is terrible is that it never got enough traction nor was it that obvious when it was used. But, I saw a lot of very bad XML implementations. To the point I became similarly leery when I heard about it being the plan.
No technology is a magic bullet. Assuming it is will lead to a crappy end product.
Post a Comment