Hybrid and HTML5 technologies are now the de facto standard for mobile development. We see few enterprises developing large-scale external-facing applications using pure native technologies, primarily because of the flexibility and OS platform reach hybrid provides.
While there are many benefits to hybrid technologies, there are also challenges that surprise many organizations. Furthermore, we have seen many technology organizations minimize the technology risks when pitching the hybrid approach to the business teams. Most of the times these are honest mistakes, but business teams should understand the basics of mobile development to ensure their projects stay on track.
We act as sherpas to both business and technology teams as they execute their mobile strategy – often after helping them build their mobile strategy. In addition we’ve been hard at work developing our own line of mobile products using hybrid technology to fill gaps in the marketplace. We know first hand the many, many pitfalls in developing mission-critical mobile applications – especially in highly regulated industries.
Probe your teams designs and [require good architecture]. The line of business will ultimately be held accountable.
We believe line of business teams should understand the following concepts in order to work more effectively with their technology partners:
- What does Hybrid mean?
In a mobile application context, the term hybrid refers to a pattern of using a mixture of browser and native OS technologies. In practice, most hybrid applications are really web applications wrapped with a native shell that provides limited access to native-app only functionality, including the ability to be deployed to the app store. HTML5 blurs this description by also providing access to native functionality through browsers that until recently was only available to native applications. Cordova (aka PhoneGap) is a critical tool for bridging web and native technologies.
- What is HTML5?
HTML5 is simply the next version of the standard web browser markup language HTML. HTML5 provides standard access to functionality, such as the camera or GPS, that previously was only available to native applications. It’s important to note that HTML5 is a standard specification and not an implementation. Browser makers do the actual implementation and are responsible for deciding how close they’ll follow the spec (if at all) and in what timeframe to implement the features. There are entire web sites devoted to tracking HTML5 functionality in browsers. http://caniuse.com is one example.
- Hybrid projects are not necessarily faster – initial time to market might be slower
- Thorough testing remains vitally important and hybrid doesn’t reduce the impact on testing
Remember that each browser version on each version of each OS actually does the work of executing your hybrid code. In theory they all follow the standard, but not always. Sometimes it’s a bug and sometimes it’s a conscious decision. Hybrid doesn’t change your test plan much. You need a thorough testing strategy for validating your functionality in general, then validating across OS and browser version combinations as well as with variations of signal strength, online and offline modes, and so on.
- Performance is almost certainly slower with hybrid
By definition you’re adding at least one more layer of software above actual processor execution. In practice you’re often adding many more layers and reducing your control and visibility significantly. You have to be really good – and sometimes lucky – to approach the performance of native technology with hybrid applications. The key is to accept this and use hybrid technology where performance isn’t an issue and native technology where performance is critical – while balancing your need for a cross-platform code base.
- Debugging is awful with hybrid. Simply awful.
- Great software design is even more important with hybrid
Software design skills are critical when you’re trying to cover many operating systems with one code base (possibly including targets that don’t even exist yet), while working with more blunt tools. Hybrid app architects must thoroughly understand where each native technology varies from the common approach and plan for it to change over time as the project evolves. Furthermore, performance considerations will almost necessarily change some of the application flow as the final app is tuned and bottlenecks are removed.
- Server side components are critical with hybrid and are often overlooked until it’s too late
For some reason, mobile developers underestimate the need for “mobile application server” components. I’ve been debating this with developers since 2007 in the early mobile banking days. I continue to see teams dash ahead building an app without a mobile-specific server-side component built-in and they ultimately end up building a mobile application server themselves bit-by-bit as they discover they need functionality. Unless you’re an application server company, this is probably a huge waste of your resources and your time to market is delayed significantly. Many developers will delight in getting to build that infrastructure. Probe your teams designs and prevent this from happening. The line of business will ultimately be held accountable.
- Hybrid requires deep understanding of all your underlying mobile operating systems – don’t choose it so your technology team doesn’t have to learn each OS
- Don’t compromise on a stunning user experience
Last but definitely not least, your user experience will make your app a success or failure. The unspoken truth is that hybrid is often chosen out of developer laziness and the user suffers. Developer laziness isn’t necessarily a bad thing in that it often creates productivity improvements and innovation. However, the business team must unceasingly be the voice of the user. It is difficult to provide the same level of usability and performance with hybrid as with targeted pure-native technologies, but it is possible. The team has to design for an amazing UX and the testers and project sponsors must insist that developers continue to find ways to delight the user when faced with technical roadblocks. They will be tempted repeatedly.
Those of you who know me have probably noticed reusability as a recurring theme for me. I got started in mobile in the early days at mFoundry and spent time at Kony. I was attracted to both companies because of their write-once, run everywhere innovations.
I also was an object-oriented software developer for almost a decade before moving to the business side. One project in the 90s needed to support 23 different UNIX print subsystem variations. Obviously, designing for reusability was a large part of that experience.
Today HTML5 still provides hope for massive reusability to many mobile developers. However, Mark Zuckerberg famously said “betting too much on HTML5 was [Facebook's] biggest mistake.” I’m a believer that HTML5 and cross-platform technology like Kony can provide reusability balanced with innovation and functionality. However, great software design has always and continues to be the key to using a variety of tools to build an elegant solution.
Great software design has always and continues to be the key
In the end though, the question is not just which tool to use, but rather how to design the right solution, then choose the right tools to solve the problem.