Web vs Native

by Graham Hinchly

… How technology has shaped the FT’s digital strategy

Native apps, Web apps, HTML5, responsive design — the media industry’s transition from print to digital is full of terminology and technical choices. The engineering manager at FT Labs, an emerging Web technologies division of the Financial Times, explains the pros and cons of each and how FT has found its way.

With kind permission from inma.org,
where this article was originally published
on 20th January 2014

The Financial Times’ award-winning Web app shook up the news industry when it was launched 2011, quickly becoming a case study for the benefits of distributing content solely using the Web, rather than relying on native apps.

But for many, the “Web vs. native” debate is still opaque, due to the technical jargon and acronyms that surround it. By demystifying some of the concepts for a non-technical audience, and outlining the advantages and disadvantages to both native and Web apps in an impartial manner, I hope to enable more publishers to make informed decisions when it comes to evaluating, or re-evaluating, their approach to delivering a great user experience on all devices.

I’d also like to share some of the things we’ve learned from building a Web app at the FT, as well as a few thoughts on how I’m expecting publishers’ approaches to content distribution to evolve over the next few years.

Native apps

As a trip to a local technology outlet will show you, there are many makes and models of smartphones available and an increasingly large number of tablet devices.

The common ground for a lot of these devices is the operating system that they run, with the majority either running Google’s Android operating system or Apple’s iOS, the operating system for iPhones and iPads. Between them, these two operating systems comprise more than 90% of the smartphones and tablets currently in use (Source: netmarketshare.com, Dec 2013).

The term “native app” refers to an app that has been built specifically for one of these operating systems, using the specific programming language of that platform, meaning that you can’t re-use an app written for one operating system on another. The apps are generally distributed through app “stores,” such as the Apple iTunes store for iOS or the Google Play store for Android.

Web apps

A Web app is often defined as a Web site that mimics a native app — giving a great user experience by doing things such as formatting content to suit the screen size of the device, navigating almost instantly between links, working without an Internet connection and being able to swipe through to content.

Web apps are accessed through a Web browser (providing it supports the required functionality) and as such can potentially be used on any smartphone or tablet. On iPhones and iPads, you can also add Web apps to the home screen, giving a bookmark icon, and also allowing the Web app to run full screen, just like a native app.

Web apps are built using the technologies that have been used to build Web sites for many years, now often referred to with the catch-all term “HTML,” but actually comprising HTML, CSS, and Javascript.

The latest evolution of these technologies (generally referred to as “HTML5”) and the development of modern Web browsers have given developers the ability to develop an “app-like” experience.

Is there a middle ground between Web and native apps?

There is also a middle ground between a Web app and a native app, where you can augment an app built on Web technologies with some native technology and distribute through an app store. This is often referred to as a “hybrid” app and can give the best of both worlds.

At the Financial Times, we use this method to support the Android operating system — the core app is the same HTML5-based app that is used for iPhone/iPad — but we then use native functionality to add features Web apps can’t currently offer, such as background downloads of new content.

Responsive design’s application to native and Web apps

When discussing Web site and app development, one term often used (and mis-used) is “responsive design,” so it’s worth taking a moment to clarify this term.

Responsive design is a design approach, rather than a particular technology, and applies equally to Web apps, hybrids, native apps, and Web sites. The primary consideration of responsive design is designing and building an app or Web site so it gives a good user experience regardless of screen size and/or orientation.

This can mean reducing the number of columns of text as the screen size shrinks, reducing font size, or resizing or hiding images (you can see how the FT Web App responds by going to app.ft.com in an up-to-date version of Google Chrome and resizing the browser window).

Differences between native and Web apps

Although the challenges of responsive design are similar for native and Web apps, there are a number of areas where there are currently quite distinct differences:

• Discoverability and monetisation
• Discoverability: In addition to going directly to Web apps via their URL, they can be linked to from search, adverts, or social networks, all of which take a user directly into the app. These methods can only link to the install page of native apps, meaning a user still needs to download and install the app. Native apps can also be discovered through the app store for that platform, either through search or promotion within the store.
• Customer relationship: Web apps offer a direct relationship with customers, whereas native apps require the app store operator to act as an intermediary, limiting the relationship you can build with a customer.
• Revenue sharing: Payments for content consumed through native apps are subject to revenue sharing with the store from which the app was downloaded, with typically 30% going to the store operator. Although Web apps bring the cost of processing payments, this is much lower than the store operator’s share, and companies are not constrained to dealing with a single monopoly supplier.
• Payments: Native apps can generally offer one-tap payments, but are restricted to using a single payment method. Although Web apps still require users to input credit card details, they can offer multiple payment methods, such as Paypal, and new technology should bring one-tap payments within reach this year.
• Functionality and performance
• Performance: For content-based apps on modern devices, performance differences between Web and native apps are now negligible, meaning scrolling, swiping, and responsiveness can sufficiently meet performance needs regardless the approach taken.
• Access to device functionality: Native apps have access to more device functionality than Web apps, for example, background downloads and push notifications.
• Search, sharing, bookmarking: The Web already has very well-established methods for search, sharing, and bookmarking. Currently on the Web, these methods are superior to those of native apps. You can’t, for example, bookmark content across multiple apps or share the “app” version of an article (a link to a Web site is shared instead).
• Development
• Development/testing overhead: Because a single Web app supports multiple operating systems, development and test overhead can be significantly reduced vs. developing and testing multiple native apps.
• Approval process: Certain stores, such as Apple’s iTunes store, require native apps to comply with a set of regulations and to submit to manual review of any new or updated apps. Web apps are not subject to this approval process, giving greater flexibility to release instantly and perform A/B testing. Not being reliant on an app store also removes the possibility that there will be a change of regulations that have a negative business impact.

The number of differences means publishers should carefully consider which approach to take, as there is not a clear “one-size-fits-all” winner. Other important considerations are:

• Availability and cost of staff with required skills.
• Current strengths, knowledge, and resources within the organisation.

Reflections on building and maintaining the FT Web app

Clearly at the FT, we decided that the advantages of a Web app outweighed the advantages of a native app, and we still believe this is the case.

The Web app is a key part of our strategy, and we invested significantly in it in 2013, fundamentally re-architecting and re-designing the app to give us a product that we can continue to innovate and build on.

For me, two lessons stand out, which I think are applicable to any news or media organisation, regardless of size.

Firstly, the success of the Web app has proved to be a vital component in moving the FT to a “mobile-first” approach (although this journey is not yet complete). Encouraging people throughout the organisation to participate in trials of new versions of the Web app has been a particular success for us, engaging a much wider variety of people with mobile and digital.

Whether you’re at a point where you’re advocating “digital-first” or “mobile-first” in your organisation, it’s important that someone is responsible for advocating this throughout the organisation. Developing an innovative product in-house makes this job much easier.

Secondly, the Web app has always been seen in the context of a coherent portfolio of digital products, which is the result of having a holistic, long-term strategy. A key part of this is “loose coupling,” meaning if the requirements for part of the system change, we can easily swap in an alternative.

For content driven-apps, developing a robust “API,” or application programming interface, that supports multiple channels (such as Web sites, apps, and third parties) to expose your content is essential.

Predictions for 2014 and beyond

With the pace of change in the industry, it’s difficult to predict where we’re going to be in 12 months time, never mind beyond that. But I expect both Web apps and native apps to have a fundamental role to play in the long term, with the already blurred lines between Web apps and Web sites further blurring to the point where there is no longer a distinction between the two.

At this point, users will be more accustomed to expecting “app-like” functionality as standard from Web sites, whether they are on a mobile device or not.

In the media in particular, an increased focus on cost rationalisation and the fundamental requirement to operate a Web site will prompt a gradual shift in investment away from native apps towards HTML5-based hybrid apps distributed through Apple’s iTunes or Google Play.

This, then, avoids having multiple siloed development teams with different skill sets or having to rely on external agencies. With a purely Web-based technology team, management overheads are reduced, recruitment is easier, and synergies between development teams are easier to realise.

Although I don’t expect to see many publishers remove their apps from app stores in the near future, I expect to see more investment in Web apps (or extending parts of their existing Web sites to offer more “app-like” behaviour), to avoid being beholden to a particular app store operator. This mitigates the risk of changes to app stores and their regulations, which may have a significant business impact.

Conclusion

As users increasingly move to mobile and tablet devices instead of desktop computers, delivering a great user experience on smartphones and tablets is essential, and as such, adopting a “mobile-first” strategy seems to be more critical than ever.

Both native apps and Web apps can be appropriate for almost any organisation, but this decision should be taken as part of a holistic digital product strategy.