Native, Web or Hybrid Mobile App Development?

Native, Web or Hybrid Mobile App Development?
[[gotowebinar page - no slide]] We will begin momentarily. [wait 1 min] [start record 20 seconds before speaking] [[show slide]] Hello everyone, I’m Yonni Harif , head of marketing and online at WorkLight, and I want to thank you for joining us for this edition of the WorkLight webinar series. Today we are going to cover the differences between Native, Web and Hybrid mobile application development, the 3 main methodologies used today by companies launching mobile apps. <CLICK> WorkLight Webinar Series

Agenda Introduction Understanding the different approaches
Native apps Web apps and HTML5 Hybrid apps The business context Q&A Joining us are Ron Perry, CTO, and Jonathan Kempel, head of product marketing at WorkLight. WorkLight is a mobile application platform used by the world’s largest companies to create, run and manage rich, cross platform mobile applications for smartphones and tablets. In this webinar, drawn from our expertise and customer experience, we will provide an overview of the different characteristics of each of these different application types, compare the pros and cons of each, and discuss how each methodology can impact your business. We hope that this webinar will help you make a decision as to the right approach for your mobile goals. Finally, please make sure you submit questions through the webinar console at any time. By sharing your experiences, others with similar challenges stand to learn and benefit. I also urge you to visit our website to learn more about WorkLight, where you can download our platform at dev.worklight.com for an enterprise evaluation. And with that I would like to introduce Ron.

Introduction Native Apps Web Apps Hybrid Apps
<!DOCTYPE html PUBLIC <html> <! - - created > <head><title>XYZ</title> </head> <body> <p> Voluptatem accusantium do Totam rem aperiam eaque </p> </body> </html> <!DOCTYPE html PUBLIC <html> <! - - created > <head><title>XYZ</title> </head> <body> <p> Voluptatem </p> </body> </html> Thank you Yonni, and thank you everyone for joining us. In our discussion today I will explain the differences between native, web and hybrid mobile apps - and how these apply to enterprise mobile initiatives. We’ll start by looking at Native Apps – which you might think of as the “conventional” mobile app. We’ll then look at Web Apps – which are written in HTML and run inside the browser, but you may be a bit surprised at what they can do. And then we’ll look at Hybrid Apps, which are a very interesting combination of two approaches, a combination which is especially important for the enterprise context. Before we proceed, though, I wanted to note that there is no “official” definition of “native app”, “web app” and “hybrid app”. In the webinar, we use these terms as they are generally accepted in the industry – although some companies and experts may have slightly different interpretations; Now let’s dig in to these with more detail <click>

Examples of Purely-Native Mobile Apps
So just to put our discussion in context, let’s take a look at screenshots of a few prominent native apps. In the top row, we’ve got the iPhone skype app, which provides VOIP services through the mobile, the Twitter and FourSquare apps – these screenshots are from Android, and the Shazam app, which listens through the microphone of the mobile device to identify songs. On the bottom row, we can see WordLens, a cool augmented-reality app, which translates words on the fly by processing the images captured by the mobile device’s video camera, and no discussion about native apps could be complete without showing at least a picture of angry birds. The thing that all of these apps have in common - is that they are all purely native. But what does that actually mean?

Characteristics of a Purely-Native Mobile App
A binary “executable image”, that is explicitly downloaded and stored on the file system of the mobile device Distributed through the popular app store or marketplace of the device, or via an enterprise distribution mechanism Executed directly by the operating system Launched from the home screen Does not require another “container app” to run it Makes explicit use of operating-system APIs binary Distributed Well, in this slide, I tried to summarize the most prominent characteristics of native apps: <click> First of all, native apps have binary executable files that are explicitly downloaded to the device, and stored there. This installation process can be initiated by the user, or in some cases by the IT department of an enterprise. <click> The most popular way to get native apps is by visiting an app store, such iTunes or Android Market, but mobile operating systems also provide additional methods to get the app on to the device. <click> Anyways, once the app has been stored on the device, the user launches it like any other service of the mobile device. For example, on iPhone or Android, the app is launched from the homescreen. Once the native app has been launched, it interfaces directly with the mobile operating system, without any intermediary or container application.<click> The app is free to access all of the APIs made available by the OS vendor, and in many cases (although not always), has a look&feel which is typical of that specific mobile OS. Let’s dive into these points a little deeper, starting with the first two: <click> binary, distribution

