Analyst Report: The cross-platform mobile app: advice for enterprise developers

1 Summary

Development tools and methodologies for cross-platform mobile applications have been with us for many years, and they now claim some astounding benefits: five to ten times faster development; usage of familiar languages like HTML5, JavaScript, and CSS; and development and maintenance of a single codebase.

Today’s developers now have several choices to assist with cross-platform design, ranging from options of application type, supported languages, toolkits, and delegation of logic to scalable, remote backends. Each of these comes with a set of trade-offs, and the speed with which they evolve requires examination of where each will be headed in the future.

In this report, we explore and expand on the following:

  • The four avenues through which mobile cross-platform development can be achieved (mobile-styled web app, hybrid app, cross-compiled app, and MBaaS), along with the limitations, benefits, and use cases for each.
  • The strict limitations of HTML5, JavaScript, and CSS applications and the specific use cases and applications for which the approach may be valid.
  • The tremendous upside of solutions like Xamarin and Appcelerator, which enable developers to write code in one language and cross-compile down to native code on mobile devices.
  • The fairly recent trend in offloading client-side business logic to MBaaS and remote service solutions and where this approach does and does not make sense.
  • Organizational and structural challenges encountered by web and desktop development teams and how managers can best overcome those challenges.

(Feature image courtesy Flickr userphilcampbell)

2 Defining the mobile beast

Cross-platform mobile app toolkits appear to make two beasts many of us are familiar with — cross- browser web development and stand-alone desktop apps — into a single plausible animal with the obvious benefits of each. Although these toolkits are both real and extremely abundant, they can lead
developers to mistakenly view their mobile app as a chimera rather than the entirely new species that it is.

Cross-platform mobile app development tools are alluring, and we innately want to believe their many claims. The tools and frameworks even come in many flavors that offer us a spectrum of capabilities and deployments, including mobile web technologies that use HTML5, JavaScript, and CSS; tools and frameworks that ease the building of these mobile web apps; and finally “cross compile to native” tools that allow us to write our code once and deploy natively everywhere.

Because our mobile devices are (at least in theory) constantly connected to the network, we even have the ability for the apps to simply be native UI wrappers that pass some or all of their heavy lifting over REST to remote servers with centralized codebases written by our web teams in the language they are most proficient in. If you don’t want to write those backends from scratch, there are even mature, thriving spaces known as MBaaS and remote services, with many vendor options to choose from.

3 User expectations trump developer benefits

Good developers know that they should be reusing code. They know model-view controller (MVC) software makes their lives easier and their software easier to maintain and extend. They know that patterns repeat, and they pride themselves on being able to know when and where to use these patterns. They know in their heart of hearts that cross-platform mobile development is what they should be doing. What both developers and enterprises often fail to realize, however, is that mobile is a beast unlike any other, with the biggest difference being the expectations of users about speed, functionality, and familiarity (native UI).

Mobile users expect the responsiveness of a desktop app even when calling remote services. They expect that their apps will easily integrate with all of their specific device’s hardware, and they expect their apps will present familiar, well-rendered UIs, regardless of their screen size or resolution.

Unfortunately for the mobile developer, speed, functionality, and familiarity are the same three attributes on which cross-platform tools compromise in order to fulfill the promises of productivity and single code base. Hardware access and/or UI limitations alone could outright disqualify many a cross-platform tool from even being considered for use, and more than one enterprise has had to recently rebuild its app natively on each platform after user outcries about speed of HTML-based solutions.

In Sept. 2012, Mark Zuckerburg pulled no punches in stating that “HTML5 was one of Facebook’s biggest mistakes,” citing speed issues as the largest cause of user dissatisfaction with its app. Just a few months later, LinkedIn revealed that due to memory constraints, it too had been forced to scratch its HTML5 app and rerelease on native.

4 Questions to ask before you start

