By Stephen Reeder
In more industries, single function physical products are supplanted by general purpose hardware running a multitude of software delivered services. Performance of the software applications (apps) used to deliver these services is central to the experience that customers receive. TV is a good example—connected services such as Netflix may use the consumer’s own hardware, but it is the app experience they remember. Additionally, consumers often have multiple devices, and want a consistent, high-quality app experience across all of them. Adding to the equation, the separation of a hardware purchase from that of the app or service has considerably lowered the cost of switching to a different service provider. It is therefore clear that software performance can have a huge impact on consumer retention, which directly drives revenues and company success.
A 2015 Huffington Post blog, 50 Important Customer Experience Stats for Business Leaders, also gives a warning to those tempted to overlook customer satisfaction as they strive for growth. 91 percent of unhappy customers don’t complain to the service provider, they just leave. They don’t go quietly though—whilst a happy customer will share their experiences with six or more people, an unhappy customer will tell at least 15 others of their bad experience.
Delivering Multi-Platform Performance
Achieving the good software app performance that customers expect isn’t straightforward, particularly given the number of platforms that software has to run on. This is partly due to the way that apps are authored. To minimize development costs and achieve platform diversity, many apps are written in HTML as Single Page Applications (SPAs) rather than authoring them in native code. Using HTML avoids the need to create individual apps for each platform and is invisible to the consumer as the app seamlessly launches the browser each time it is run. This means the toolbar is never visible and no URL ever needs to be entered. SPA developers have a choice of either using the device’s built-in browser or combining a different browser engine into their app during its development.
While being a massive benefit in multi-platform application development, a key issue with HTML-based SPAs is that they generally require more processing power than native apps. Today’s smartphones, tablets, and TVs all use multi-core silicon where a number of smaller processors are combined to deliver increased processing capabilities with minimal power consumption. Reduced power consumption is achieved because each individual core runs at a slower speed. So, to gain the benefits of the increased processing performance, software execution should be evenly distributed across all the cores.
Software written for single-core processors doesn’t automatically benefit from the capabilities of multi-core silicon. Traditional HTML browsers—including those built into operating systems like Android and iOS—have some multi-threaded capabilities they are unable to harness the combined processing capabilities of multi-core silicon to improve SPA rendering performance. Statistics show that on a typical quad-core consumer electronics processor, a traditional browser fails to benefit from nearly 75 precent of the available CPU performance. For service providers this issue means underperforming apps, frustrated customers, and greater churn.
Meeting Rising Customer Expectations
To best meet customer needs, the service provider is faced with a choice between one of the following app strategies. First, decrease the capabilities of the SPAs to ensure that apps perform well, even on lower powered platforms. In some cases this could mean managing multiple classes of SPAs with different functionality dependent upon platform capability. Second, move to creating multi-core native apps, adding to development time, costs, and maintenance requirements. Or finally, adopt new methods that make SPAs faster, more memory efficient, and able to benefit from multi-core processors, retaining a single codebase that performs effectively across all target platforms.
Of the three strategies, the last is ideal as it avoids the development cost and complexity of managing multiple SPAs or creating multiple native apps. Achieving it involves embracing a new browser architecture which focuses upon the capabilities of consumer electronics silicon and utilises new techniques to get the best performance from it. For example, our own multi-core ready HTML browser, called Flow, uses this approach and is typically around twice the speed of a traditional browser. The good news for the development community is that swapping the underlying browser doesn’t mean rewriting any application code as the higher level HTML requires no modification.
We live in an ‘app economy’ where performance is central to customer experience, retention, and revenues. Demonstrating this, a 2017 study by AppDynamics showed that, for 73 percent of users, application performance impacts their view of the service provider.
Meeting these needs brings multiple challenges for developers, particularly when it comes to multi-core silicon. Therefore, it is recommended that now is a good time for service providers—and their developers—to take a step back, re-evaluate their app development strategy, and browser partner selection criteria to ensure their approach is in line with the capabilities of modern silicon. After all, getting this right enables focus to return to the important business matters of creating high-performance, cross-platform apps that deliver the responsiveness consumers demand which in turn boosts loyalty, drives long-term relationships, and helps deliver a healthy bottom line. SW
Stephen Reeder is Ekioh’s commercial director. He has commercial and technical experience having spent over 30 years in the cable, IPTV, and telecoms industries. Stephen has an MBA from London Business School and a BSc in Electronic Systems Engineering from UEA.
Jan2019, Software Magazine