Native App Development
Application Source Code Software Source Code Resources (e.g. images) SDK Tools The process of obtaining a binary executable image and preparing it for distribution is basically the same for all the leading mobile operating systems. The developers write the source code of the application <click> (which is in human-readable form), and create additional resources, such images, audio segments or configuration info and various OS-specific declaration files. <click>They then use tools provided by the operating system vendor to compile the source code (and sometimes also link it) <click>in order to create an executable in binary form, and then package that binary executable <click> together with the resources of the app, in order to obtain a package that can be distributed to the mobile devices through app stores or other means. These tools, and a few other utilities and files, are usually called the SDK of the mobile OS. The SDK is platform-specific, and each mobile OS comes with its own unique tools – but the process is quite similar for all of them. Let’s take a quick look at the different operating systems, starting with iOS. Compiler, Linker Executable (Binary) Packager Distributable Package App Stores

iOS – Native App Development
Application Source Code iOS Software Source Code Resources (e.g. images) Objective-C, C++, C SDK Tools To create native iOS apps – for iPhone or iPad – developers write their code in Objective-C, C, or C++. They then compile and package the apps using Apple’s tools (they all come bundled in a single IDE called Xcode). The output from the packager is called a “.app” file, and it can be submitted to Apple’s iTunes App Store. Compiler, Linker Executable (Binary) Packager Xcode Distributable Package .app App Stores

Android – Native App Development
Application Source Code Software Source Code Resources (e.g. images) Java (some C, C++) SDK Tools To create native Android apps – developers write their code in Java. For some versions of Android, developers can also include C or C++ code, but this complicates the process and requires additional tools, and developers are encouraged to avoid this unless absolutely necessary. The developers then compile and package the apps using the Android SDK (which has a nice integration with the Eclipse IDE). The output from the packager is called a “.apk” file, and it can be submitted to the Android Market, or transferred to the device from the web. Compiler, Linker Executable (Binary) Packager Android SDK Distributable Package .apk App Stores

BlackBerry – Native App Development
Application Source Code Software Source Code Resources (e.g. images) Java SDK Tools For BlackBerry native apps, the process is also similar: we start with Java source files, the SDK is called “BlackBerry Java Plug-in for Eclipse”, use the SDK tools to create a binary and package it with the resources, get a ‘.cod’ file, and optionally submit to BlackBerry App World, or use over-the-air installation to download to a device. Compiler, Linker Executable (Binary) Packager BlackBerry Java Plug-in for Eclipse Distributable Package .cod App Stores

Windows Phone – Native App Development
Application Source Code Software Source Code Resources (e.g. images) (Sliverlight) C#, VB.NET, etc. SDK Tools And as you might expect, the process is quite similar on Windows Phone 7, except that the source code is written in C# (or other Microsoft languages), the SDK is integrated into Visual Studio, and the resulting distributable is called “.xap”. The app store, in this case, is Windows Phone Market. As a side note, I’ll mention that Microsoft has an additional development option, called “XNA”, which optimized for game development, and allows apps to be written for Windows Phone as well as X-Box 360, but this is less relevant to our topic. Compiler, Linker Executable (Binary) Packager Visual Studio, Windows Phone Developer Tools Distributable Package .xap App Stores

Native App Development Summary
Languages Obj-C, C, C++ Java (Some C, C++) C#, VB.NET, etc Tools Xcode Android SDK BB Java Eclipse Plug-In Visual Studio, Windows Phone Dev Tools Executable Files .app .apk .cod .xap Application Stores Apple iTunes Android Market BlackBerry App World Windows Phone Market So as we can see, even though the overall process is similar for all the platforms, the specifics are different for each one. When we write code for one platform, we can’t use it on others. This means that the process of developing and maintaining a mobile app for multiple operating systems is very expensive. Similar approach, but different source code and expertise results in expensive development and maintenance

Characteristics of a Purely-Native Mobile App
A binary “executable image”, that is explicitly downloaded and stored on the file system of the mobile device. Distributed through the popular app store or marketplace of the device, or via an enterprise distribution mechanism. Executed directly by the operating system Launched from the home screen Does not require another “container app” to run it. Makes explicit use of operating-system APIs So why write native apps all? Because there are benefits. To understand them, <click> let’s look at how the native apps interface with the mobile OS when they execute – the two points I still owe you. Executed directly operating-system APIs

