Today, Mobile apps have become an integral part of enterprises and businesses can no longer afford to ignore them. Recent surveys and studies all point to the same conclusion, ‘This is the year of the mobile business app’ and finally accept that mobile is not only here to stay, but also offers compelling benefits i.e., they let you operate anytime and anywhere, bringing productivity beyond the confines of the office, salespeople have access to real-time product data, customers have another way to interact with your business, or even make purchases.
EXECUTIVE SUMMARY
Today, Mobile apps have become an integral part of enterprises and businesses can no longer afford to ignore them. Recent surveys and studies all point to the same conclusion, ‘This is the year of the mobile business app’ and finally accept that mobile is not only here to stay, but also offers compelling benefits i.e., they let you operate anytime and anywhere, bringing productivity beyond the confines of the office, salespeople have access to real-time product data, customers have another way to interact with your business, or even make purchases.
Needless to say, effectively reaching your mobile audience is no longer as simple as selecting your target platform, developing and deploying the app. The rapid changes in device adoption, mobile OS share, and user behavior have a significant impact on the mobile development process. These app’s traverse a gamut of industries – from media and entertainment, travel and lifestyle to financial services, education and healthcare. There are many decisions to be made in this phase which can make or break a mobile app project.
“Knowing the answers to these questions is not just vital but business critical. A faulty decision can completely ruin the functionality and future of the app. And, “One Size fits all” may not hold true for Mobile App development.”
Making the correct choice
Businesses trying to build mobile apps are running into the below mentioned strategic confusion(s) which will influence the results of the mobility initiative taken. As the user base for mobile app(s) is diverse, below are few questions which need to be considered and answered before deciding on a Mobile app development strategy:
Who are my targeted audience?
Should the app be targeted across all available Mobile OS platforms?
Should I simply start with a mobile website?
Should we develop a native app (one for each, multiple mobile OS platforms) or a Hybrid app or a Mobile Web app?
Should the app require access to device functionalities such as GPS, Camera, Contacts, Calendar etc?
Should the app be UX/UI consistent across multiple mobile OS platforms?
Should this app require regular updates, to retain the user base?
Should the app generate revenue?
Is it worth spending Time, Money and IT resources to make an app with 4 different source codes for 4 different Mobile OS?
Will the decision taken make any impact on the Design, Development, Distribution and future prospects of the app?
The purpose of this article is not to discover the best development approach, as such does not exist, but rather to list the pros and cons each has and describe the different scenarios or enterprise requirements that best fit one or the other.
KNOWING THE MOBILE APPS
There are 4 types of mobile apps: Native, Web, Mobile Web and Hybrid. As the debate rages about which approach is best, here we present a feature-wise comparison of each to help you make your own choice. First, here is a brief introduction of the Top 4 Mobile OS players:
Languages
Objective C, C++
Java
(Some C, C++)
Java
C#, VB.NET
Tools
XCode
Android SDK
BB Java Eclipse
Plug – In
Visual Studio, Windows Phone Dev Tools
Executable Files
.ipa
.apk
.cod
.xap
App Stores
Apple iTunes
Android Market/Google Play
Blackberry App World
Windows Phone Market/Store
Native App
Do you use Microsoft PowerPoint, Word or MS Excel? These are the applications that run directly on your computer, and smartphones have these as well. In a nutshell, Native apps are built for a specific platform (e.g. iOS, Android, RIM, Windows Phone, Symbian, Samsung Bada etc.), with the platform SDK, tools and languages which are provided by the platform vendor (e.g. xCode/Obj-C for iOS, Eclipse/Java for Android and BB, Visual Studio/C# for Windows Phone).
Mobile Web(site)
Mobile Web(site) runs in a phone’s inbuilt/external browser, is internet enabled with a specific functionality and doesn’t require download/installation on the device. These are server-side apps, built with any server side technology (PHP, Node.js, ASP.NET) that renders HTML and is styled for rendering well on a device form factor.
Mobile Web App
Web app’s use the same web technology which is used for building a Mobile Web(site) and allows developers to create a single app that can be run on a variety of devices, with the only difference being the below characteristics.
Hybrid Axc.cpp
Hybrid app(s) are written with the same technology used for mobile websites and mobile web implementations, and are hosted inside a native container on a mobile device. Hybrid mobile apps, as the name implies, is the marriage of web technology and native execution. So, they are made partially from native components, partially from web components, and run partially on the device, partially on the web. While one hybrid app could be 90% web and 10% native, another one could be 50% web and 50% native.
AN OVERALL COMPARISION – THE SCORE CARD
Here we highlight the significant, noteworthy differences between Native, Hybrid and Mobile Web app(s).
FACTORS
NATIVE
HYBRID
WEB
PRODUCT
DEVELOPMENT
Development Language
Native Only
Native and Web/ Web Only
Web Only
# Of Developers Required
1 per platform
Many
1
Device Knowledge Required
Yes
Partial
No
Development Cost
Expensive
Reasonable
Reasonable
Development Time
Long
Short
Short
Time To Market
High
Moderate
Low
Market Reach/Capture
Few Devices
(targeted platform)
Moderate Devices
(targeted platforms)
All devices
(internet enabled)
# of app(s) needed to reach major Mobile OS platforms
4
1
(separate code base)
1
Platform Affinity
Single
Multiple
Multiple
App Portability
None
High
High
Code Portability/
Reusability
None
High
High
UX AND
ENGAGEMENT
Device Features Access
Full
Full
Low
Access to Native API’s
High
Moderate
None
Advanced Graphics
High
Moderate
Low
User Experience
High
Moderate
Low
Speed/Performance
Very Fast
Native speed as necessary
Fast
Installation Experience
High
(from app store)
High
(from app store)
NA
(via mobile browser)
Upgrade Flexibility
Low
(through app store)
Moderate
(through app store)
High
(instant update’s applied)
BUSINESS
MODEL
App Store
Available
Available
Not Available
Distribution
App Store/Market
App Store/Market
Internet
Approval Process
Mandatory
Low Overhead
None
Approval (Releases) Time
1-2 weeks
1-2 weeks
Continuous
App Maintenance
Difficult
(app store approval)
Moderate
(app store approval)
Easy
(instant update’s)
Revenue
Yes
(shared with app store)
Yes
(shared with app store)
Yes
(through ads)
Purchase Type
Free
Paid
Free
Paid
Free
Discoverability
Yes
(through app store)
Yes
(through app store)
Yes
(search, hyperlinks, ads)
Security
High
Moderate
Moderate
(SSL dependant)
From the above, it is clear that no single approach delivers all of the benefits, all of the time. There is an obvious tradeoff between user experience, application functionality, development costs, time to market and internal IT resources.
CHOOSING THE RIGHT APP
Native – When Performance Matters
Pros
Cons
Better performance, neat transitions, tighter integration with platforms
Built for a specific platform/device and is expensive
Can store more data offline, runs offline, lower network usage at runtime
Code can’t be re-used i.e., the codebase needs to be re-worked for each OS
Available in App Store and hence can be easily searched for on the device
Time to market is high, maintenance cost is also high due to porting efforts
Full access (integration) to the device’s hardware and OS features/API’s
App must be approved by an App store/Market, which is time consuming
Implicit installation of an app to the device’s home screen
App generated revenue must be shared with the app store (30/70)
App Store handles purchase transactions; generates revenue on downloads
User has to install/update the apps manually, after approval from app store
Web – Write Once, Run Everywhere
Pros
Cons
Runs in the phone’s browser and works across all the devices
Commerce model is the only option, if the app has to generate revenue
Uses the same code base to support all devices (iOS, Blackberry, Windows, Android)
Unpredictable performance due to high dependency on internet connection
No approval process is in place ; Instant updates can be applied to the app(s)
Restricted access/integration to the Device API’s
Decrease in app development costs with a better time to market
Maintaining the web page’s based on screen resolution is difficult
Portability is high across device platforms
Unavailability of App Store
No revenue sharing with app store/market
Lack of Native UX/UI ; No offline access
Hybrid – Fully Loaded with Better Fuel Economy
Pros
Cons
Allows you to capitalize on the single codebase offered by web technologies
UX better than Mobile Web apps but not on par with Native apps
Has access to device APIs ; generates revenue on app downloads
Requires app store approval and is time consuming ; No instant app updates
Presence of App Store and can be searched for easily ; better time to market
App generated revenue is still shared with the app store (30/70)
Portability across platforms is high with decrease in total cost of ownership
Possible lower performance of the app at times, due to browser dependency
.
CONCLUSION
A Better Mobile App Strategy !
If you’re wondering which one is the best type of app, unfortunately the answer is: “It depends”. As you can see from the above score card, the decision of which technology to go with is often dependent on what your app will need to do, Time and Budget, Target audience and the IT resources required.
The conclusion is that building and supporting 3 or 4 separate code bases is not a financially desirable long term strategy. Enterprises that choose the native code route (or have requirements forcing them to use it) will incur significant costs as they repeatedly map app logic to each new platform. Enterprises that choose a portable code strategy let the programming platform vendor incur the costs of mapping logic to each platform and have lower costs by developing and maintaining a single code base, as shown below:
As this paper attempts to explain, the answer lies not in one development approach, but rather in a flexible solution: one that can harness the benefits that each provides and support not only the development of a first mobile app, but of all future apps, regardless of the initial development approach, thus supporting the security and scalability integration of the apps.
A Quick List – Decision Maker
Here, we present a list, for a quick decision process on the type of app to approach for.
WHEN TO
WHEN NOT TO
NATIVE APPS
High Performance, rich UI/UX
More than 2 platforms are targeted
Heavy on OS and Device features
More or less replicates Web apps with very few device features
Complex network communication
Standard restful ; Widget based apps
Canvas based apps
Time to market is crucial/urgent
Only 1 or 2 platforms are targeted
Smartphones/Audience diversity is targeted
Apps for Games, Entertainment, Sports
Instantaneous app updates are recommended
HYBRID APPS
Fairly Simple UI ; Complex backend
Only 1 platform is targeted
Optimize performance, cost and time
Access to Device API’s is never required
Take advantage of device features/API’s
UI/UX and Performance is not the criteria
Make the experience feel like native app’s
Instantaneous app updates are required
More platforms with a single code base
is preferred
App dependency on the web is high
WEB APPS
Time to market, Saving costs are critical
High performance is required
Performance, UI/UX is not so important
Heavy on OS and Device features
Instant app updates are recommended
Complex Network communication
Many platforms/devices are targeted
UX plays a crucial factor
Static UI, Generic look and feel
Only 1 platform is targeted
Access to Device features is minimal/low
No app updates are required
Subscription based services such as
news, weather, retail, shopping, social apps
Developing apps for Games, Sports,
Travel and Local, Entertainment
________________________________________________________
This post has been penned down by:
Kiran Gopisetty