[[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>
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.
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>
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?
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
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.
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.
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.
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.
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.
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.
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.
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.
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 email. 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.
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.
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.
So you remember this slide, right? Here we saw how a native app interacts with the mobile OS.
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.
<click and read aloud>
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.
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.
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>
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>
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>
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>
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.
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?
Native, Web or Hybrid MobileApp Development?WorkLight Webinar Series
AgendaIntroductionUnderstanding the different approaches• Native apps• Web apps and HTML5• Hybrid appsThe business contextQ&A2
Introduction3Native AppsNative Apps Web AppsWeb Apps Hybrid AppsHybrid Apps101101101011011110110110110110110110110110101101101011011011011011011011011011101011101111110110110110101101000001101011101101101011011110110110110110110110110110101101101011011011011011011011011011101011101111110110110110101101000001101011<!DOCTYPE html PUBLIC<html><! - - created 2003-12-12 - - ><head><title>XYZ</title></head><body><p>Voluptatem accusantium doTotam rem aperiam eaque</p></body></html><!DOCTYPE html PUBLIC<html><! - - created 2003-12-12 - - ><head><title>XYZ</title></head><body><p>Voluptatem accusantium doTotam rem aperiam eaque</p></body></html>
Characteristics of a Purely-Native Mobile AppA binary “executable image”, that is explicitly downloadedand stored on the file system of the mobile deviceDistributed through the popular app store or marketplace ofthe device, or via an enterprise distribution mechanismExecuted directly by the operating system• Launched from the home screen• Does not require another “container app” to run itMakes explicit use of operating-system APIs5
Native App Development Summary11Languages Obj-C, C, C++Java(Some C, C++)Java C#, VB.NET, etcTools Xcode Android SDKBB Java EclipsePlug-InVisual Studio,Windows PhoneDev ToolsExecutable Files .app .apk .cod .xapApplication Stores Apple iTunes Android MarketBlackBerry AppWorldWindows PhoneMarketSimilar approach, but different source code and expertiseresults in expensive development and maintenance
Characteristics of a Purely-Native Mobile AppA binary “executable image”, that is explicitly downloadedand stored on the file system of the mobile device.Distributed through the popular app store or marketplace ofthe 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 APIs12
Native App – Interaction with Mobile Device13Touch Screen,KeyboardTouch Screen,KeyboardGraphicsTouch EventsGPSGPSLocationMicrophoneMicrophoneAudioSpeakerSpeakerGSM NetworkGSM NetworkCalls, DataVibrationVibrationActivationAccelerometer,CompassAccelerometer,CompassOrientationCameraCameraWiFiWiFiDataImages, VideoStorageStorageMobile OperatingSystemMobile OperatingSystemDataNativeAppNativeAppOS-SpecificAPIsWide Range ofServicesAudioAPI Calls
GUI Toolkit Provides App With “Native” Look15GUIToolkitAppsAPIsBrowserAPIBuilt-in AppsDownloaded Apps
Mobile Web Apps and Mobile Browsing16High-LevelAPIsGUIToolkitCalendarAPIPushAPIContacts,Email APIBrowserAPIMore…AppsAPIsRendering Engine(e.g., Webkit)Built-in AppsDownloaded AppsAPI CallsAPICalls
Mobile Browsing and Mobile Web Apps17Google, Wikipedia:Mobile-optimizedwebsitesDremel:Launch usingQR-Codes2B: Web AppYouTube: Web App
Mobile Browsing vs. Mobile Web Apps18Pure Mobile Web Sites• Visited by browsing• Static, navigational UI• Generic look & feel• Server-side rendering• Require connectivityPure Mobile Web Apps• Installed and launched• Interactive UI• Touch optimized• Client-side rendering• Available offline
HTML5 and related technologies20Static Pages Dynamic Pages Web Applicationsw3c.orgwhatwg.orgMain 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…
Native App – Interaction with Mobile DeviceTouch Screen,KeyboardTouch Screen,KeyboardGraphicsTouch EventsGPSGPSLocationMicrophoneMicrophoneAudioSpeakerSpeakerGSM NetworkGSM NetworkCalls, DataVibrationVibrationActivationAccelerometer,CompassAccelerometer,CompassOrientationCameraCameraWiFiWiFiDataImages, VideoStorageStorageMobile OperatingSystemMobile OperatingSystemDataNativeAppNativeAppOS-SpecificAPIsWide Range ofServicesAudioAPI Calls22
Web App – Interaction with Mobile DeviceBrowserBrowserTouch Screen,KeyboardTouch Screen,KeyboardGPSGPSMicrophoneMicrophoneSpeakerSpeakerGSM NetworkGSM NetworkVibrationVibrationAccelerometer,CompassAccelerometer,CompassCameraCameraWiFiWiFiStorageStorageMobile OperatingSystemMobile OperatingSystemOS-SpecificAPIsWide Range ofServicesWebApp(HTML, CSS, JS)WebApp(HTML, CSS, JS)RenderingEngineRenderingEngineAPI CallsGraphicsTouch EventsLocationAudioCalls, DataActivationOrientationDataImages, VideoDataAudio23
Native vs. Web24NativeDeviceAccessSpeed App StoreDevelopmentCostApprovalProcessFull Very Fast AvailableExpensive MandatoryPartial Fast NotReasonable NoneWeb
HybridIntroducing Hybrid Apps25NativeDeviceAccessSpeed App Store ApprovalProcessFull Very Fast Available MandatoryPartial Fast Not NoneWebDevelopmentCostExpensiveReasonablePartial Fast NotReasonable NoneWeb
Characteristics of Hybrid AppsA Hybrid App is a native app with embedded HTMLIt has all the benefits of native apps: full access to APIs, app-store presence, etc.Selected portions of the app are written using webtechnologiesThe web portions of the app can either be downloaded fromthe web or packaged within the app26
FullNativeSpeed asNecessaryReasonable AvailableLowOverheadHybridApp Development Comparison30NativeDeviceAccessSpeed App Store ApprovalProcessFull Very Fast Available MandatoryDevelopmentCostExpensivePartial Fast NotAvailableReasonable NoneWeb
No Single Approach Is Right For Everyone31Target AudienceTarget Audience App FunctionApp FunctionTime and BudgetTime and Budget IT ResourcesIT Resources
An Inherent Tradeoff32NativeAppUserExperienceCost and Time-to-MarketHybridAppWeb AppMobileWeb Site
Choosing What’s Right For You33• Existing in-housenative skills• Targeting a singlemobile OS• Dominant nativefunctionality• Rich UI requirementsNative• Direct distribution tothe hands of users• Pilot application• Out-of-store visibilityvia search enginesWeb• Breaking thedevelopment tradeoff• Existing in-house webdevelopment skills• Taking the future intoconsiderationHybrid
Future TrendsFuture device fragmentationAccelerated enterprise adoptionNew features and complementing technologiesNew distribution channels34
Mobile is Strategic. Not Tactical.Flexible DevelopmentSecure and Scalable IntegrationOngoing Monitoring and Control35
For More Information36Contact me at http://ibm.co/RvM7pY