Native App – Interaction with Mobile Device
Mobile Operating System Touch Screen, Keyboard Graphics Touch Events Data WiFi Wide Range of Services Calls, Data GSM Network Audio Microphone Once the native app is installed on the mobile device and launched by the user, it interacts with the mobile operating system through proprietary API calls that the OS exposes. It is through those API calls that the app gets access to all the different hardware components of the device. Using the APIs, the app can interact directly with the touch screen or keyboard, render graphics, connect to networks, process audio received from the microphone, play sounds through the speaker or headphones, or receive images and video from the camera. It can access the GPS, receive orientation information, and of course read and write files on the solid state disk, or access any other hardware elements available today – or in the future (like Near-Field-Communications mechanisms). There are two important things to note about these APIs: -) First, on the upside, they are very fast and powerful, and let you do amazing things – and really tap the full potential of the mobile device. -) The downside is that these APIs are proprietary, and each mobile OS provides its own unique APIs for each function. So if having to write a native app in a different programming language for each mobile OS wasn’t expensive enough, the differences in APIs make porting of an app to multiple devices even more expensive. Native App Speaker API Calls Audio OS-Specific APIs Images, Video Camera Vibration Activation Orientation Accelerometer, Compass Location GPS Data Storage

Native App – High-level APIs and Built-in Apps
Downloaded Apps Built-in Apps Apps APIs API Calls In addition to providing the low-level hardware-access services we just mentioned, mobile operating systems also provide higher-level services that are important to the personal mobile experience, and made available to the user. For example, such services include things like browsing the web, managing a calendar, contacts book, a photo album, and of course the ability to make phone calls or send and receive text messages. Interestingly, those services are exposed by the mobile OSs in two ways: First of all, the OS comes with built-in native apps that let users directly access those services. Each mobile OS comes with its own set of built-in apps. On this slide you can see a few examples from both Android and iOS. The other way mobile OSs expose those high-level services, is by making them accessible to downloadable native apps. This is done by exposing high-level APIs that let the apps interact with those services. The built-in apps are usually allowed to do more with those APIs than the downloadable apps are, but there are many things that downloadable apps can do. For example, an app can read the user’s contacts list, add events to the calendar, or initiate the sending of an . Other APIs let downloadable apps access various cloud-based services that are provided by the OS vendor, such as Push Notifications or In-App Purchases. API Calls High-Level APIs GUI Toolkit Calendar API Contacts, API PushAPI Browser API More API Calls Low-Level APIs File System Network Graphics Camera Multi-tasking Audio More

GUI Toolkit Provides App With “Native” Look
Downloaded Apps Built-in Apps Apps APIs API Calls Another important set of APIs that the operating system provides is the GUI toolkit. Each mobile OS comes with its own set of user interface components, such as buttons, input fields, sliders, menus, tab bars, dialogs, and so forth. Apps that choose to make use of these components inherit the look&feel of that mobile OS, and these native UI components usually provide a very smooth user experience. It’s important to note, though, that each mobile OS comes with its own unique palette of UI components. Which means that if you want an app that works across multiple operating systems, the designer of the application must be familiar with the UI components provided by each OS in order to design an app that works well for the user. But let’s take a step back, and focus on one specific built-in native app: the browser. GUI Toolkit Browser API

Mobile Web Apps and Mobile Browsing
Downloaded Apps Built-in Apps Apps APIs API Calls API Calls Today’s mobile devices come with very powerful browsers with support for many HTML5 capabilities, CSS3 and advanced JavaScript. Here, on this slide, I’ve specifically highlighted the browsers that come bundled with iOS and Android, but the more recent BlackBerry devices also come with a top-notch browser, as do webOS devices and even many Nokia phones. Windows Phone 7 currently lags behind a bit, but Microsoft is working hard to catch up, and have already demonstrated a preview of IE9 running on Windows Phone 7, with support for a lot of HTML5 features. HTML5 and JavaScript have become so powerful, that it is now possible to develop very advanced applications using them - and this actually brings us to our next category: mobile web apps. Let’s take a look at a few examples. High-Level APIs GUI Toolkit Calendar API Contacts, API PushAPI Browser API More… Rendering Engine (e.g., Webkit)

