2. 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 2010, Amazon's Jeff Bezos commented that
customers had ordered “more than $1 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 (16%).
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:
3. 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.
4. 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.
5. 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 1 below, this team of four is
costing the business about $500,000 annually.
Role Headcount Yearly Hours Annual Cost
iOS Architect 1 2,000 $200,000
iOS Developer 3 6,000 $300,000
Total 4 8,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:
* 1 JavaScript/HTML 5 architect
* 3 JavaScript developers
* 1 iOS engineer
* 1 Android engineer
* 1 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.
6. “This approach allows for better development and product flexibility,”
Burgert says. “Also, by using web technologies in portions of the app, the dev
“According to the challenges Globant
team can have more automated testing options, and even A/B testing for
better product management and feature decisions. There can also be was facing I can say that we proved
sharing of components between a web development team and a mobile to have the right skills and ability as
team.” a company to produce a testing
Burgert points out, however, that the hybrid strategy is not appropriate for
working team in only two weeks as
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, well as providing all the necessary
or a very polished entertainment product. “When the app is very demanding resources for the project, such as
in terms of user experience, then hybrid might not be appropriate,” he says. HHRR recruiting, IT infrastructure,
“A racing game that uses the accelerator on the phone, or one that requires
servers, communications, power, etc,
a high degree of responsiveness, for that you need to go native. A hybrid app
tends to perform similarly to a browser-based app.” within the time schedule required by
Orbitz business”, expressed
The development team needs to perform an analysis that looks at the Alejandro Stornelli, Globant’s
performance requirements of the app, the user experience, and whether or
Technical Director for Orbitz
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 account.
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 1 2,000 $200,000
JavaScript Developer 3 6,000 $300,000
iOS Developer 1 2,000 $100,000
Android Developer 1 2,000 $100,000
WinPhone Developer 1 2,000 $100,000
Total 7 14,000 $800,000
Compared to:
Native Team 12 24,000 $1,500,000
Hybrid Team 7 14,000 $800,000
Savings 42% 42% 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 US Globant Argentina Globant UK
34 Hayden Rowe Ingeniero Butty 240 6th floor Sistemas UK LTD
Street Suite 122 Laminar Plaza Tower Central Point 45 Beech Street
01748, Hopkinton, MA C1001AFB - Capital Federal London | EC2Y 8AD
1-877-798-8104 +54 11 4109 17 00 +44 20 70 43 82 69
Fax: +1 (774) 759 3019 Fax: +54 11 4109 18 00 Fax: +44 20 79 45 61 26
