Web, Native And Cross-platform - Three Approaches To Mobile App Development
APPROACHINGMOBILEUnderstanding the Three Waysto Build Mobile Apps
WHY ARE THERE DIFFERENTAPPROACHES?Mobile app development is complex.To build apps that reach all users, developers mustdeal with many different operating systems, SDKs,development tools, screen sizes and form factors,as well as a technology landscape that is still in aconstant state of flux. And if that were not enough,there are also several different ways to build mobileapps that development teams must sort throughbefore beginning any new mobile effort.Choosing how to build a mobile app, though, canhave the most dramatic effect on the eventualcost, time, and success of a mobile project. Thisis second only to determining the scope andfunctionality of the app itself. Failure to matchan application's requirements to the right mobiledevelopment approach all but guarantees wastedtime and effort–often resulting in a less effectiveend result.There are three primary approaches to buildingmobile apps today: Web, Hybrid and Native. Thispaper aims to explain the primary differencesbetween these approaches, and provide a basicframework for choosing the “right” way to buildmodern mobile apps.Mobile software development is still softwaredevelopment. If twenty years of “desktop” softwaredevelopment taught the industry anything, it is thatevery application is unique. Every application hasrequirements that drive the decisions about howit should be built. Some apps require maximumaccess to hardware for rich visual presentation.Some apps require maximum flexibility and theability to quickly deploy changes in response tobusiness needs.A responsible software development strategy isbuilt around a mixture of approaches that allow abusiness to cover all software requirements whileoptimizing the time and cost of delivering an app.Forrester Research shares the same belief in itsstudy, Putting a Price to Your Mobile Strategy,suggesting developers not “get taken in by theallure of technology trends du jour.” The pattern forsuccess is to realize each mobile app has a best-fittechnology determined by mobile app objectivesand available resources.Before mobile development, it was well understoodthere are no silver bullets that solve all softwaredevelopment requirements.A peek inside the software portfolio of anybusiness today will reveal a mix of web-basedapplications, desktop-based applications, andA publication of3A responsible softwaredevelopment strategy is builtaround a mixture of approachesthat allow a business to coverall software requirements whileoptimizing the time and cost ofdelivering an app."perhaps software targeting cross-platform plugins,like Silverlight, Flash or Java.The same principles apply to a new era ofmobile software development. A mature mobileorganization with an optimized strategy will havea mix of mobile apps developed with Web, Hybrid,and Native approaches. The key is knowing how tochoose the right approach for each application.Share this article
THE THREE PRIMARYAPPROACHESWEBMobile web development leverages the sameskills and workflow traditionally associated with“desktop” web development. Developers buildwebsites using HTML, JavaScript and CSS thatare then accessed on mobile devices via mobilebrowsers. While some degree of local cachingcan be employed, most mobile web apps rely ona constant connection to the Internet and a webserver to provide the views and content as a usernavigates through the app.There are two ways developers target apps formobile devices with the web:1. Responsive Web Design: WithThere are three broad approaches to developingmobile applications: Web, Hybrid, and Native.Each affords distinct advantages to a mobiledevelopment team, and none is a silver bullet thatwill meet the needs of all mobile applications.As with all software development, there aretradeoffs that must be considered when choosingA publication of4between these options. Understanding when andwhy to use each of these approaches is key toforming a consistent and optimized mobile strategy.The following sections briefly describe each of theprimary approaches to mobile development andhighlight common pros and cons.Share this articleresponsive web design (RWD), developersprimarily focus on modifying the layout anddisplay of existing desktop websites to adaptto the smaller screen size and touch-inputof mobile devices. The advantage is a singleweb code base for both desktop and mobileusers, but RWD is generally limited in its abilityto create a “tailored” mobile experience thatimitates the look-and-feel of native apps. It canA publication of5also be challenging to use this technique whena desktop web experience contains complexwidgets, such as data grids, that do not easilyadapt to mobile screens with responsive CSS.2. Mobile Web App: Alternatively, developerscan build web-based experiences designedspecifically for mobile users. In this scenario,mobile devices are usually detected anddirected to a mobile optimized web app wheredevelopers can build tailored experiences thatconform to mobile specific UI conventions.While much of a mobile web app’s code basecan continue to be shared with desktop webapps, this approach does require developers tobuild and maintain separate view (HTML/CSS)implementations for both mobile and desktopclients. Developers can choose to make mobileweb apps look and feel exactly like installablemobile apps, or they can choose simplerpresentations that feel more like traditionalbrowser web apps (with no attempt to mimicnative UI).Share this article
is ultimately limited access to device capabilitiesrelative to native and hybrid options. Unlike hybridapps, which are able to expose essentially anydevice API via native plug-ins, web apps are limitedto the features built-in to mobile browsers. Webapps also offer a very weak offline story in today’sbrowsers, so any app that needs to work withoutan active Internet connection will be a challenge toimplement on the web.Web is one of the most familiarand fastest ways to reachmobile users. "Regardless of which approach to web a developerchooses, web is one of the most familiar and fastestways to reach mobile users. No software installs(and subsequent updates) are required. Applicationaccess and information security can continue tohappen in the data center on the server. And doneproperly, a mobile web app can reach all mobiledevices with a browser, not just a limited subsetof specifically targeted mobile platforms. Modernmobile browsers are even exposing an increasingnumber of device APIs, such as geolocation, viaJavaScript, further enhancing the capabilities ofmobile web-based apps.That said, the trade-off for a mobile web app’sfamiliar development platform and maximum reachPROSEven still, for apps that don’t require offline supportand don’t exceed the capabilities of the web (noneed to access device sensors/APIs, for example),the web remains a very compelling way to buildand deliver mobile apps.Essential skills: HTML, JavaScript, CSSEssential tools: Anything capable ofdeveloping web appsPlatform reach: iOS, Android, Windows Phoneor any HTML5 capable mobile browserSharable cross-platform codebase:100% (UI Logic)CONS Familiar, very low developer learning curve Limited access to device hardware, APIs Easy to deploy, no software installs Poor offline support, requires “always on”Internet connection Easy to share code with desktop websites Unable to “install” on a device or publish via anapp store Maximum reach Reuse existing security and softwaremanagement solutions Unable to match native performance for rich,animated interfaces Open standards-based platform(no vendor lock-in)A publication of6NATIVEShare this articleOn the other end of the spectrum from mobileweb app development is native app development.As the name implies, native apps are built usingplatform-specific SDKs and development toolsprovided by the platform vendors. For iOS, thatmeans apps are built using Objective C in Apple’sIf something can be done on a mobiledevice, then native apps will imposethe fewest limits."A publication of7XCode. For Android, that means apps are builtusing Java and Google’s Android SDKs. WindowsPhone is .NET and Visual Studio, and so on. Everyplatform has its own SDKs, and often, its ownprogramming language.The advantage of native mobile apps, of course, ismaximum access to the features and APIs availableon each platform. If something can be done ona mobile device, then native apps will imposethe fewest limits. As stated in an MGI Researchstudy titled Buyer's Guide for Mobile EnterpriseApplications Platforms (MEAP), “Native architecturetends to offer the richest, most graphically engaginguser experience, high performance, and the abilityto integrate with native device functions and backend enterprise systems.”Share this article
This power comes at the high cost of buildingapps that only reach one platform at a time, andwith the requirement that development teamsbuild and maintain multiple platform-specific codebases for the same app. Native app developmentis the most powerful, but the most expensiveand slowest approach to reach all mobile users,especially if an app must support two or moreplatforms. Still, when maximum power is required,nothing beats native.Essential skills*: Objective-C, Java, .NET,HTML/JavaScriptEssential tools*: XCode (for iOS), Eclipse(for Android), Visual Studio (for WinPhone)Platform reach: Each app only reachesone platformSharable cross-platform codebase:0% (No UI, No logic)*Required skills and tools will vary depending on targetplatforms. To support the “top” mobile platforms today, aminimum of three programming languages and three IDEsis required.PROSCONS Complete access to device hardware, APIs Installable, can be app store deployed Multiple implementations required to reachmultiple platforms Maximum control over performance Multiple skill sets and programming languages Powerful platform-specific development anddebugging tools direct from platform vendors Requires installation (and device provisioning ifprivate deployment desired) New tools needed to manage app security,enforce data security policiesThe major drawback to multi-platform nativesolutions today is that the frameworks providingthe abstraction are proprietary and reach alimited number of mobile platforms. Developersadopting one of these solutions will be “lockedin” to vendor specific abstractions (or bindings)and will be dependent on that vendor to continueto evolve the abstraction as underlying mobileoperating systems change. In many ways, multiplatform native solutions face the same limits andrisks as cross-platform plugins like Silverlight andFlash. If a company is willing to accept the riskof the underlying multi-platform technology, thesolution can be a great path to simplifying normallyexpensive and time consuming native developmentfor multiple platforms.Essential skills: Depends on the multiplatform solution (examples: C#, JavaScript)Essential tools: Usually a custom developmentenvironmentPlatform reach: Limited to platformssupported by underlying compilerMulti-Platform NativeDevelopmentBefore discussing hybrid, it’s worth mentioninga “middle-ground” option that has emergedfor developing native applications acrossmultiple platforms. With multi-platform nativedevelopment, developers write an applicationin a single language (such as JavaScript or C#)targeting an abstraction layer to access nativedevice APIs and SDKs. When the application iscompiled, different app packages are producedA publication ofbelow), which rely on embedded web containersto present full-screen HTML-based UI. As a result,multi-platform native development is appealingwhen an app’s UI complexity exceeds the limits ofHTML, CSS and JavaScript, such as apps with lotsof animation or movement.8that can run “natively” on different platforms.The result is a multi-platform “native” applicationwritten in non-native language, and a code basethat can be largely shared between platforms.The actual degree of “nativeness” and codereusability varies between multi-platform solutions,but in all cases the UI for the application is native.This is different from hybrid applications (discussedShare this articleSharable cross-platform codebase*:Partial (UI is generally not sharable)*Clearly, exact sharability depends heavily on the multiplatform native technology stack and app design. Somesolutions provide better support for sharing UI and logic;some leverage platform-specific native UI, requiring customUI implementations for each target platform.A publication of9Share this article
app. In fact, prior to rebuilding their mobile appsnatively, Facebook used hybrid technology tocreate some of the world’s most popular mobileapps, reaching millions of users. Most users, andeven many developers, did not know Facebook’sapps were anything other than native. In fact, 52%of developers surveyed by Telerik in 2012 wereunaware of this fact.HYBRIDRecognizing that most developers, given thechoice, would prefer apps that have the “reach” ofweb and the “richness” of native, hybrid attemptsto blend the benefits of web and native mobile appdevelopment. According to a recent Telerik KendoUI Survey on HTML5, when asked what makesHTML5 development more appealing than otheroptions for writing software, 62% said reach/crossplatform support as one of the biggest benefits.Hybrid apps are developed using standard webtechnologies, like HTML, JavaScript and CSS, butare able to overcome the limits of “pure” web appsby using platform-specific native “wrappers” topackage and deploy the code. The native wrappersallow hybrid apps to be installed on devices, deployvia app stores and access native device APIsvia JavaScript.Since hybrid apps are built with web technologies,the learning curve is very low for web developers,and most existing JavaScript libraries can beA publication of10leveraged from within a hybrid app. Seventy-twopercent of developers surveyed by Telerik, notedthe familiarity of languages as most appealing.Developers can further access any native API ordevice capability via plugins that expose additionalnative features to JavaScript code. Popular hybridcontainers, like Apache Cordova, offer a richecosystem of available plugins, and developerswith native programming skills can choose tocreate custom plug-ins tailored to specific apprequirements.Hybrid apps are completely self-contained. Noserver is required to launch or run a hybrid app,other than to supply or persist data within theapp. In this way, hybrid apps are identical to native.When a hybrid app runs, the native applicationwrapper hosts a full-screen web container inwhich the HTML, JavaScript and CSS are loadedand run. To an end user, a well done hybrid appcan be visually indistinguishable from a nativeShare this articleThe primary limit of hybrid apps is the speedand performance of the web container on eachtarget device. Older, slower devices require highlyoptimized code to achieve expected performance,while newer, faster devices are more capableof running more complex CSS and applicationJavaScript without making hybrid apps appearslow. For this reason, hybrid development is bestused when the requirements of an app exceed thelimits of web, but do not demand the full power ofnative. As an example, simple line of business appsthat require offline support are great candidates forhybrid. Hybrid development for enterprise mobilityis increasingly endorsed by leading industryanalyst firms as well. In its 2013 release, Gartnerrecommends the hybrid approach, which “offers abalance between HTML5 and native” for Businessto-Employee mobile apps. Meanwhile, rich,interactive games or highly-animated interfaces arenot good candidates for hybrid.PROSHybrid development is best usedwhen the requirements of an appexceed the limits of web, but do notdemand the full power of native."Essential skills: HTML, JavaScript, CSS,Hybrid container (such as Apache Cordova)Essential tools: Anything used for webdevelopment* hybrid SDKsPlatform reach: Limited to reach of hybridcontainer, but most reach all major platformsSharable cross-platform codebase:Almost 100% (Some platform specific UI may bedesired)*While web development tools can be used, tools designedand optimized for hybrid mobile development can improveproductivity by helping with debugging, packaging anddeployment to devices.CONS Low learning curve for web developers Performance limited by web’s capabilities Installed, can be app store deployed One code base for all platforms Requires installation (and device provisioningif private deployment desired) Easy to transition from web to hybriddevelopment, reuse code New tools need to manage app security,enforce data security policies Extensive access to device hardware, APIsA publication of11Share this article
HOW DO YOU CHOOSETHE “RIGHT” APPROACH?If native is determined to be a requirement, plan ontargeting one platform, such as iOS, first, and thenrolling-out additional apps to additional platforms.In some cases, it even makes sense to build onenative app for one platform, complemented by aweb or hybrid app to address all other platforms.What are the skills of ourdevelopment team?Who is the audience for the app?There is a big difference between buildinginternal Business-to-Business (B2B) or Businessto-Employee (B2E) apps and building public,consumer-facing, Business-to-Consumer (B2C)apps. The differences are similar to developinginternal web apps or line of business apps andA publication of12developing a company’s primary, consumer-facing.COM website or packaged, off-the-shelf software.Meanwhile, if a team is not familiar with webdevelopment, or is not skilled in creating anddebugging JavaScript, pursuing native or crossplatform native can avoid future frustration andwasted development time. The available nativedevelopment tools can also help a team producebetter results if they are not proficient debuggingand optimizing JavaScript.Internal apps often prioritize budget and flexibilityover rich experience, making them ideal candidatesfor web and hybrid development.How long do we have to developthe app—and for how manyplatforms?Timelines have always been a critical factor in anysoftware project. With mobile, if the goal is to reachmultiple platforms, a tight timeline may requirethe use of web, hybrid or multi-platform nativedevelopment. Developing the same app multipletimes with native SDKs may simply exceed the timeand budget of many projects.Share this articleIf offline support is important, developingwith the web will be much more difficult, if notimpossible. Hybrid or native development willbe needed to create the desired sometimesconnected capabilities.Does the app need to accessdevice APIs or hardwarefeatures?Teams with strong backgrounds in webdevelopment are going to be more productivefaster with mobile web and hybrid appdevelopment. Strong skill reuse will minimizelearning curves and often translate back intoimproved desktop web apps.Choosing the “right” approach to develop amobile app depends entirely on marrying therequirements and budget of an app to thecapabilities and cost of a mobile developmentapproach. As such, it is impossible to genericallyprescribe the “right way” to build every mobile app,but for businesses building many mobile apps,asking the following questions can help determinewhether web, hybrid or native is right for anymobile project:Does the app need to work offline?Internal apps often prioritizebudget and flexibility overrich experience, making themideal candidates for web andWhile mobile web apps have access to basic deviceAPIs and hardware sensors, apps that require morecomplete access should plan on hybrid or nativeimplementations. If it is known up-front that an appwill need push notifications, access to the devicecamera, contact list, file system or other nativecapabilities, you can quickly eliminate web as anoption for developing the app.What is most important for theapp: Experience, Reach or Cost?If maximum reach is desired, nothing beats theweb. It spans all screens, even those not yeton the market today, while minimizing risk ifpopular platforms today fail in the future (such asBlackBerry). If maximum “experience” is desired,with rich, animated interfaces, native is the safestchoice. Animation in particular is taxing on hybridand web performance, and native will provide morepolished results. Finally, if it’s a blend of reach andrichness that’s required, hybrid is a solid choicethat can help control costs and promote codereusability across platforms.hybrid development."A publication of13Share this article
INEFFICIENCY OF“ONE SIZE FITS ALL” STRATEGYIt is tempting to look for the “one size fitsall” solution to mobile development as a wayof reducing complexity. Unfortunately, anystrategy that attempts to develop all apps usingone approach will ultimately force inefficientdevelopment decisions, waste development time andmoney, and limit the flexibility of an organization.Avoiding one or the other option completely is notwise either. As Forrester puts it, “Don’t be a mobiletechnology lemming; simply because Facebookdecided to move away from HTML5 doesn’t meanthat you should do the same.”For example, basic internal apps that need toquickly reach all employees and rapidly evolve withthe business are likely best built as mobile webapps. No installs. Reusable code for desktop andmobile clients. The requirements do not exceedthe limits of web, and the web offers a low cost, fastway to deliver the mobile solution.Meanwhile, polished apps that reach a business’customers via public app stores are bettercandidates for hybrid or native development.Consumers expect to discover apps in an appstore. The app is less likely to change as rapidly.And overall, the goal is to optimize experiencemore so than cost.A publication of14MOBILE APPLICATIONMANAGEMENTAPPAny strategy that attemptsto develop all apps using oneapproach will ultimately forceinefficient development decisions,waste development time andmoney, and limit the flexibility ofan organization."If a “one size fits all strategy” is adopted, such as“all native” or “all hybrid” mobile development,inefficient decisions will be made in thesescenarios. A company may overspend and reduceagility building many native internal apps, or it mayfail to deliver the right experience for a polishedconsumer-facing app.Beware the temptation to find a mobiledevelopment silver bullet, and instead adopta smart, optimized strategy that drawson the benefits of web, hybrid and nativeapp development.Share this articleOne hidden implication of choosing betweendifferent mobile app development approaches ishow that decision will impact the need for newapplication management policies and tools. Unlikedesktop applications which tend to stay inside thefirewall on computers that don’t regularly leave thebuilding, mobile apps are everywhere. They quiteliterally live with users, frequently traveling outsidethe boundaries of traditional corporate security.This has significant implications on applicationdistribution and security. When native or hybridmobile apps are created, a company must deal witheach of the following: How does the app get on “allowed” devices(assuming it’s not a public app store app)? How is access to the app controlled (forscenarios where a device is lost or employee/partner access needs to be revoked)?A publication of15 How are updates delivered (and enforced)? How is cached data handled and securedon a device? How is app usage monitored? How are crashreports collected?A company unprepared to deal with thesechallenges may have extra motivation to considermobile web apps, which can typically reuse existingdelivery and security policies set-up for traditionaldesktop web apps. With no installs and often nooffline data storage, mobile web apps sidestepthe need to introduce formal mobile applicationmanagement solutions.When choosing between web, hybrid and native,in addition to matching the strengths of eachapproach to a mobile app’s requirements, acompany should also consider the secondaryimpacts, like mobile application management,before making a final decision.Share this article
OPTIMIZED MOBILE STRATEGYDECISION GUIDEThe following diagram illustrates how to apply anoptimized mobile development strategy to choosebetween web, hybrid and native for any project.Clearly, every organization will have differentcriteria to consider, but this example is a goodABOUT THE AUTHORstarting point for any company building multiplemobile apps reaching different audiences, likeemployees (B2E), business partners (B2B) andconsumers (B2C).WEBNONOExceedcapabilities amskills?NATIVEYESEVP of Cross-Platform Tools & ServicesYESYESTeamskills?App Storedeployed?B2B ities ofhybrid?HYBRIDMobile Development:Web, Hybrid or Native?Requiremulti-platformsupport?Todd AnglinNOnotWEBNOExceedcapabilities ofweb?NONOWEBExceedcapabilities ofweb?YESNATIVEAs the EVP of Cross-Platform Tools & Services atTelerik, Todd Anglin is responsible for the Telerikgrowing line of tools for web and mobile appsdevelopment, including Kendo UI and AppBuilder.He leads a global team of engineers, evangelistsand business analysts and oversees the design,creation, sales and support of the Telerik industryleading HTML/JavaScript tools.Previously, Todd worked in Fortune 200 financialservices enterprise IT, and has experienceindependently building and selling SaaS. Hegraduated with business honors from MaysBusiness School at Texas A&M University with aBachelor's Degree in Business Administration. He isbased in the Telerik office in Houston, Texas.He is on Twitter at @toddanglinConclusionMobile development may be complex anddisruptive, but the core principles of softwaredevelopment that have been honed for more thantwenty years still apply. Every app is unique, andthat demands a strategy capable of intelligentlyA publication of16delivering the right result. When a mobile strategyis built around the three approaches to mobile appdevelopment, every app can be delivered on-timeand on-budget.Share this articleTodd joined Telerik in 2007 and prior to servingas EVP of Cross-Platform Tools & Services, he wasTelerik Chief Evangelist, building and coordinatingTelerik global evangelism efforts. Todd is a wellrespected HTML5 industry leader and is an activemember of the .NET and HTML5 developercommunities. He is also a Microsoft MVP, founderand president of the North Houston .NET UsersGroup, and O'Reilly author.A publication of17Share this article
web app development is native app development. As the name implies, native apps are built using platform-specific SDKs and development tools provided by the platform vendors. For iOS, that means apps are built using Objective C in Apple's If something can be done on a mobile device, then native apps will impose the fewest limits." XCode.
Two types of cross-platform applications In practice, we encounter two main types of cross-platform apps: cross-platform native and cross-platform hybrid. Cross-platform native leverages on better native application performance compared to hybrid because the code is compiled into native controls. Therefore, it feels and runs like a native app.
NATIVE INSTRUMENTS GmbH Schlesische Str. 29-30 D-10997 Berlin Germany www.native-instruments.de NATIVE INSTRUMENTS North America, Inc. 6725 Sunset Boulevard 5th Floor Los Angeles, CA 90028 USA www.native-instruments.com NATIVE INSTRUMENTS K.K. YO Building 3F Jingumae 6-7-15, Shibuya-ku, Tokyo 150-0001 Japan www.native-instruments.co.jp NATIVE .
NATIVE INSTRUMENTS GmbH Schlesische Str. 29-30 D-10997 Berlin Germany www.native-instruments.de NATIVE INSTRUMENTS North America, Inc. 6725 Sunset Boulevard 5th Floor Los Angeles, CA 90028 USA www.native-instruments.com NATIVE INSTRUMENTS K.K. YO Building 3F Jingumae 6-7-15, Shibuya-ku, Tokyo 150-0001 Japan www.native-instruments.co.jp NATIVE .
React Native React Native stands out among its cross-platform competitors with its ability to render native components on both supported operating systems, iOS and Android, while still maintaining a unified code base. Most other cross-platform solutions ei-ther
Native Village of Port Heiden Lake and Peninsula Borough Meshik Inc. Bristol Bay Native Corporation Port Heiden Native Village of Port Lions Kodiak Island Borough Afognak Native Corp Koniag, Incorporated Port Lions Native Village of Ruby Yukon-Koyukuk Census Area Dineega Corp Doyon, Limited Ruby Native Village of Saint Michael Nome Census Area .
React-Native Apps JS components render as native ones Learn once, write everywhere 13 Android Android SDKs Native UI JS Runtime React Native 3rd Party Libs NPM Pkgs (e.g., React) Bridge Your App Your App (JS) (Native UI & Modules) iOS iOS SDKs Native UI JS Runtime React Native 3 Party Libs NPM Pkgs (e
NATIVE INSTRUMENTS GmbH Schlesische Str. 29-30 D-10997 Berlin Germany www.native-instruments.de NATIVE INSTRUMENTS North America, Inc. 6725 Sunset Boulevard 5th Floor Los Angeles, CA 90028 USA www.native-instruments.com NATIVE INSTRUMENTS K.K. YO Building 3F Jingumae 6-7-15, Shibuya-ku, Tokyo 150-0001 Japan www.native-instruments.co.jp NATIVE .
Description Logic: A Formal Foundation for Ontology Languages and Tools Ian Horrocks Information Systems Group Oxford University Computing Laboratory Part 1: Languages . Contents Motivation Brief review of (first order) logic Description Logics as fragments of FOL Description Logic syntax and semantics Brief review of relevant complexity .