Mobile Browsing and Mobile Web Apps
Google, Wikipedia: Mobile-optimized websites Dremel: Launch using QR-Codes 2B: Web App YouTube: Web App Of course, we’re all familiar with mobile browsing. This is the most trivial use of the browser, and I’m sure you’ve all seen mobile-optimized web sites, such as those operated by google or wikipedia. These web sites recognize when they are being contacted by a smartphone, for example, and serve up HTML pages that have been designed to provide a comfortable “touch experience” on a small screen size. <click> Some companies have created a mobile web site that looks somewhat like a native app. One interesting example of this approach is that of Dremel, the hardware tools manufacturer, which have created a mobile version of their product catalog. <click> What I found especially interesting here, is that in conjunction with the site itself, they created QR codes that allow navigation to a specific product from a printed ad. The user scans the QR code with a QR Reader App using the phone’s camera, and is redirected to the right place within the online catalog. But other companies don’t stop at making the site look like an app. Take Google, for example. A few months ago, they launched a YouTube Web App, which not only looks very similar to their native app, it provides very similar functionality, and it even prompts you to sort of “install” it on your phone by “adding it to your home screen” when you visit the site. <click> As you can see in this iPhone screenshot, the “installation” creates a shortcut which is indistinguishable from those used to launch native apps. When the user taps this shortcut, the YouTube Web App is launched. And here is a small web app, written by an Australian developer, that takes things even further. This is a small touch-based sketchpad written entirely in HTML5 and JavaScript. When you slide your finger on the screen, a pencil appears, and you can draw on the pad – with wavy lines and everything. This is a great demonstration of the power of HTML5. What’s more, this app uses an HTML5 feature that enables it to run when the phone is in “offline mode” – and not connected to a web server at all - and it even saves your drawing locally on the mobile device. Another nice thing about this app is that on iPhone, it uses a feature of the browser that lets installed web apps remove the browser chrome in portrait mode, so that users can’t really tell that it is running in the browser.

Mobile Browsing vs. Mobile Web Apps
So these four examples of browser-based pages can really help us understand the wide spectrum of offerings available on the mobile web. <click> On one extreme we have what I like to call “Pure Mobile Web Apps” – which are written entirely in HTML, CSS and JavaScript, and served from a web server, but are almost indistinguishable to the user from native apps. <click> They are “installed” on the homepage and launched like native apps, <click> they have an interactive user interface, <click> which is highly optimized for touch screens <click>, and while data is retrieved from servers using AJAX, the logic for rendering the user interface resides entirely on the mobile device, which means that it can be very responsive and doesn’t require long waits for a response from the web server <click>. And because the server doesn’t render the UI, the app can have an offline mode, allowing it to function without network connectivity. <click> On the other extreme we have what we might call “Pure Mobile Web Sites”. <click> The user visits them by typing a URL into the browser, <click> they have a navigational UI – which means that visitors mostly navigate between pages that display static data. <click> The pages have a generic look & feel, so they really look like web pages, <click> and the logic for rendering these pages is executed on the server (for example, using PHP, JSP or Python), which means that the user usually waits for pages to be retrieved from the network, <click> and which also means that any interactive functionality requires network connectivity and doesn’t really work when the phone is in offline mode. <click> Along those two extremes, we have a very wide range of possibilities, with most web sites making use of their own mix of app features, in a way that puts them somewhere in between pure mobile web apps and pure mobile web sites. … Gray Area … Pure Mobile Web Sites Pure Mobile Web Apps Visited by browsing Static, navigational UI Generic look & feel Server-side rendering Require connectivity Installed and launched Interactive UI Touch optimized Client-side rendering Available offline

JavaScript Toolkits for Mobile Web App UI
SenchaTouch Example: Crossword Puzzles for iPad jQuery Mobile: Boston Event App So as you can see, mobile web apps are a very promising trend. And to help developers create the client-side user interface of such mobile web apps, there’s a growing number of JavaScript toolkits that do just that. At the current point in time, I think the two most interesting libraries are Sencha Touch and jQuery Mobile. Without getting into the specifics of each toolkit, we can see from the screenshots on this slide that both of them generate user interfaces that are very reminiscent of the look & feel of native apps. Both execute entirely within the browser on the mobile device, and make use of the newest JavaScript, CSS and HTML5 features available in browsers.