Given all of this evidence, it would be easy to write cross-platform mobile development off as a myth, tell you to write your apps native from the get-go, and let you continue about your day. Anyone who tells you that, however, is dead wrong. HTML5 is a completely viable way to deliver some apps in a cross-platform manner, but it’s no longer the only game in town. Developers can now choose from a spectrum of tools and toolkits — some of which can be used in concert— to centralize code base, cut down development and maintenance time, and deliver their apps faster and more reliably across multiple platforms.

“In certain cases, these tools can give you huge productivity gains, sometimes north of 90 percent,” says Steve Loper, the director of innovation at Boulder, Colo.–based technology solutions provider Amadeus Consulting. To get those gains, however, you must pick the right tool for the right case, and you need to ask the right questions. Unfortunately, most folks get it wrong from the start. “The most important question many decision makers neglect to ask is, ‘What do I have?’” Loper continues. “‘Do I have strong HTML5, JavaScript, and CSS talent? Does my team have substantial .NET or Java depth? Are we used to outsourcing all but core competencies?’” The next step is to make sure the technology can deliver on the business need: A viable solution must provide toolkit functionality, developer productivity, and business need.

The decision tree starts getting more complicated after that first question, and the HTML5 branch has many more leaves. The high-level questions you need to ask before writing a single line of code will probably resemble something like this:

Do we have in-house HTML5, CSS, or JS wizards? And/or:

  • Is my app incredibly simple?
  • Can our users accept slower interactions (and possibly even a web app)?
  • Can our users can tolerate a clunkier UI?
  • Will our app only be consumed by internal users?
  • Is our app a prototype to prove market demand?
  • Do we have C# wizards for Xamarin, Ruby wizards for or RubyMotion, or Javascript wizards for Appcelerator Studio?
  • Can we (or must we) push logic to a remote service? And/or: Can our users live with a network requirement?
Approach Pros Cons Best fit
Mobile-styled web app Extremely fast deployLittle or no maintenanceCommon UI across platforms Not a true mobile app (no access to hardware, no icon, no app store)Network requirementUnsuitable for widespread external audience Internal customersComplicated web product that would be costly to reproduce as an appCustomers just need “something on mobile now”
Hybrid app Fast buildCommon developer skill setAccess to most device hardwareDiscoverable in app storesCan incorporate HTML5, JavaScript, and CSS libraries such as jQuery MobileSingle codebase “Uncanny valley” problemVariable performance and support across devicesLack good debugging and profiling toolsHigh risk, as coding work-arounds can consume all productivity gains All web app casesSimple appsUsers can tolerate slowness and clunkinessPrototyping
Cross-compiled app (Xamarin) Native performanceAccess to all device hardwareNative UIIndustry-standard languageDiscoverable in-app storesPotential for code reuse

Single codebase

.NET and C# requirementCurrently limited to only Android and iOS Enterprises with access to good .NET and C# developers
MBaaS and remote service Can be used in concert with any of the above solutions or even straight nativeScalableCost-effective (usage-based pricing)Quickly leverage existing enterprise and legacy systemsOffload heavy lifting to in-house or third-party remote servicesAllows nondevelopers to build mobile apps

Single codebase in well-understood language (if developing in-house service)

Network requirementAdditional costCould result in vendor lock-inExperience degrades with slow connections Access to existing enterprise functionalityDon’t want to reinvent the wheelLogic cannot be implemented with limited mobile device processing and storage powerPrototyping (start with third-party MBaaS to speed deployment and save dev costs)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The answers to those questions will drive your direction and lead you down one or more of the four paths we discuss in this article.

If you do want to take an HTML5-based approach or leverage remote services, pay particular heed to the speed, functionality, network connectivity, and UI concerns of your users. You wouldn’t want a prototype giving a false negative because the delivery, not the idea itself, was flawed.

