Hybrid Mobile Development: A Cost-Effective Strategy for Building Cross-Platform Mobile Apps

Hybrid Mobile Development: A Cost-Effective Strategy for Building Cross-Platform Mobile Apps

Smartphone sales totaled more than 480 million last year, surpassing sales of PCs, according to figures from research firm Canalsys. The personal computer as we ve known it is not headed for extinction, but clearly the smartphone could become the dominant device for communicating and using the web. Consider this other data: In 200, Amazon's Jeff Bezos commented that customers had ordered more than $ billion of products using a mobile device. Today, nearly 90 percent of the world s population subscribes to a mobile service; that s about 6 billion users, according to the International Telecommunications Union. Granted, not all of those subscribers are using smartphones, but the number reflects an essential truth: People want a mobile connection. The question, then, is not Should we develop mobile applications but rather How should we develop mobile applications? The diversity of mobile platforms and the variety of development tools make How? a complex question. A business has to decide first which device or devices to develop for. Currently the most common smartphones are Android-based models and iphones, with 48 percent and 43 percent of the US market, respectively, according to the latest Nielsen survey. IDC predicts that three years from now, Android will command half the smartphone market, followed by Windows phones (20 percent) and then iphones (6%). Many software providers will want to sell apps to users of all three platforms. And as a result of IT consumerization with employees bringing their personal devices to work organizations will have to build business applications that run on all three platforms as well; that is, that run on the most popular models. Cross-platform development will be standard practice. That's great for users, but presents a variety of complex challenges for software creators. The developer choices begin with the two types of app delivery mechanisms: Web delivery (URL or web apps) and app-store delivery (Google Play or itunes, or enterprise app stores). The most important consideration is choosing the programming or markup language for writing the app, which typically would be:

Native technologies: Objective-C for the iphone's ios; Java for Android;.NET for Windows Web technologies: JavaScript, HTML 5, CSS3 Hybrid technologies: Using both native and web technologies in the same app A software publisher will typically want to establish a consistent look-and-feel and user experience (UX) across different devices. While this is relatively simple with a web app, it is a considerable challenge when porting between different mobile environments. The developer who wants to follow a cross-platform strategy has to contend with the different user interface guidelines for Android phones and iphones and Windows phones. In order to create a consistent UX, these guidelines dictate how developers must handle all the elements of the interface, from icons to buttons to input screens. This reality of multiple platforms pushes publishers of apps to consider strategies for cross-platform mobile development, making sure that they can scale their development teams in a cost-effective way, says Andrew Burgert, general manager, mobile, for Globant, a software company that has designed products for Android and ios devices. Globant's clients have included JP Morgan Chase, Cars.com, LinkedIn, and Salesforce.com. But a strategy that involves having dedicated teams building mobile apps for each platform becomes unwieldy and expensive. Plus, it sacrifices the ability to share and re-use components between the platforms. Finding sufficient numbers of qualified programmers and designers to staff these separate teams can also be a hindrance. Some mobile software developers, including Globant, have instead adopted the hybrid paradigm. We believe the hybrid approach, although not applicable for all apps, is the key to achieve a cost-effective multiplatform mobile strategy, Burgert says. The Hybrid Process Consider a typical business scenario. A company wants to develop an app to help its salesforce manage customers. The company could build a web or URL app and give the sales team a link to the app, which they could access from most mobile devices.

The company could also develop an app that would be pushed from an app store to the mobile devices. This latter approach would allow for software that provides a more robust user experience, but it might not be necessary or worth the expense in this case. (An app that consumes more phone capabilities and resources, such as an action game, however, would be best delivered as an app store app.) If the company chooses to deliver the customer-management app as a URL or web app, it will have to build it using web technologies, which usually means JavaScript and HTML 5. These technologies allow within a browser the sorts of graphics and transitions and user experience provided by an app store app. As Globant's Burgert points out, the developers building this app can achieve a high level of user satisfaction with this approach, even with standard processes that allow the user to bookmark the app on their device's home screen with an icon, which then launches the browser and links to the URL app. After building the URL app, the developers can also choose to wrap it in a WebView in order to ship the app to an app store for downloading. If created appropriately, the UX would be extremely similar, and the development team could make use of native features of the smartphone if needed, Burgert says. This is an example of hybrid development, in which both native and web technologies are employed. HTML and JavaScript would be interpreted in the WebView without the user noticing. With an app that exists on a smartphone, developers can implement features that would not be possible if the app was accessed through a browser. The app can take advantage of photos or contacts or other files stored on the phone, and also tap into native features of the device. The developers can make native API calls, or use JavaScript and a connecting framework, such as PhoneGap, to link the JavaScript code to the phone's native capabilities. This hybrid strategy, based on open source standards, allows the publisher to reuse web components that come from other areas of the organization, or create components that can be used throughout. As Burgert explains, there are two ways to develop using this hybrid approach: * Build user interface code into the app * Have the app pull UI code from a server, similar to a regular browser With the first option, the user experience tends to be smoother; the user does not have to wait for the app to pull the user interface code into the phone. Furthermore, there is room for offline capabilities if an Internet connection is not available. With the second option, the user has to wait while the app interprets and renders the front-end code from the server. In this case, no Internet connection means no app. From a developer standpoint, though, this approach does make it easy to update or improve the user interface as needed. This could be an appealing capability to enterprises in particular.