HTML5 and related technologies
Static Pages Dynamic Pages Web Applications w3c.org whatwg.org Main HTML5/CSS3 features on mobile Bitmapped and vector graphics, including animations Offline support and data URLs Geolocation Video and Audio Continuous communications with the server More… I’ve been mentioning HTML5 a lot over the past few minutes, and I’d like to take a moment to explain what that actually means. HTML5 is the current target of the HTML standardization process. In many ways, HTML5 signals the transition of HTML from a “page definition language” into a powerful technology for creating browser-based apps. [In fact, many parts of HTML5 will just be a “snapshot” of an ongoing effort driven forward by employees of Apple, Google, Mozilla and Opera (who are operating an organization called the WHATWG), whose aim is to keep evolving HTML in this manner.] It’s a work in progress, but a very large portion of the features that are part of HTML5, is already available in mobile browsers. Here are a few examples of HTML5 features – already available on most mobile browsers, or will be available soon: <click> For starters, HTML5 provides many client-side graphics capabilities, with the Canvas element, SVG, and things like rounded corners in CSS3. <click>HTML5 has several mechanisms that enable offline support, such as application caching and offline storage. Data URLs also make it easier for apps to perform client-side rendering without contacting the server. <click>HTML5 has already defined APIs for accessing location data, and there is work on defining new APIs for device orientation, as well as other device access APIs. <click>Video and audio can now work without special plugins. <click>And client-side apps now have more powerful tools for communicating with the servers without continuous polling. <click>There are also new HTML tags and attributes, and many other interesting features. The HTML standard is constantly evolving, and the leading mobile browser manufacturers are diligently adding new features with every update to the mobile OSs. It’s these features that make it possible to develop powerful apps that run inside the browser, rather than simple dynamic pages in which most of the content is rendered by a web server.

Characteristics of Mobile Web Apps
Entirely written using web technologies HTML, CSS and JavaScript Code is executed by the browser, not by the OS Various launch mechanisms Typing URL, clicking hyperlink, scanning QR Code or clicking home-screen shortcut Installation is optional Combine cross-platform HTML5 and device-specific features optimize apps Touch-optimized look & feel No address bar Suggestion to pin to home screen Offline availability So let’s recap: <click> Web apps are entirely written in HTML, CSS and JavaScript <click> Their code is executed by the browser There are several ways to launch them And their installation is optional They can easily support multiple mobile OSs, and can be extended with device-specific enhancements, to make them behave more like native apps. So if web apps can do so much, who needs native? Well, web apps are very promising, and there are some great things that can be done with them today, and they will quickly become an even more powerful approach as HTML continues to rapidly evolve, but there are still some important limitations. To understand them, let’s take a look at how web apps interface with the mobile device.

Native App – Interaction with Mobile Device
Mobile Operating System Touch Screen, Keyboard Graphics Touch Events Data WiFi Wide Range of Services Calls, Data GSM Network Audio Microphone So you remember this slide, right? Here we saw how a native app interacts with the mobile OS. Native App Speaker API Calls Audio OS-Specific APIs Images, Video Camera Vibration Activation Orientation Accelerometer, Compass Location GPS Data Storage

Web App – Interaction with Mobile Device
Browser Mobile Operating System Touch Screen, Keyboard Graphics Touch Events Web App (HTML, CSS, JS) Data WiFi Wide Range of Services Calls, Data GSM Network Audio Microphone Web apps work differently. Unlike native apps, which are independent executables that interface directly with the OS, web apps run within the browser. The browser is itself a native app, and it has direct access to the OS APIs, but it only exposes some of them to the web apps that run inside it. So while native apps have full access to the device, there are many features that web apps can only access in a limited fashion, and even others that web apps cannot access at all. For example, a web app cannot access the camera or microphone, or the calendar and address book. This will change in the future, because HTML is evolving, and there is specific work being done to allow such things as access to the camera, but we’re not there yet. One specific element of the browser that I wanted to highlight is the Rendering Engine. This is the heart of the browser. It’s the part that translates the HTML, CSS and JavaScript into a real live user interface. Today, all the leading smartphone vendors are using the same rendering engine in their devices. This rendering engine is called WebKit, and it’s an open source project led mostly by Apple and Google – and it has the largest amount of HTML5 features implemented already. So while each vendor makes their own changes to WebKit, the browsers have a nice level of compatibility between them. There are of course differences, and extensions, and each version of each OS has a slightly different browser, but the differences are not huge. Some operating systems, like Windows Phone 7, use a different rendering engine, but as I mentioned earlier, they are also working fast to catch up in implementing HTML5 features – so we can probably expect HTML5 to be the most widely supported cross-platform technology for mobile. Speaker Audio OS-Specific APIs W3C Calls Images, Video Camera Vibration Activation Rendering Engine Orientation Accelerometer, Compass API Calls Location GPS Data Storage