HTML5 is without a doubt still the riskiest route to take, but many have achieved success, as long as they understand and account for the risks. Chief among those risks is this: If you use HTML5-based cross- platform toolkits, you could well find all of your productivity gains negated upon having to code work- arounds for limitations of the kit or platforms. HTML5 cross-platform dev tools provide over 90 percent of all the functionality and UI needs. But it’s common to need something from that remaining 10 percent, and coding work-arounds can get costly. For many projects, the current tools might involve an unacceptably high risk for a marginal, possible gain. But expect that to change in the future. “Wherever there is interest,” says Loper, “the tools will improve.”

5 Four paths to a cross-platform app

There are a myriad of risks and rewards inherent with cross-platform mobile development, but fortunately, there are really only a handful of approaches you need concern yourself with. Let’s explore four of the most promising paradigms: web apps, hybrid apps, cross-compiled apps, and MBaaS and remote services. Each comes with its own trade-offs, summarized below.

6 Mobile-styled website

Browser-based web apps styled for mobile devices are about as simple as it gets. Your web team just uses whatever tools it likes for the logic layer (PHP, Ruby, Python), HTML (doesn’t have to be HTML5), JavaScript, and CSS development and builds appropriate stylesheets, and next time a consumer hits your website with a mobile device, she gets a better experience. Downsides here are obviously that this is not an app in any sense of the word. It’s a mobile view of a website, with all the associated lag, no access to device hardware like camera and geolocation, no discoverability in the app store, and no individual icon on the mobile device. The advantage is it can be fast to deliver and maintain: There’s only one codebase on the server, and because it’s all being rendered in the mobile browser, your web team’s cross-browser design skills can come in handy. Several JavaScript libraries exist to help with mobile functionality and UI, with jQuery Mobile being the most popular.

Plain Jane web apps should be considered for any mobile experience outside a widespread external audience. You’ll be able to release them quickly, and if they are nothing more than styling on an existing web product, your mobile users will automatically receive any upgrades made to the core code, meaning little or no maintenance.

7 Hybrid apps

Once we take a step up from the web app, we begin using toolkits such as PhoneGap to build packaged web apps, more commonly known as hybrid apps. These toolkits essentially wrap your HTML5, JavaScript, and CSS code with device-level access, going through the device’s WebView engine, which is separate from the device’s browser. This means we can now both access hardware and package the software into a true app that runs on the device. Logic must be written in JavaScript (and, possibly, to some extent HTML) since there is no server-side parser, but this also means that you can still include libraries like jQuery Mobile and make their functionality part of your app. That logic now goes through an interpretation layer, which lets us communicate with hardware on the mobile device. The wins here are that we now have access to some hardware features through a single codebase, and these apps can even be submitted to both Apple and Android app stores. Where this type of app falls short is when we need to implement that last 10 percent: The core of the application development flies by using the toolkit and its wrappers, but then the last 10 percent drags on for weeks as your team finds ways to implement functionality the toolkit doesn’t provide (or provides in a way other than you need).

In addition, these apps are susceptible to entering the “uncanny valley,” where they look and behave close to a native app, but the subtle differences throw users off and can significantly interfere with the experience. Perhaps the best bit of advice to keep your app looking native with these toolkits is, surprisingly, don’t. Apps in this space will never look or behave exactly like native apps. Because that’s never going to happen, be bold and go the other direction, like TripCase did: Give your app a unique look and feel that is largely the same across platforms.

The lack of performance and debugging tools are two other complaints common with these apps. “You’re at the mercy of the JavaScript engine on the device, and your app will likely push JS harder than it’s ever been pushed,” Loper explains. Because the engine varies from device to device, it’s also fairly common to see an app fly on one platform and crawl on many others, and tracking down that performance variance can be painful. Debugging is also nowhere close to what we expect with enterprise software, with an overall lack of stepping and breakpoints. While some environments like Kendo UI by Telerik are built from the ground up with the goal of providing high-performing and solid hybrid mobile web experiences, without these tools you’re often relegated to archaic methods like console.write statements.

