Native vs HTML
- 1. Native vs HTML 5 An Overview of Considerations Presented by Marc Henderson
- 2. Number 1 Mobile Question Native versus HTML? www.intelliware.com 2
- 3. Answer That depends… www.intelliware.com 3
- 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