Native, Web or Hybrid Mobile App Development?
â˘
19 gefällt mirâ˘7,146 views
The document discusses different approaches to developing mobile apps, including native apps, web apps, and hybrid apps. Native apps are developed specifically for a single platform using that platform's tools and programming languages. They have full access to device features but have high development and maintenance costs. Web apps are developed with web technologies like HTML, CSS, and JavaScript and run in a mobile browser, allowing cross-platform use but more limited access to device features. Hybrid apps combine native and web technologies by wrapping web views in a native container, giving them full device access and lower costs than native apps. The document explores the characteristics and tradeoffs of each approach.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ăhnlich wie Native, Web or Hybrid Mobile App Development?
Ăhnlich wie Native, Web or Hybrid Mobile App Development? (20)
Mehr von Sura Gonzalez
KĂźrzlich hochgeladen
KĂźrzlich hochgeladen (20)
Native, Web or Hybrid Mobile App Development?
- 1. Native, Web or Hybrid Mobile App Development? WorkLight Webinar Series
- 2. Agenda Introduction Understanding the different approaches ⢠Native apps ⢠Web apps and HTML5 ⢠Hybrid apps The business context Q&A 2
- 3. Introduction 3 Native AppsNative Apps Web AppsWeb Apps Hybrid AppsHybrid Apps 101101101011011 110110110110110 110110110110101 101101011011011 011011011011011 011101011101111 110110110110101 101000001101011 101101101011011 110110110110110 110110110110101 101101011011011 011011011011011 011101011101111 110110110110101 101000001101011 <!DOCTYPE html PUBLIC <html> <! - - created 2003-12-12 - - > <head><title>XYZ</title> </head> <body> <p> Voluptatem accusantium do Totam rem aperiam eaque </p> </body> </html> <!DOCTYPE html PUBLIC <html> <! - - created 2003-12-12 - - > <head><title>XYZ</title> </head> <body> <p> Voluptatem accusantium do Totam rem aperiam eaque </p> </body> </html>
- 4. Examples of Purely-Native Mobile Apps 4
- 5. 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 5
- 6. Native App Development 6 SDK Tools Application Source CodeApplication Source Code Resources (e.g. images) Resources (e.g. images) Software Source Code Software Source Code Compiler, LinkerCompiler, Linker Executable (Binary) Executable (Binary) PackagerPackager Distributable Package Distributable Package App Stores
- 7. iOS â Native App Development 7 SDK Tools Application Source CodeApplication Source Code Resources (e.g. images) Resources (e.g. images) Software Source Code Software Source Code Executable (Binary) Executable (Binary) PackagerPackager Distributable Package Distributable Package App Stores XcodeXcode Objective-C, C++, C Objective-C, C++, C .app.app Compiler, LinkerCompiler, Linker
- 8. Android â Native App Development 8 SDK Tools Application Source CodeApplication Source Code Resources (e.g. images) Resources (e.g. images) Software Source Code Software Source Code Executable (Binary) Executable (Binary) PackagerPackager Distributable Package Distributable Package App Stores Java (some C, C++) Java (some C, C++) .apk.apk Android SDKAndroid SDK Compiler, LinkerCompiler, Linker
- 9. BlackBerry â Native App Development 9 SDK Tools Application Source CodeApplication Source Code Resources (e.g. images) Resources (e.g. images) Software Source Code Software Source Code Executable (Binary) Executable (Binary) PackagerPackager Distributable Package Distributable Package App Stores BlackBerry Java Plug-in for Eclipse BlackBerry Java Plug-in for Eclipse JavaJava .cod.cod Compiler, LinkerCompiler, Linker
- 10. Windows Phone â Native App Development 10 SDK Tools Application Source CodeApplication Source Code Resources (e.g. images) Resources (e.g. images) Software Source Code Software Source Code Executable (Binary) Executable (Binary) PackagerPackager Distributable Package Distributable Package App Stores Visual Studio, Windows Phone Developer Tools Visual Studio, Windows Phone Developer Tools C#, VB.NET, etc. C#, VB.NET, etc. .xap.xap Compiler, LinkerCompiler, Linker (Sliverlight)
- 11. Native App Development Summary 11 Languages Obj-C, C, C++ Java (Some C, C++) Java 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 Similar approach, but different source code and expertise results in expensive development and maintenance
- 12. 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 12
- 13. Native App â Interaction with Mobile Device 13 Touch Screen, Keyboard Touch Screen, Keyboard Graphics Touch Events GPSGPSLocation MicrophoneMicrophoneAudio SpeakerSpeaker GSM NetworkGSM NetworkCalls, Data VibrationVibrationActivation Accelerometer, Compass Accelerometer, Compass Orientation CameraCamera WiFiWiFiData Images, Video StorageStorage Mobile Operating System Mobile Operating System Data Native App Native App OS-SpecificAPIs Wide Range of Services Audio API Calls
- 14. Native App â High-level APIs and Built-in Apps 14 File System Network Graphics Camera Low-Level APIs Multi- tasking More High-Level APIs GUI Toolkit Calendar API Push API Contacts, Email API Browser API More Audio Built-in Apps Downloaded Apps Apps APIs
- 15. GUI Toolkit Provides App With âNativeâ Look 15 GUI Toolkit Apps APIs Browser API Built-in Apps Downloaded Apps
- 16. Mobile Web Apps and Mobile Browsing 16 High-Level APIs GUI Toolkit Calendar API Push API Contacts, Email API Browser API More⌠Apps APIs Rendering Engine (e.g., Webkit) Built-in Apps Downloaded Apps API Calls APICalls
- 17. Mobile Browsing and Mobile Web Apps 17 Google, Wikipedia: Mobile-optimized websites Dremel: Launch using QR-Codes 2B: Web App YouTube: Web App
- 18. Mobile Browsing vs. Mobile Web Apps 18 Pure Mobile Web Sites ⢠Visited by browsing ⢠Static, navigational UI ⢠Generic look & feel ⢠Server-side rendering ⢠Require connectivity Pure Mobile Web Apps ⢠Installed and launched ⢠Interactive UI ⢠Touch optimized ⢠Client-side rendering ⢠Available offline
- 19. JavaScript Toolkits for Mobile Web App UI 19 SenchaTouch Example: Crossword Puzzles for iPad jQuery Mobile: Boston Event App
- 20. HTML5 and related technologies 20 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âŚ
- 21. 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 21
- 22. Native App â Interaction with Mobile Device Touch Screen, Keyboard Touch Screen, Keyboard Graphics Touch Events GPSGPSLocation MicrophoneMicrophoneAudio SpeakerSpeaker GSM NetworkGSM NetworkCalls, Data VibrationVibrationActivation Accelerometer, Compass Accelerometer, Compass Orientation CameraCamera WiFiWiFiData Images, Video StorageStorage Mobile Operating System Mobile Operating System Data Native App Native App OS-SpecificAPIs Wide Range of Services Audio API Calls 22
- 23. Web App â Interaction with Mobile Device BrowserBrowser Touch Screen, Keyboard Touch Screen, Keyboard GPSGPS MicrophoneMicrophone SpeakerSpeaker GSM NetworkGSM Network VibrationVibration Accelerometer, Compass Accelerometer, Compass CameraCamera WiFiWiFi StorageStorage Mobile Operating System Mobile Operating System OS-SpecificAPIs Wide Range of Services Web App (HTML, CSS, JS) Web App (HTML, CSS, JS) Rendering Engine Rendering Engine API Calls Graphics Touch Events Location Audio Calls, Data Activation Orientation Data Images, Video Data Audio 23
- 24. Native vs. Web 24 Native Device Access Speed App StoreDevelopment Cost Approval Process Full Very Fast AvailableExpensive Mandatory Partial Fast NotReasonable NoneWeb
- 25. Hybrid Introducing Hybrid Apps 25 Native Device Access Speed App Store Approval Process Full Very Fast Available Mandatory Partial Fast Not NoneWeb Development Cost Expensive Reasonable Partial Fast NotReasonable NoneWeb
- 26. 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 26
- 27. Hybrid App â Interaction with Mobile Device 27 Hybrid AppHybrid App Web Portion of App Web Portion of App Native Portion of App Touch Screen, Keyboard Touch Screen, Keyboard Graphics Touch Events GPSGPSLocation MicrophoneMicrophoneAudio SpeakerSpeaker GSM NetworkGSM NetworkCalls, Data VibrationVibrationActivation Accelerometer, Compass Accelerometer, Compass Orientation CameraCamera WiFiWiFiData Images, Video StorageStorageData Audio Web Portion of App HTML, CSS, JS Rendering EngineRendering Engine Mobile Operating System Mobile Operating System OS-SpecificAPIs Wide Range of Services API Calls API Calls PhoneGapPhoneGap API Calls API Calls
- 28. Hybrid App Examples 28 Bank of America Morgan Stanley Lotte Card (Korea) Facebook
- 29. Hybrid App Development 29 SDK Tools Application Source CodeApplication Source Code Resources (e.g. images) Resources (e.g. images) Software Source Code Software Source Code Compiler, LinkerCompiler, Linker Executable (Binary) Executable (Binary) PackagerPackager Distributable Package Distributable Package App Stores Native SourcesNative Sources HTML SourcesHTML Sources Server
- 30. Full Native Speed as Necessary Reasonable Available Low Overhead Hybrid App Development Comparison 30 Native Device Access Speed App Store Approval Process Full Very Fast Available Mandatory Development Cost Expensive Partial Fast Not Available Reasonable NoneWeb
- 31. No Single Approach Is Right For Everyone 31 Target AudienceTarget Audience App FunctionApp Function Time and BudgetTime and Budget IT ResourcesIT Resources
- 32. An Inherent Tradeoff 32 Native App UserExperience Cost and Time-to-Market Hybrid App Web App Mobile Web Site
- 33. Choosing Whatâs Right For You 33 ⢠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
- 34. Future Trends Future device fragmentation Accelerated enterprise adoption New features and complementing technologies New distribution channels 34
- 35. Mobile is Strategic. Not Tactical. Flexible Development Secure and Scalable Integration Ongoing Monitoring and Control 35
- 36. For More Information 36 Contact me at http://ibm.co/RvM7pY
Hinweis der Redaktion
- [[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.
- 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.
- 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. <click> 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. <click> 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.
- 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.
- 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.
- 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 letâs recap: <click> Web apps are entirely written in HTML, CSS and JavaScript <click> Their code is executed by the browser <click> There are several ways to launch them <click> And their installation is optional <click> 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.
- So you remember this slide, right? Here we saw how a native app interacts with the mobile OS.
- 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.
- 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.
- 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 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.
- 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.
- 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. âŚ