Native vs. Web Native Web Device Access Speed Development Cost
App Store Approval Process Native Full Very Fast Expensive Available Mandatory So now that we understand both native and web apps, let’s compare the two. <click> Native apps have a significant advantage in that they offer full access to all the features of the device and get a native look & fell, while web apps are more limited in what they can do, and the native look & feel can be achieved only in part on many phones. <click> Furthermore, even though mobile web apps can be quite fast, native apps run faster. It’s important to mention two things about this point: 1. Execution speed depends on the specific mobile operating system, and on the hardware capabilities of the mobile device. 2. Looking forward, we anticipate browser performance to continue to improve. OS vendors are constantly improving them, and adding things like JavaScript optimization and hardware acceleration (including even 3D graphics). But still – if you need powerful computation, or a super-responsive game-like user interface, you’ll prefer native. <click> The most obvious downside of native app development is cost, because there’s a significant penalty for each supported mobile OS, and this is not only for initial development, but also for ongoing maintenance. <click> On the other hand, native apps are available on the major app stores, whereas mobile web apps are only available on smaller, lesser known app stores. <click> The downside of app store presence, is the painful approval process which you have to go through when you submit the app, and every time you release an update. So which should you choose? That depends on your specific needs. Some of our customers go with native – at least for one operating system, whereas others prefer web, and some do both. Web Partial Fast Reasonable Not None

Introducing Hybrid Apps
Device Access Speed Development Cost App Store Approval Process Native Full Very Fast Expensive Available Mandatory But most of our customers choose a more flexible solution, which is to create an app that combines both native and web elements – or in other words, a hybrid app. Let’s examine this approach. Hybrid Web Partial Fast Reasonable Not None Web Partial Fast Reasonable Not None

Characteristics of Hybrid Apps
A Hybrid App is a native app with embedded HTML It has all the benefits of native apps: full access to APIs, app-store presence, etc. Selected portions of the app are written using web technologies The web portions of the app can either be downloaded from the web or packaged within the app <click and read aloud>

Hybrid App – Interaction with Mobile Device
Mobile Operating System Touch Screen, Keyboard Graphics Touch Events Web Portion of App Web Portion of App Data WiFi Wide Range of Services HTML, CSS, JS Calls, Data GSM Network HTML API calls Audio Microphone So let’s go back to our familiar diagram, and examine how hybrid apps operate. As you can see on the left, hybrid apps have 2 separate components: First of all there’s the native portion of the app. <click> This part can call all the APIs provided by the operating system. <click> This means it has free access to everything the device offers – including things like the camera, microphone and even the high level services, like the calendar or address book. The second component is the Web Portion of the app <click> This part is written in HTML, CSS and JavaScript, which are executed by the same rendering engine that is at the heart of the browser that comes with the device. By default, this web code can only access the services that the rendering engine exposes. <click> So theoretically, you might think it has the same limitations as web apps do. However, the native portion of the app has control over the rendering engine. And as such, it can create what you might call “a bridge” <click> that allows the web portions of the app to access all of the OS APIs. The developers of the app can create their own bridge, or they can use a ready-made one. The most popular such bridge today <click> is an open source library called PhoneGap, which, BTW, we include as part of our platform. PhoneGap comes with both native and javascript endpoints and provides a javascript interface to selected device capabilities, which is consistent across operating systems. Speaker Audio OS-Specific APIs API Calls API Calls Images, Video Rendering Engine Camera Vibration Activation API PhoneGap Orientation Accelerometer, Compass Native Portion of App API Calls API Calls Location GPS Data Storage

Hybrid App Examples Bank of America Facebook Morgan Stanley
Lotte Card (Korea) Morgan Stanley There are many hybrid apps out there. For example, <click> Bank of America’s mobile app is a hybrid one. <click> Morgan Stanley have a hybrid app, <click> some of the pages in the official Facebook app are in HTML, and there are many other examples. One specific example I’d like to highlight, and not only because it was created on our platform, is the Lotte Card app <click> that was developed by finance-all-solutions of Korea. This app has a very large number of screens – I only included 3 of them here, but they can help us understand a few points about hybrid apps: First of all, you might not notice it by looking at them, but the two screens on the left were written entirely in HTML5. The screen on the right, is an augmented reality feature, which overlays icons on top of a real-time video image from the camera - this is pure native code. The app lets the user switch between the screens, and the user doesn’t notice that one screen was implemented in HTML and the other is native. Another interesting point, is that this app is available for both Android and iPhone. Most of the HTML, CSS, and JavaScript code is shared between the two implementations, and only the native portions (such as for the augmented reality) had to be implemented separately for each OS. And even though this app has a very large amount of screens, it was implemented extremely quickly, due to the ability to leverage the HTML expertise of the developers.