“It’s hard to compare any hybrid approach directly to native dev, because ‘hybrid’ simply means HTML/JS/CSS and some kind of device API framework, like Apache Cordova,” explains Brandon Satrom, the lead product manager for Cross-Platform Tools and Services at Telerik. “It’s only when you consider the developer tooling experience around building hybrid apps that a fair comparison can be drawn. In the case of Kendo UI Mobile, we’ve dedicated a lot of time to performance because we believe that hybrid app developers should get the same high quality UI widgets in a mobile web framework that they get from built-in native equivalents.”

Debugging tools are perhaps one of the fastest-changing areas in this space, with several commercial and open-source offerings readily available. In addition to several recent performance-focused improvements in Kendo UI Mobile, developers now have access to tools like Google’s Chrome DevTools and Safari’s own DevTools, which allow them to connect their mobile device and thus, their app, to the desktop debugging devices that they already use.

Despite their limitations and risks, hybrid app toolkits boast a long list of Fortune 500 companies that have successfully deployed apps (including games and complicated UIs) with their tools, and that list has ballooned over the past year as the tools themselves have improved. If you have a strong web team and can accept the caveats and limitations we’ve covered, these tools can enable them to crank out an app on multiple platforms in a fraction of the time it would take to write native. The strict definition of an app is a small, single-focus piece of mobile software, and if you’re writing a true app —something simple and straightforward, which is unlikely to enter the “10 percent is really tough” arena — both PhoneGap and Appcelerator (which can also package apps to hybrid, and even has MBaaS solutions) are worthy of your attention.

8 Cross-compiled native apps

One step higher up the abstraction layer, we have tools that cross-compile code to native applications, with providers like Appcelerator Studio and SDK Xamarin, and RubyMotion (at the time this report was written, the latter, unfortunately, can only deploy to iOS).

The Appcelerator Studio and SDK (powered by their free developer product Titanium) allows enterprises to build cross-compiled native, hybrid and mobile web app, all from a single JavaScript code base. Appcelerator’s platform takes an end to end approach in order to accelerate mobile app delivery and lower total cost of ownership for enterprises that are delivering multiple applications to customers and employees. It provides an optional robust MBaaS solution and includes built-in analytics which capture and track metrics for app functionality in the wild (crash reports and exception handling) as well as in-app engagement and adoption.

Those familiar with the successful Mono open-source project know that its biggest benefit was allowing .NET developers to easily run their C# code on Linux. Xamarin is a company spun out of Mono, with the focus instead on allowing C# code to run on mobile. The company provides three products: Xamarin iOS, Xamarin Android, and Xamarin Mac, which allow developers to compile their C# code to native iOS Android and Mac OS X, respectively. If you have a stable of talented .NET developers, Xamarin should be high on your list of tools to evaluate. In addition to letting your developers use C# (and tools like VisualBasic that they already know), you also get the ability to reuse existing code and have your apps all served by a singular codebase. The resulting products are native apps, which can be submitted to the Apple and Android app stores. Xamarin also does not come with the risks of the HTML5, JavaScript, and CSS tools. Ryan Paul, the developer evangelist at Xamarin, proudly states, “Virtually anything that can be done in Java (for Android) or Objective C (for iOS), can be done in C# with Xamarin.”

For the UI layer, Xamarin gives you the option of either building a separate UI for each platform or cross- compiling the UI, although most folks opt for the former in order to avoid the uncanny valley problem. One might think that building separate UIs could slow development down significantly, but even with UI- heavy apps, such as the highly successful iCircuit, Xamarin has allowed developers to achieve 70 to 80 percent code reuse. Where Xamarin can shine even brighter is on the other end of the spectrum, where you have a complex piece of mobile software of which UI is only a relative fraction of the codebase.

This cross-compile space offers maybe the most exciting current and future prospect for cross-platform apps. What could be more enticing than a platform that lets developers write mobile apps in an industry- standard language and provides native speed and functionality for both the program logic and UI?

9 MBaas and remote services