The customer-management app referred to earlier could be written in the native code of the smartphone, fully using the device's potential, and perform very well on that platform. But if the development team has to port the app to another device from Android to iphone, for example the team will very likely have to be augmented with people who have the necessary knowledge and skills, or a new team brought in. The launch timeline for the ported app will most likely have to be extended. The Business Case To analyze the cost side of the development equation, let's consider a medium-size business that already has built a few iphone apps. For purposes of this discussion, let's assume they have three ios developers and an ios architect. They are busy maintaining the released apps and working on another one. Based on estimates in Table below, this team of four is costing the business about $500,000 annually. Role Headcount Yearly Hours Annual Cost ios Architect ios Developer Total 3 4 6,000 8,000 $200,000 $300,000 $500,000 Now, as happens often today, the company's managers decide the iphone apps need to be ported to Android devices and then to Windows Phone devices as well. The chief technical officer estimates that he will need to expand staff considerably in order to have the manpower but, more importantly, to have the necessary Android and Windows Phone competency. In this scenario, he does not ask for additional staff to help with business analysis, interface design, or testing; in reality, these additional skills would most likely be part of his request, but for simplicity's sake, this example includes only actual development personnel. Despite the CTO's minimalist request, the CFO says only three new staffers can be hired. The CTO can panic, or he can regroup and adopt an innovative approach. In this situation, a hybrid strategy would allow the development team, only slightly enlarged, to build the app for the two new platforms cost-effectively. For this hybrid plan of action, the CTO would need to build the team as follows: * JavaScript/HTML 5 architect * 3 JavaScript developers * ios engineer * Android engineer * Windows Phone engineer Table 2 breaks out the costs for this team, and demonstrates that for the scenario we've described and for similar situations, a hybrid development strategy enables a company to build for multiple smartphone platforms in a very budget-friendly way.

This approach allows for better development and product flexibility, Burgert says. Also, by using web technologies in portions of the app, the dev team can have more automated testing options, and even A/B testing for better product management and feature decisions. There can also be sharing of components between a web development team and a mobile team. Burgert points out, however, that the hybrid strategy is not appropriate for all types of mobile software. For example, when the app requires a high level of performance, like a financial trading app, a game with complex graphics, or a very polished entertainment product. When the app is very demanding in terms of user experience, then hybrid might not be appropriate, he says. A racing game that uses the accelerator on the phone, or one that requires a high degree of responsiveness, for that you need to go native. A hybrid app tends to perform similarly to a browser-based app. The development team needs to perform an analysis that looks at the performance requirements of the app, the user experience, and whether or not code should reside on the smartphone or can be pulled from the server without hindering operation. The cost analysis in Table 2 presents an exercise that any CTO needs to conduct before deciding which development strategy is most financially acceptable. For his company, John Doe, technology director for Acme Corp., summarizes the benefits of a hybrid strategy like this: "We see great value in unifying our mobile initiatives across different platforms with a hybrid approach. It makes sense from a talent and business perspective, while allowing us to push product out faster." JavaScript Architect JavaScript Developer ios Developer Android Developer WinPhone Developer Total 3 7 6,000 4,000 $200,000 $300,000 $00,000 $00,000 $00,000 $800,000 Compared to: Native Team Hybrid Team Savings 2 7 42% 24,000 4,000 42% $,500,000 $800,000 47% Features of Web, Native, and Hybrid Strategies Web: true multiplatform, rapid UI changes, online only Native: single platform, high-performance apps, full access to device features, offline capabilities Hybrid: multiplatform, flexibility for native API call access, offline capabilities For more information visit www.globant.com Globant San Francisco 535 Pacific Avenue Suite B San Francisco, CA 9433-877-798-804 Globant Argentina Ingeniero Butty 240 9th floor Laminar Plaza Tower C00AFB - Capital Federal +54 409 7 00 Fax: +54 409 8 00 Globant UK Sistemas UK LTD Central Point 45 Beech Street London EC2Y 8AD +44 20 70 43 82 69 Fax: +44 20 79 45 6 26