Hybrid App Development
Native Sources HTML Sources Server Application Source Code Software Source Code Resources (e.g. images) So how do you create a hybrid app? Remember that a hybrid app is first of all a native app. So we first have to create that. <click>. The native app should be coded in a way that launches the HTML rendering engine where appropriate. And now that we have a native app, there are actually 2 primary ways we can get the HTML, CSS and JS files into that app. The first way, is the more “conventional” way – this is what most people refer to when they say “hybrid app”. <click> What we do here is we take the HTML sources, put them on a web server, and have the app instruct the rendering engine to browse to that web server. This approach has a slight drawback, because it introduces a delay. The HTML pages are not displayed until they are downloaded from the server. On the other hand, it means that the HTML portions of the app can have minor updates made to them, without requiring the app to be submitted again to the app store. The other way <click> is to package the HTML sources within the distributable package of the app. By the way, some mobile OS vendors offer development tools that by default create hybrid apps, for example BlackBerry’s new Web Works, and these tools use this means of packaging. So if the web resources are packaged within the app, it means that there’s no delay for the user, because the HTML and other files are retrieved directly from the file system of the device. On the other hand, it means that remote updates are not possible. But of course, if we want both advantages, <click> we can always combine – package the HTML sources within the app, but also have them on a server that lets us send updates to users quickly. SDK Tools Compiler, Linker Executable (Binary) Packager Distributable Package App Stores

App Development Comparison
Device Access Speed Development Cost App Store Approval Process Native Full Very Fast Expensive Available Mandatory So to summarize, let’s look at all 3 development approaches compared to each other. Native excels in performance and device access, but suffers in cost and updates. Web is much simpler, less expensive, easier to update, but is currently more limited. Hybrid provides a middle ground, which in many situations is the best of both worlds – especially if you’re targeting multiple operating systems. Which should you choose? That really depends on your specific needs. There isn’t a single approach that works for everyone. So to provide you with a few more tips that will help you decide, I’d like to transfer the microphone over to Jonathan - who will examine the approaches from a business perspective, and discuss how they fit into the bigger picture of defining the mobile strategy of your organization. Hybrid Full Native Speed as Necessary Reasonable Available Low Overhead Web Partial Fast Reasonable Not Available None

No Single Approach Is Right For Everyone
Target Audience App Function Thank you Ron for this detailed overview. The important thing to understand here is that there is no single development approach that will fit all needs of all companies. Different organizations have different requirements such as application functionality, target audience, IT resources and of course limited time and budget. <Click> Time and Budget IT Resources

Cost and Time-to-Market
An Inherent Tradeoff Native App User Experience Cost and Time-to-Market Hybrid App But in this web of uncertainty, one thing is clear; companies today face an obvious tradeoff between user experience and application functionality on one hand and development costs and time to market on the other. The challenge becomes choosing the right development approach that will balance your requirements with your budget and time-to-market constraints. <Click> Web App Mobile Web Site

