Those Who Do Not Remember History…

It seems like there are two groups of mobile developers out there.  The first group thinks that using HTML5 with PhoneGap (or a similar tool) will save them time and money.  The second group feels that such a setup adds complexity, removes a lot of the polish from your app, and ultimately adds significant costs to development.  I find myself in the second camp, despite a rapidly-growing number of developers who would disagree with me.  As I watch mobile developers (mostly former web app jockeys) gush about the potential of hybrid HTML/Native apps, flashbacks of every write-once-debug-everywhere toolkit I’ve ever used spring immediately to mind.  They’re not pleasant memories.

I can certainly understand a lot of the arguments.  If, for example, you’re doing native iOS development, you have to hire people who know Objective-C/Cocoa.  It can be hard to find good people with that skill set.  There’s also the tendency for native development— when tackled by inexperienced resources— to be more expensive than web development.  So, you might figure that since you can find a ton of HTML developers, you’ll just switch to HTML5, wrapped with something like PhoneGap for access to native-only features not available via the web.  Problem solved, right?  Perhaps, but now you have a whole new set of challenges.

Proponents of hybrid development tend to ignore several important factors that are sure to impact both the cost and quality of their applications.  First, it’s just as hard to find really good HTML developers as it is Cocoa Touch jockeys, and if you want any kind of polish at all, you’ll need the best web talent.  Second, these teams are actually increasing their staffing requirements from a single core competency to four of them:

  • Core web skills (HTML5 / CSS / JavaScript)
  • A rich web app framework (Sencha Touch, JQuery Mobile, etc)
  • The PhoneGap framework and tools
  • Apple’s iOS development suite (Xcode, the Objective-C language, and the Cocoa Touch frameworks)

Good luck with your hiring.  Third, you’ll spend a ton of time with caching and loading strategies to make the app feel smooth, not to mention all the UI tweaking and everything you’ll need to do to get it just right.  It’s so much effort that, in my experience, most hybrid development teams simply don’t do it— their apps ship with a depressing lack of polish.

Finally, you’re at the mercy of a third-party compatibility layer to be timely with updates when a new system version lands, or when bugs are discovered; if you want to get the newest features in the latest iOS integrated with your app as quickly as possible, native is the only way to go.  Any other approach will automatically put you in “fast follower” territory, at best.

Please note that I’m not saying that if you’re doing native development, your app is automatically good. There are a lot of ways to do native development wrong, and indeed, it seems that most native development groups are working far harder than they have to in order to bring their apps to market, while still ultimately releasing mediocre products.  If you want to save time and money, there are myriad ways to improve your approach to native development without hopping aboard the “Native development BAAAD!” bandwagon, and you can improve your customer experience at the same time.

Start by getting your house in order from the bottom, upward:

  • Make sure your web services are smart enough that you don’t have to code a ton of client-side business logic to decide what UI elements to present.
  • Clean up your model and networking layer so you can avoid a potential mess of spaghetti code every time you add a feature.
  • Simplify and unify your component library, eliminating or merging all of the one-off UIView and UITableViewCell subclasses you’ve got floating around that probably all do the same thing.

Most importantly, strive to create application designs that allow you to use as many built-in framework objects and patterns as possible.  I’m not saying that your app should be boilerplate; devoid of style or brand. I’m saying that you should go get the human interface guidelines for your platform, and follow them.  Learn your frameworks, and understand which customizations are easy, and which might be avoided to prevent headaches.

If you’re creating a ton of objects and patterns to sidestep the framework, it’s likely that you’ve entered the “should be avoided” category, and your app needs to be redesigned.  Those “workaround” objects are expensive twice: they’re difficult and time-consuming to plan and create, and then they’re the first objects to break when an OS update lands, causing you to spend time and money patching them to preserve functionality that probably shouldn’t be there at all.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>