Most cross-platform discussions stop right here with the three approaches of delivering the core application. When you’re in the mindset of doing cross-platform development, however, you really need to always be thinking of MBaaS and remote services, which allow you to offload some of the app’s logic to server-side code. Many operations such as file storage and sharing, push (to device) notifications, user management, third-party (typically social network) integrations, and possibly even core business logic either cannot or should not be performed using the limited processing and storage power of the mobile device. Furthermore, you may already have partially or fully built backend systems that you simply need to tie together and deliver in a mobile experience. “Regardless of how you build your application, be it with HTML5 or native, moTwin allows you to orchestrate, integrate and streamline delivery to mobile of any enterprise back-end data” explains Allan Denis, the CTO of moTwin. By pushing logic to a single codebase on a remote server, your team will save time both building and maintaining that logic.

If competition is a proxy for developer interest, then MBaaS (which provides not only the API but also the actual backend storage and processing services as well) and remote services (which provide middleware connectors to enterprise and/or legacy systems) may be where most of the “cross-platform mobile app” interest lies, with at least 30 competing product offerings from companies like StackMob, Appcelerator (which also makes Titanium), moTwin, Catavolt, and Parse.

A big draw of these products is that most offer API builders that let developers (or even nondevelopers) quickly connect to third-party or even internal data sources and systems such as ERP and CRM, oftentimes via point-and-click interfaces. For apps that either need a considerable amount of remote interaction or integration with third-party or enterprise systems, these services can save considerable development and maintenance time. The cost for most of these services follows the reasonable, usage- based service model of the cloud, and the only real downside is the network-connectivity requirement and possible lag, which are often mitigated by doing device-side caching.

True MBaaS services such as those offered by Parse, Appcelerator, and StackMob also often provide the actual processing and storage layer, something to watch if you’re concerned about vendor lock-in. If you’re worried about starting down that path, take the time to investigate and understand how your data could be exported should you ever wish to switch providers.

With network speeds and coverage getting better all the time, it may also be worth following the MBaaS model and acquiring a bit of cross-platform compatibility by pushing some of your app’s more-involved logic to your own centralized, REST-accessible custom backend, essentially building your own internal MBaaS.

10 Organizational concerns

To get an app right, an enterprise needs to not only match its mobile users’ speed, functionality, and familiarity requirements up to the appropriate technology stack and tools but also make the right organizational decisions. This is especially true if, like most enterprises, the teams responsible for the app are coming from a desktop or web development background.

It’s often said that a good software developer is worth 10 mediocre ones, and in mobile, that gap can be wider. “With mobile, you have to take staffing even more seriously,” says Loper. “Good mobile developers are in high demand, and both recruiting and retention can be a challenge.” He suggests that one of the best ways an enterprise can ramp up strong mobile developers is by carefully selecting and cross-training internal resources. “Most enterprises out there have excellent Java, C, or .NET developers who know the business and technologies well, but may have grown bored and do not feel challenged — mobile may and re-engage and retain them.” That said, you still probably want at least one experienced in- house or external mobile developer leading your team for the year or so it will take for your cross-trained staff to ramp up.

A final caveat for cross-training web or desktop developers is, again, making sure they give enough respect and ample consideration to their new medium. The more experienced they are, the stronger inclination they will have to assume they already know the answers to questions about functionality, form factor, flow design, and architecture. “With mobile, when you stop to ask the same questions, you get different answers,” Loper reminds us. Err on the side of lightweight, single-focus apps; make sure you’re using experienced in-house or contracted mobile flow designers; and make sure all other critical questions are getting asked at every step from requirements through test.

Another critical decision you’ll often make as a manager of a mobile team is determining and standardizing the appropriate development environments. In addition to the preferred native development tools of Eclipse (for Android) and Xcode (for iOS), most of the aforementioned toolkit providers also offer desktop or cloud-based IDEs. Managers should budget a good amount of time researching and comparing the available tools and consulting with their developers on which to standardize on. Loper cautions against leaving this decision solely in the hands of your developers: “Shoving tools down developer throats will always fail, but when you leave the decision entirely up to them, they often lean too far toward the bleeding edge which may cause headaches for the whole team.” If you have developers who feel strongly about an environment or toolset you didn’t choose, it’s important to make sure they at least know you heard them and that they understand your final decision and why it was made.