Choosing What’s Right For You
Existing in-house native skills Targeting a single mobile OS Dominant native functionality Rich UI requirements Native Direct distribution to the hands of users Pilot application Out-of-store visibility via search engines Web Breaking the development tradeoff Existing in-house web development skills Taking the future into consideration Hybrid I’ve gathered a list of scenarios to help guide you as you decide on the approach that is right for your company. <Click> Let’s start with the native approach. If your organization or the use case you plan for the application fits into these criteria, then the native development approach is right for you: Existing native skills – One of the main arguments against the native approach is the need to hire new employees or train your developers in a variety of native languages. If your organization has these native skills in-house then putting them to work will does not significant new investments. A single mobile OS – If your organization is aiming to release a mobile application to a limited target audience – one that is known to use a single mobile OS, e.g. an internal app in an organization that standardized the BlackBerry Torch – then having the multiplatform coverage is not a priority for your organization and the native approach can make sense. Native functionality – Some applications are built around a single functionality. Take Skype for example, VOIP and access to the user’s contacts are key elements of the app and are only possible to develop natively. For such applications, web technologies are simply not yet sufficiently evolved and are far from capable of achieving the desired functionality. Rich UI – For game-like applications that require a rich and responsive user interface, web technologies add a layer of complexity – the result of the translation of the code to the binary language of the OS. This added complexity can hinder the responsiveness of the app and result in poor user experience. Let’s move on. <Click> The following scenarios are best supported by web applications: Direct Distribution – Some organizations prefer distributing their apps in a manner that is controlled internally, and is not subject to what can sometimes result in a long and uncertain approval processes. In such cases, using purely web languages can completely circumvent the app store process and allow the organization to fully control the distribution of the app and its ongoing updates. Pilot App – When comparing the price and time to market of a native app vs. a web app, using web technologies to create a pilot version of the app can be a very compelling and cost-effective tactic. Visibility – Further to the distribution we already discussed, another benefit of creating a web application is its visibility in search engine results which, in many cases, can gain significantly more eyeballs. <Click> As for the hybrid approach: Breaking the tradeoff – Using the hybrid approach, companies can enjoy the best of both worlds. On one hand, the native container, or the ability to implement native code, allows developers to take full advantage of all the different features and capabilities of modern mobile devices. On the other, all the portions of the code that are written using web languages can be shared among the different environments, making the development and ongoing maintenance process centralized, shorter and cost-effective. In-house skills – Web development skills are very common and can easily be found in many organizations. By choosing the hybrid approach, web developers are able to build applications with nothing but HTML knowledge, while delivering a native user experience. Considering the future – HTML5 is rapidly growing in both availability and capabilities. I’m sure you would all agree with me, and with many analysts, when I say that HTML is very likely to become the default technology for front-end application development. By writing most of the app in HTML, and using native only where needed, companies can make sure that investments they make today do not become obsolete tomorrow, as HTML functionality becomes richer and addresses more and more of the mobile app requirements. Speaking of future advancements in the market, I would like to spend a few minutes exploring these projections. <Click>

Future Trends Future device fragmentation
Accelerated enterprise adoption New features and complementing technologies New distribution channels So, here is a short list of what I believe we will be witnessing in the mobile market in the very near future: Further fragmentation of mobile devices and technologies, which in turn, will continue to increase the overall costs that are associated with mobile application development, integration and ongoing management Accelerated mobile adoption by consumers and within the enterprise of mission critical applications, increasing the requirements around security, scalability and ongoing control New device features and complementing technologies such as near-field communications, geo-location, augmented reality, social networks, and others which will undoubtedly give rise to new types and new use cases of mobile apps, be it in finance, e-commerce, healthcare, travel, communication or any other industry for that matter And new distribution channels for the apps, both public and private, allowing organizations to easily place the apps in the hands of the user, quickly deploy updates and manage its entire portfolio of apps without going through a long submission and approval process. <Click>

Mobile is Strategic. Not Tactical.
Flexible Development Secure and Scalable Integration Ongoing Monitoring and Control One conclusion is obvious from this list: the choice between hybrid, native and web is a major one, but not the only one. Companies that are just forming their mobile strategy must also consider the future trends that we just mentioned, and choose a comprehensive solution, one that will not only support the development of their first mobile application, but would also: Be flexible enough to support the development of all future apps, regardless of their development approach One that would support the secure and scalable integration of the apps into their ever-evolving IT infrastructure and back-end systems, and also Allow them to monitor and control their entire portfolio of applications from one centralized interface. That’s it from me. Thank you for listening.

For More Information Resource Location www.worklight.com
Industry Whitepapers Technology Reports Expert Webinars dev.worklight.com Developer Zone Self-Guided Tutorials Technical Resources Thank you Jonathan and Ron. Very thorough overview of the different technology and business considerations for mobile app enterprise initiatives. And now let’s turn to the questions you’ve submitted, as we will try to address all within the remaining time. …

Native, Web or Hybrid Mobile App Development?

Similar presentations

Presentation on theme: "Native, Web or Hybrid Mobile App Development?"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Native, Web or Hybrid Mobile App Development?

Similar presentations

Presentation on theme: "Native, Web or Hybrid Mobile App Development?"— Presentation transcript:

Similar presentations

About project

Feedback