White paper native, web or hybrid mobile app development

  • Published on

  • View

  • Download

Embed Size (px)


  • 1. IBM SoftwareThought Leadership White PaperWebSphereNative, web or hybridmobile-app development

2. 2 Native, web or hybrid mobile-app developmentContents2 Introduction2 Introducing the approaches2 Native apps3 The application programming interface (API)4 Mobile-web apps6 Hybrid apps7 Comparing the different approaches8 Choosing the right approach8 Scenarios for the native approach9 Scenarios for the web approach9 Scenarios for the hybrid approach10 SummaryIntroductionMany organizations taking their first steps to implement amobile strategy are facing an important decision that willinfluence the results of this initiative. The process of choosinga development approach for a mobile application (hereafterreferred to as an app), namely native, web or hybrid, entailsmany parameters, such as budget, project timeframe, targetaudience and app functionality to name a few. Each approachcarries inherent benefits and limitations, and finding the onethat best addresses the organizations needs could be achallenging task.The purpose of this white paper is not to identify the bestdevelopment approach, as none exists, but rather to list the prosand cons each carries and to describe the different scenarios,or enterprise requirements, that best fit one or the other.Introducing the approachesNative appsNative apps have binary executable files that are downloadeddirectly to the device and stored locally. The installation processcan be initiated by the user or, in some cases, by the IT depart-mentof the organization. The most popular way to download anative app is by visiting an app store, such as Apples App Store,Androids Marketplace or BlackBerrys App World, but othermethods exist and are sometimes provided by the mobile vendor.Once the app has been installed on the device, the user launchesit like any other service the device offers. Upon initialization, thenative app interfaces directly with the mobile operating system,without any intermediary or container. The native app is free toaccess all of the APIs that are made available by the OS vendorand, in many cases, has unique features and functions that aretypical of that specific mobile OS. 3. IBM Software 3To create a native app, developers must write the source code(in human-readable form) and create additional resources, suchas images, audio segments and various OS-specific declarationfiles. Using tools provided by the OS vendor, the source code iscompiled (and sometimes also linked) in order to create anexecutable in binary form that can be packaged along with therest of the resources and made ready for distribution.These tools, in addition to other utilities and files, are normallycalled the software development kit (SDK) of the mobile OS.Although the development process is often similar for differentoperating systems, the SDK is platform-specific and each mobileOS comes with its own unique tools. The following table pres-entsthe different tools, languages, formats and distributionchannels associated with the leading mobile operating systems.These differences across platforms result in one of the mostcritical disadvantages of the native development approachcodewritten for one mobile platform cannot be used on another,making the development and maintenance of native apps formultiple OSs a very long and expensive undertaking.So, why is it that in spite of this costly disadvantage, manycompanies choose to develop natively? To answer that question,we will need to better understand the role of the APIs.The application programming interface (API)Once the native application is installed on the mobile deviceand launched by the user, it interacts with the mobile operatingsystem through proprietary API calls that the operating systemexposes. These can be divided into two groups: low-level APIsand high-level APIs.Apple iOS Android Blackberry OS Windows PhoneLanguages Objective-C, C, C++ Java (some C, C++) Java C#, VB.NET and moreTools Xcode Android SDK BB Java Eclipse Plug-in Visual Studio, Windows Phonedevelopment toolsPackaging format .app .apk .cod .xapApp stores Apple App Store Google Play Blackberry App World Windows Phone Marketplace 4. 4 Native, web or hybrid mobile-app developmentLow-level APIsIt is through these low-level API calls that the app can interactdirectly with the touch screen or keyboard, render graphics, con-nectto networks, process audio received from the microphone,play sounds through the speaker or headphones, or receiveimages and videos from the camera. It can access the GlobalPositioning System (GPS), receive orientation information and,of course, read and write files on the solid-state disk or accessany other hardware element available today or in the future.High-level APIsIn addition to providing the low-level hardware-access serviceswe just mentioned, mobile operating systems also providehigher-level services that are important to the personal mobileexperience. Such services include processes like browsing theweb, managing the calendar, contacts, photo album and, ofcourse, the ability to make phone calls or send and receive textmessages.Although most mobile OSs include a set of built-in applicationsthat can execute these services, a set of exposed high-level APIsis made accessible for native apps as well, allowing them toaccess many of the important services mentioned above. OtherAPIs enable downloadable apps to access various cloud-basedservices that are provided by the OS vendor, such as pushnotifications or in-app purchases.The graphical user interface (GUI) toolkitAnother important set of APIs that the OS provides is the GUItoolkit. Each mobile OS comes with its own set of user interfacecomponents, such as buttons, input fields, sliders, menus, tabbars, dialog boxes and so on. Apps that make use of these com-ponentsinherit the features and functions of that specific mobileOS, which normally results in a very easy and enjoyable userexperience.Its important to note that different mobile platforms carryunique palettes of user interface (UI) components. As a result,apps that are designed to work for multiple operating systemsrequire the designer to be familiar with the different UIcomponents of each OS.Although APIs are OS-specific and add much complexity andcost to the development of multiple native apps, these elementsare the only means of creating rich mobile applications thatmake full use of all the functionality that modern mobile deviceshave to offer.Mobile-web appsModern mobile devices consist of powerful browsers thatsupport many new HTML5 capabilities, Cascading StyleSheets 3 (CSS3) and advanced JavaScript. With recent advance-mentson this front, HTML5 signals the transition of thistechnology from a page-definition language into a powerfuldevelopment standard for rich, browser-based applications. 5. IBM Software 5A few examples of the potential of HTML5 include advancedUI components, access to rich media types, geolocation servicesand offline availability. Using these features and many more thatare under development, developers are able to create advancedapplications, using nothing but web technologies.It is helpful to distinguish between two extreme web-appapproaches. Everyone is familiar with mobile browsing andmobile-optimized websites. These sites recognize when they areaccessed by a smartphone and serve up HTML pages that havebeen designed to provide a comfortable touch experience on asmall screen size. But some companies go even further andenhance the user experience by creating a mobile website thatlooks like a native app and can be launched from a shortcut thatis indistinguishable from that used to launch native apps.There is a wide range of possibilities between these two ex-tremes,with most websites implementing their own mix offeatures. Mobile web apps are a very promising trend. To capital-izeon this trend and help developers build the client-side UI, agrowing number of JavaScript toolkits have been created, such asdojox.mobile, Sencha Touch and jQuery Mobile, which gener-ateuser interfaces that are comparable in appearance to nativeapps. Both execute entirely within the browser of the mobiledevice and make use of the newest JavaScript, CSS and HTML5features that are available in modern mobile browsers.One of the most prominent advantages of a web app is its multi-platformsupport and low cost of development. Most mobilevendors utilize the same rendering engine in their browsers,WebKitan open-source project led mainly by Google andApple that provides the most comprehensive HTML5Feature Pure mobile web apps Pure mobile websitesTools and knowledge Written entirely in HTML, CSS and JavaScript Written entirely in HTML, CSS and JavaScriptExecution Installed shortcut, launched like a native app Reached by navigating to a website by way of aUniform Resource Locator (URL)User experience Touch-friendly, interactive UI Navigational UI between pages displaying static dataPerformance UI logic resides locally, making the app responsiveand accessible offlineAll code executed from a server, resulting innetwork-dependent performance 6. 6 Native, web or hybrid mobile-app developmentimplementation available today. Because the application code iswritten in standard web languages that are compatible withWebKit, a single app delivers a uniform experience for differentdevices and operating systems, making it multiplatform bydefault. However, these advantages are not without a price.Despite the potential and promise of web technologies in themobile space, they still carry significant limitations. To under-standthese limitations we need to explain how web applicationsoperate.Unlike native apps, which are independent executables thatinterface directly with the OS, web apps run within the browser.The browser is in itself a native app that has direct access to theOS APIs, but only a limited number of these APIs are exposedto the web apps that run inside it. While native apps have fullaccess to the device, many features are only partially available toweb apps or not available at all. Although this is expected tochange in the future with advancements in HTML, these capa-bilitiesare not available for todays mobile users.Hybrid appsThe hybrid approach combines native development with webtechnology. Using this approach, developers write significantportions of their application in cross-platform web technologies,while maintaining direct access to native APIs when required.The native portion of the application uses the operating systemAPIs to create an embedded HTML rendering engine thatserves as a bridge between the browser and the device APIs.This bridge enables the hybrid app to take full advantage of allthe features that modern devices have to offer.App developers can choose between coding their own bridge ortaking advantage of ready-made solutions such as PhoneGapopen-source library that provides a uniform JavaScript interfaceto selected device capabilities that is consistent across operatingsystems.The native portion of the app can be developed independently,but some solutions in the market provide this type of a nativecontainer as part of their product, thus empowering the devel-operwith the means to create an advanced application thatutilizes all the device features using nothing but web languages.In some cases, a solution will allow the developer to use anynative knowledge he or she might have to customize the nativecontainer in accordance with the unique needs of theorganization.The web portion of the app can be either a web page that resideson a server or a set of HTML, JavaScript, CSS and media files,packaged into the application code and stored locally on thedevice. Both approaches carry advantages and limitations.HTML code that is hosted on a server enables developers to 7. IBM Software 7introduce minor updates to the app without going through theprocess of submission and approval that some app stores require.Unfortunately, this approach eliminates any offline availability,as the content is not accessible when the device is not connectedto the network. On the other hand, packaging the web code intothe application itself can enhance performance and accessibility,but does not accept remote updates. The best of both worlds canbe achieved by combining the two approaches. Such a system isdesigned to host the HTML resources on a web server for flexi-bility,yet cache them locally on the mobile device forperformance.Comparing the different approachesTo summarize, a comparison of all three developmentapproaches follows.The native approach excels in performance and device access,but suffers in cost and updates. The web approach is muchsimpler, less expensive and easier to update, but is currentlylimited in functionality and cannot achieve the exceptional levelof user experience that can be obtained using native API calls.The hybrid approach provides a middle ground which, in manysituations, is the best of both worlds, especially if the developeris targeting multiple operating systems.As can be inferred from the table above, no single approachdelivers all the benefits all the time. Choosing the right approachdepends on the specific needs of the organization and can bedriven by many parameters, such as budget, timeframe, internalresources, target market, required application functionality,IT infrastructure and many others.One thing is clear: most companies today face an obvious trad-eoffbetween user experience and application functionality onthe one hand, and development costs and time to market on theother. The challenge becomes choosing the right developmentapproach that will balance the organizations requirements withits budget and time-to-market constraints.Native app Web app Hybrid appNative application Mobile browser Native containerWeb codeWeb codeDevice APIs Device APIs 8. 8 Native, web or hybrid mobile-app developmentFeature Native app Hybrid app Web appDevelopment language Native only Native and web or web only Web onlyCode portability and optimization None High HighAccess device-specific features High Medium LowLeverage existing knowledge Low High HighAdvanced graphics High Medium MediumUpgrade flexibility Low(Always by way of app stores)Medium(Usually by way of app stores)HighInstallation experience High(From app store)High(From app store)Medium(By way of mobile browser)Choosing the right approachThe following is a list of scenarios to help guide organizations inthe process of choosing an approach.Scenarios for the native approachExisting native skills. One of the main arguments againstthe native approach is its lack of multiplatform support.Organizations asking to develop an application for multiplemobile platforms need to hire new employees or train in-housedevelopers in a variety of native languages. Organizations thathave such native skills in-house are able to take advantage ofthem, without significant new investments.A single mobile OS. In some cases, an organization will aim torelease a mobile application to a limited target a...