At Redpoint, we’ve been fortunate to be trusted by so many of our clients to do their high-profile mobile and enterprise web development. Historically, the majority of our mobile development has been using native approaches on the iOS, Android and Blackberry platforms. However, more and more of our clients are interested in using a hybrid mobile development approach.

Hybrid development is technique where a mix of native and web technologies are used together to deliver a native app shell (i.e. container) that provides some or most of the user interface using traditional web technologies (e.g. HTML5/CSS3). Although not true in all hybrid development, in our development at Redpoint, we always have data and web content delivered from web/application servers, over the Internet, to the mobile device. The attraction of the hybrid approach is based on the desire to create mobile apps faster and cheaper with existing web development staff.

So let’s get to it, based on our experience developing mobile apps, here is what we’ve learned regarding hybrid development:

The good – What are the positive aspects of hybrid mobile development?

• One of the primary motivators for hybrid mobile development is the desire to reuse existing web development staff and assets. It is possible to reuse some staff with a bit of retraining for the development and maintenance. (Note: We do not seen significant reuse of web assets from mobile initiatives.)
• It is possible to develop certain apps more quickly and get to market faster. We’ve found that larger applications, and especially those that are used to display information to the users (and not gather much input), are great candidates for hybrid development. These types of apps allow for the right economies of scale and provide the acceleration required to override the drag/complexity of dealing with both native and web technologies on one project.
• A significant portion of the web technology implementation can be shared across multiple web platforms. This eases the development across multiple platforms, but still requires some native development on each native device. This ensures each implementation, on a given mobile platform, feels native and works as the user would expect on the given platform.
• Typically has a lower bar of entry, allowing web development staff to get up and running fairy quickly building a basic hybrid mobile app
• Ability to distribute app in all mobile platform app stores

The bad – What are the negative aspects of hybrid mobile development?

• Increased architectural complexity increases potential points of failure during creation and after golive
• More technologies (both native and web technologies) are involved in the project, so it is harder to staff. We’ve found that hybrid projects require specialized skills for short durations. This type of staffing requirement does not usually fit well into enterprise IT departments because of the diversity of skills required and short and sometimes fragmented needs for different skills.
• Does not allow the same level of control over the user interface (UI) and therefore the UI is not “as tight” as with native approaches. Hybrid UIs are not as smooth or snappy as native code.
• Potential poor runtime performance, especially on older phones on apps that are graphic/animation heavy. Using a native approach for animation is generally faster at runtime and less error prone than using hybrid approaches.
• Potential that it  may be more difficult to incorporate platform-specific features depending on selected tools/approach
• May take longer to develop and test using a hybrid approach for apps that are small. Small apps are not necessarily faster to develop and test when you introduce the additional complexities of a hybrid ecosystem.

The ugly – What is not widely known and might be surprising about hybrid mobile development?

Although appropriate in many situations, choosing a hybrid development approach over a native approach introduces significant risk to a development project. A native app has its features mapped against a native platform’s capabilities and is therefore considered relatively straightforward and does not typically experience implementations that don’t work as expected. Using hybrid techniques, your team will undoubtedly encounter technical hurdles and gotchas that are unexpected. If you have experienced team members that are well versed in both web and native technologies, you may be able to recover without much blood, sweat and tears. However, if you have an inexperienced team, you may find some of the issues significantly effect your delivery schedule and budget.

Although we’ve successfully incorporated hybrid technologies into many apps for clients, careful analysis must be performed to evaluate whether it is appropriate. In cases where it is appropriate, it is critical to understand where to use a hybrid approach and where to use native technologies. For example, we’ve found that navigation-related UI elements are best implemented natively so they are responsive. On the other hand, portions of the page that are displaying read-only information are great candidates for hybrid containers for which content is streamed from web servers.

What is everybody learning about hybrid development? Make sure you have experienced team members on your hybrid mobile team and think carefully about where to use/not use a hybrid approach. Each app is different, so don’t get hung up on only what’s been done in the past and be creative with your native/hybrid boundaries. This will better guarantee your project benefits from the use of hybrid development in order to get done faster, cheaper and on more mobile platforms. Hybrid development certainly has it place, and when harnessed appropriately, is a welcomed architectural approach.