4. Answer
That depends…
• App complexity • Maintenance plans
• Target platform • Future scope and overall mobile
strategy
• Target audience
• Connectivity, storage,
• Development team strengths and synchronization, security…
experience
www.intelliware.com 4
5. Know you’re purpose
If you’re not ready to answer questions about why you’re
building
b ildi a particular mobile app you’re not ready t
ti l bil ’ t d to
answer the questions of Native vs HTML 5.
www.intelliware.com 5
6. Know you’re purpose
• Who is the app for? • Who will develop the app?
• Internal audience? • Internal or outsourced team?
• C t
Customers? ? • T
Team language/platform experience?
l / l tf i ?
• Both?
• Who will maintain the app?
• What is the value proposition? • Same as development team?
• What problem does the app solve?
p pp • Hours available for maintenance per
p
• Why do users open it? week?
• What are it’s essential functions? • How are support issues handled and
funnelled?
• How will the app be used?
• O li / ffli ?
Online/offline?
• How will t e app e o e
o the evolve?
• In the field, office, home, on the road? • Is app one-off or part of larger mobile
strategy?
• Local vs cloud data? • Will future versions be released?
• Are new features already in the pipe?
www.intelliware.com 6
7. Managing Different Forces
• Prioritize Your Questions in Context
• Is the UI/UX plan flexible or set in stone?
• Does your development platform support all planned app features?
• Is your development team comfortable with the development platform/environment?
• Do your current software development lifecycle practices fit with your development
platform choices?
www.intelliware.com 7
8. Technology Considerations
• Using native functions of the device. (GPS, Camera, Accelerometer)
• More native functions, like GPS are being exposed through HTML/Javascript bridge – stay up-to-date on what can
and cannot be done when you choose native vs HTML vs some MADP platform.
y
• Open GL and other low-level UI control
• Game developers typically choose native development and will look to get a value of code re-use by using C++
libraries that can be compiled for the different mobile platforms such as Cocos 2d.
• Offline reliable and secure local storage
Offline,
• HTML 5 does provide local storage but you need to be aware of how this compares to other local storage options in
terms of meeting the project requirements, especially around security and reliability
• Actual speed of development to achieve desired UI
• If the UI relies heavily on native widgets looking like native widgets, this can require a lot of fussing to achieve in
y g g g , q g
JQueryMobile or Sencha Touch versus the seconds it takes to create the same look using the native IDE UI tools.
• If the UI relies heavily on a custom look that bares little resemblance to any native UI widgets it could be easier to
achieve in HTML 5 than it is to customize native widgets. (Of course that will depend on the different native platforms
and the widgets involved.)
www.intelliware.com 8
9. Technology Choices
HTML 5
Strictly speaking you can choose to HTML 5 for your mobile applications
and not use any 3rd party libraries. You can write y
y p y your javascript, css, and
j p, ,
HTML to produce your mobile application and you will likely end up with
something that is exactly what you want with an architecture that suits your
needs. However you will not have saved much time or money. When we say
HTML 5 we really mean choosing an HTML library to jumpstart our
development effort:
• Common Libraries
• JQuery Mobile
• Sencha Touch
• Dojo Mobile
• Meteor
www.intelliware.com 9
10. Technology Choices
Native
Native apps typically refer to apps written using the native SDKs of the OS
providers. In some cases the OS provider has provided multiple SDKs, in which
case native refers to the SDK that compiles directly to the device chip
architecture:
• Common Native Languages
• iOS – Objective C and C and C++
• Android – Java, C and C++
• Windows Phone 8 – .Net, C and C++
• Blackberry 10 – C and C++
y
Native app development can also be accelerated using 3rd party libraries, such
as the Cocos 2d library for game development, which can used cross-platform.
www.intelliware.com 10
11. Technology Choices
Hybrid
Hybrid typically refers to an app that uses a mix of Native code and HTML 5
in order to deliver features There are different approaches to hybrid:
features.
• Hybrid approaches
• Native app wrapper where all the real development work is in HTML 5 which is served up
by a nested native Web View widget Wrapping the native app allows the app to be
widget.
distributed through the App Store and it allows the app to communicate with native API’s
through a Javascript bridge.
• Native app with embedded HTML used for less interactive content to get some reuse of
code across platforms while still d li i a primarily native f li app.
d l tf hil till delivering i il ti feeling
• Native with HTML content pushed to app allowing app content, functionality and look and
feel to all be updated without putting the app through a store review. (Depending on the
type caching involved this will require extra connectivity logic.)
www.intelliware.com 11
12. Technology Choices
MADP (Mobile Application Development Platform)
People always ask Native vs HTML 5 but the real question behind that question is usually “What’s
the quickest, cheapest, fastest, best way to deliver a mobile app across ALL my channels and
make ALL my customers/employees/users happy?”
Other’s in the mobile space have built products that attempt to be the solution to this question:
• Worklight
• Brings together other tools like Sencha Touch and Cordova and automates how they all stitch together. Includes
server to facilitate building backend connectors for enterprise integration.
• Kony
• Proprietory tool built in India that uses Javascript or Lua as the primary development language and produces native
or HTML 5 output. All Kony apps require a Kony server (like Worklight) and a key area of focus (like Worklight) is
enterprise services integration.
• Cordova (formerly Phone Gap)
• Opensource Apache project. Early Phone Gap projects were criticized by users for failing to provide a decent UI
experience. (Original O’Reilly iOS app built by the Phone Gap team is an example of one such failure.)
• Appcelerator
• You write in Javascript and it generates native apps.
www.intelliware.com 12
13. Costing Your Solution
Many people assume 3 platforms means taking the estimate for 1 platform
and multiplying it by 3. This doesn’t hold.
py g y
• Team experience
• Do you have developers experienced at your native platforms?
• Do you have developers experienced in y
y p p your MADP or in HTML 5 and all the technologies
g
those will entail. (Javascript, CSS, HTML, etc.)
• Porting or rewriting apps is faster
• Experience shows us that once a p j
p project is complete it is often faster to rewrite
p
• Do App features match well with Development Platform
• Make sure you and your team have an idea of how you will build each feature, some
features will be quick to develop using one platform while slow to develop using another
www.intelliware.com 13
14. Other Factors
• Testing
• Unit testing and Integration testing are both areas that complicate the technology choices faced
when choosing between HTML 5, Native, Hybrid and a MADP for mobile development.
• Home-grown testing solutions can become brittle and break as Apple, Google, Blackberry and
Microsoft evolve their toolsets and SDKs.
• Server
• W kli ht and K
Worklight d Kony b th provide a server piece f all apps. Th f
both id i for ll The focus i on enabling enterprises t
is bli t i to
expose complicated and heavy backend services through mobile APIs, so for apps that require this
type of backend integration the question becomes less about Native vs HTML 5 and more about
how easy it will be to provide that backend integration.
• O
Other Requirements
• Requirements outside the scope of specific app features may also influence choices. Today, choices
need to be made in the context of the entire Mobile Strategy for an enterprise, not isolated to
considerations about a specific app.
www.intelliware.com 14
15. Bake-Offs
One way to assess your technology choices is a bake-off. Create a small
POC (proof of concept) p j
(p p ) project and split y
p your dev team into 2 or more
smaller teams and have them build the POC using your different platforms.
• Pros
• Prove out whether platform will support desired features
• Assess actual speed of development
• Cons
• Adds to costs because now you need time in your project to do the bake-off and assess the
bake off
results
• A bake-off may not be long enough or complicated enough to truly evaluate platform and
may provided a skewed view of the world
www.intelliware.com 15