Mobile development itself presents a whole new set of challenges that you and your team may have not encountered before, and layering cross-platform design on top of that can be the straw that breaks the camel’s back. Although cross-development toolkits are viable for use today, they have a set of constraints around them that could result in disaster if the risks they involve are not completely understood and carefully considered.

If it’s a true, simple, single-focus mobile app you’re looking to build, cross-platform HTML5 tools could help immensely with getting something out the door, and it’s worth your time to evaluate them. Any serious mobile app built today should still have an end game plan of going native, and for a client-facing enterprise app that stands to get wide adoption, it probably makes much more sense to invest in the native app from the start. Using a development platform like Xamarin or Appcelerator in concert with or independent of MBaaS and remote services, your native app can still achieve the promises of cross-platform app development while avoiding nearly all the pitfalls.

Across the board, cross-platform mobile tools and methodologies are both viable and growing rapidly in number. Although HTML5’s current restrictions and risks limit use cases, the cross-compile space has only a few vendors, and network speed may limit usage of a MBaaS or remote service, both the tools and the environments are evolving very quickly and warrant our constant review and reconsideration.

11 Key takeaways

  • Although cross-platform mobile app development is still high risk, the tools and methodologies can be considered for a number of use cases today.
  • Four of the most appealing paths to cross-platform app design are: server-side web apps, hybrid apps (such as those built with PhoneGap or Titanium), cross-compiled apps (such as those built with Xamarin), and apps that leverage custom in-house or third-party remote services such as MBaaS. The first two types offer ways to develop apps with HTML5, JavaScript, and CSS; the third offers a way to build native apps using a familiar industry-standard language like C#; and the fourth offers a way to offload some heavy lifting from the app to beefier, more-scalable remote servers.
  • If you have the ability to write in C#, the Xamarin tools can provide over 70 percent code reuse across platforms with native performance and none of the limitations and risks of HTML5, JavaScript, and CSS.
  • For a mobile application of any complexity, going straight native is still generally the fastest, most-efficient, and least risky way to deliver. If the application is simple (and true mobile apps should be) and end users can tolerate a less familiar UI, an iterative development approach using HTML5 hybrid tools like PhoneGap or Titanium can offer significant speed to market and prove and tune a concept before investing more deeply in native versions.
  • Regardless of how you deliver your app, investigate if custom or third-party MBaaS services can be used to push some functionality out to remote servers.
  • In addition to the unique user expectations and technology-stack challenges of mobile, managers of a mobile team must also pay extra attention to staffing, education, tools, and environments.

12 About Rich Morrow

Rich Morrow is a 20-year open-source technology veteran who enjoys writing code as much as he does teaching. His current passions are cloud technologies (mainly AWS and OpenStack) and big data (Hadoop and NoSQL), and he spends about half of his work life traveling around the country training other technologists and business leaders on their use. He leads the Denver-Boulder Cloud Computing group, as well as quicloud, a Boulder, Colo.–based cloud and big data consultancy.

13 About GigaOM Research

GigaOM Research gives you insider access to expert industry insights on emerging markets. Focused on delivering highly relevant and timely research to the people who need it most, our analysis, reports, and original research come from the most respected voices in the industry. Whether you’re beginning to learn about a new market or are an industry insider, GigaOM Research addresses the need for relevant, illuminating insights into the industry’s most dynamic markets.

Visit us at: pro.gigaom.com.

14 Copyright

© Knowingly, Inc. 2013. "The cross-platform mobile app: advice for enterprise developers" is a trademark of Knowingly, Inc. For permission to reproduce this report, please contact sales@gigaom.com.

Tags