Mfuse - The Native vs HTML5 Debate - Whitepaper - Nov 12

The Native

vs HTML5

Debate

and its implications

for mobile sports

betting applications

A Whitepaper

Mfuse Limited

Copyright © November 2012, Mfuse Limited Page 1

Contents Executive Summary ...................................................................................................................... 2 Native Applications ...................................................................................................................... 3 Native Applications – Pros & Cons ........................................................................... 3 Browser-Based Web Applications (HTML5 as part of Webkit) ........................................... 6 Browser-Based Apps Pros and Cons......................................................................... 6 The HTML5 ‘Write Once – Run Anywhere’ Myth: .................................................................. 8 A Review of the Key HTML5 Supported Features Across Browsers ................................. 10 Conclusions for Sports Betting Applications ........................................................................ 15


Executive Summary There is still much debate within the sports betting and gaming industries as to the best approach for building mobile and tablet betting applications. For many, this issue centres largely on the debate between developing mobile applications as browser-based web solutions (most commonly using the latest HTML5 technology), or building operating-system-specific ‘Native’ applications that are downloaded to and run directly from the device. At a basic level this debate can be framed as a decision between the greater speed and lower cost of development of mobile web solutions, and the additional functionality and application speeds available via Native apps. The issue is a complex one however and operators have to understand and decide on a myriad of issues, options and available functionality when weighing up these possible approaches. This whitepaper examines these two different approaches, highlights the pro and cons of each, looks at possible hybrid solutions and then finally considers casino and other games before drawing its conclusions.


Native Applications A ‘Native’ mobile/tablet application is a device and operating system (OS) specific program that is able to directly take advantage of the device’s memory and processors (CPU and GPU) as well as other capabilities including the camera, geo-location, address books, calendars, in-app messaging, animation, iCloud storage, Newsstand, Twitter etc. There are currently several thousand APIs available for developers to utilise. This means that everything should run faster and more smoothly and all these data feeds and functionality should potentially make for a much richer user experience. Native Applications – Pros & Cons 1. Performance: As described above a Native application gives the developer direct access to the phone’s processors which ensures that the maximum performance can be achieved. Performance in terms of both rendering and loading times are faster in Native and this is important with end user tolerances getting increasingly lower. However Native applications that require information to be retrieved over the network from a server (as is the case for betting applications) are unlikely to be seen as much faster for an end user with server call/response times being the limiting factor. The performance gap is only really likely to be evident when trying to access and integrate with other handset features (such as the calendar for instance) but this sort of functionality has not been a key aspects of current betting apps thus far. 2. Functionality: Native applications have access to a large number of APIs which enables functionality and an enhanced user experience not possible on browser-based solutions. The question is whether any of these features justify the additional costs of building in Native. With respect to betting applications it is difficult to argue that there are currently any ’killer’ features that justify the investment. However, Siri1 integration would probably be the feature that would convince many, if and when this becomes available. 1 iOS voice-controlled ‘assistant’ system. See http://www.apple.com/uk/ios/siri/ or http://en.wikipedia.org/wiki/Siri_(software) for more info


3. App Store Discoverability: The various app store markets have been considered by some to be a cheap way to market products to a large audience - and there has been much hype about their success. The reality though is that there have been a few big winners but now the ’find-ability‘ of apps is becoming increasingly difficult. How many users actually browse app stores for things to download is questionable. Big brands will likely have the user base that will look for their apps directly in app stores but smaller companies would need to rely on tagging their apps against more common search terms and hoping to appear high up in the results. With hundreds of thousands of Native apps in app stores this is becoming challenging. As a result most developers will find they need to market awareness for the app elsewhere and then drive users to the store specifically to find their app, although undoubtedly some new user acquisition will be achieved through just being in the stores. Of course Google have made the decision not to allow gaming applications in their store which limits that decision. Note that it is still possible to get a Native betting application onto an Android handset through a secondary app store like GetJar2 for example or as a direct download. However, these requires the user to set an option in their phone settings to allow them to download apps that aren’t from the Google Play store with resulting privacy and security concerns. 4. Cost: Native applications need to be written for every single device and every new platform from scratch and they require more specialised developer knowledge which means there are fewer available developers and the ones that are there are likely to be more expensive. Given how large betting applications need to be, with hundreds of thousands of markets and multiple bet types, the cost of building Natively for even one handset type is significant and needs to be weighed up against the additional features, functionality and performance that can be achieved. Even if you are deciding just to build Natively for Apple you will still have to consider writing separate implementations for both the iPad and iPhone due to the very large difference in screen sizes. 2 See http://www.getjar.com


5. Submitting Updates: Developers of Native apps need to manually submit each of their apps to each of the app stores (and often to each jurisdiction as well) which is both time consuming and reliant on the app store approval processes and timescales. Each upgrade of the product requires resubmission and the user to then go in and update their application.


Browser-Based Web Applications (HTML5 as part of Webkit) During the past few years there has been an explosion in browser-based platform technologies and chief among these is the “Webkit” standard. 3 This browser-based technology for rendering pages defines the standards for HTML5, CSS3, animation, manifest caching, flexible layouts and canvases to name just a few. These features were either born from the Webkit base or were matured and driven by the development of the Webkit based browser standards. They have been adopted by Apple and Google as well as by RIM’s Blackberry to a lesser extent. To help developers write for these new browser-based technologies various web frameworks have sprung up such as jQuery4 or Ruby On Rails5 which have allowed Web Apps to come to life. Browser-Based Apps Pros and Cons 1. Write Once Deploy Everywhere: In Theory HTML5 has the potential to enable developers to write once and deploy everywhere. HTML5 runs in browsers on mobiles, tablets and desktops and can also be converted to a Native application or built inside a Native wrapper. We will examine later in this document just how close we are to this ‘write once’ nirvana – especially in relation to sports betting mobile and tablet applications. 2. Share over the web: HTML5 services are accessed from within a browser using a URL and can be shared over the web and found when using web search engines. The end user doesn’t need to go to a market place and download the product, they simply type in the URL and access the service – a familiar process to every PC user. 3. Multi-Vendor standards: HTML5 is a group effort not a single vendor specification which should ensure that it remains focused on developer and end user needs rather than in any vested commercial interests. 4. Millions of Developers: HTML5 and other web technologies are familiar with millions of developers and so 3 See http://www.webkit.org/ or http://en.wikipedia.org/wiki/WebKit 4 See http://www.jquery.com or http://en.wikipedia.org/wiki/JQuery 5 See http://rubyonrails.org/ or http://en.wikipedia.org/wiki/Ruby_on_Rails


it is easier to grow out a development team and at a lower cost than would be possible with the more specialised and rarer Native developers. 5. Upgrades Without a New Download: HTML5 downloads the data and screens as it is needed so changes can be made in the back office without the need for an update requiring the user to go through another download process. It also means that updates are not reliant on or delayed by approvals from the likes of Apple. 6. Responsive Product Adaptation: It is possible to code a browser-based application so that it uses responsive design to automatically scale to fit the environment in which it is operating without having to change the code or the assets. This clearly helps reduce the amount of time it takes to develop browser apps across handsets and lets the developers focus on the larger areas of difference between browser releases. 7. Offline Storage: Storage of content offline in an HTML5 application is available. A developer can choose to store the application itself, images and other data which means that offline access and usage is possible. However, this is naturally less relevant for a betting application which requires live market and pricing information. 8. Limited APIs: Despite the progress that has been made in recent years, browser-based applications still have very limited APIs when compared to Native applications. For example there is still very limited or no access to the camera, the address book, vibration, the phone or text messages and notifications etc. Mozilla and a few others have created a set of APIs to start to define access to these called WEBAPIs which will be rolled out in devices soon. Therefore, it could be argued that browsers are starting to catch up with some of the “need to have” requirements that have been in Native applications for a few years now. 9. Performance: HTML5 performance is usually worse than Native apps as both iOS and Android devices limit browser access to parts of the mobile hardware that allow peak performance. However as discussed in the Native pros and cons the extent of performance loss will depend on the type of application. Thus, for betting applications that require information to be passed over the networks, any performance loss is likely to be minimal.


The HTML5 ‘Write Once – Run Anywhere’ Myth: It is very often cited that HTML5 allows a developer to write once and for that application to run anywhere. That is a powerful and tempting claim to say the least and to answer whether such an ideal exists we need to first consider the sheer scale of the fragmentation of handsets, operating systems and browser variations. Starting with Apple we have the iPhone 3 to 5, iPad 3 to 5, the iPad mini, various iPods and operating systems from 3 to 6. Each later version of device has improved CPUs and memory and there are numerous screen variations as well, including later retina displays . Each later iOS version has given access to new features and functionality. Some older handsets cannot be upgraded to later operating systems. Looking at Android things are considerably worse with 20+ implementations of the Google operating system by multiple manufacturers and with 2.2, 2.3, 2.4, 3.0 and 4.0 all having significant differences between them. The problem this causes app developers is extensive and well documented. There are then Windows phones, Blackberry devices and the new tablet devices by major PC and mobile manufacturers as well as Google, Microsoft and Amazon – all being released as quickly as possible. Coming onto browsers we have Apple’s own Safari browser, Google’s Chrome, Microsoft’s Internet Explorer, Mozilla’s Firefox and Opera, and there are many different versions of each of these browsers with varying levels of support for key functions. Further it is clear that the pace of change in browsers is increasing. With this large fragmentation of browsers, handsets and operating systems can the write once run anywhere claim really be true? The simple answer is no. Unless that is you are building to the lowest common denominator which realistically would only be simple text-based static web pages. For pretty much everything else development teams are required to implement a number of versions of their web applications which can very quickly start to eliminate the cost-benefit argument over multi-platform Native deployments. How much additional cost is required will depend on how much of the core application can work across most handsets and how the changes that are required can be served up without affecting the core code base. This requires efficient and clever technical architecture and also means that the


developer needs a robust and reliable way to identify the handset, operating system and browser - and then be able to serve up the relevant solution. It also requires up front thought from product teams to design screens and user journeys that have multiple options based on the capabilities of the handsets and browsers being used. Thus, even with clever product design and technical architecture, support for older handsets and operating systems (c 3-4 years old) will need to be removed, as the pace of change is just too great and the lowest common denominator with these handsets is far too limiting as a base.


A Review of the Key HTML5 Supported Features Across Browsers To see what is possible and where we need to make product choices we need to examine some of the key pieces of functionality that various handsets and browsers support. For the purpose of this review we will consider the following variations: • Safari on iOS for iPhone and iPad running 3.2 to 6.0 • Androids browser on Phones and Tablets running 1.5 to 4.1 • Google chrome on android 4.0+ • Amazon Silk on the Kindle Fire tablet running 1.0 to 2.0 • Blackberry’s browser running on phones with operating systems 5.0 to 7.0 and on Tablets running 1.0 to 2.1 Application Cache: This enables storage of images and javascript locally on the handset which reduces calls to the servers for various animations and actions, and lowers bandwidth requirements for images which can significantly slow down page loading times. This is only not supported below Android 2.1 and below Blackberry 6.0. WebStorage: This is another form of local caching on the handset and allows aspects such as remembering the page the user was on or what was in their betslip. This is only not supported below Android 2.0. Geolocation: Allows access to information on where the user is which is important for restricting access to certain jurisdictions but also enables personalisation based on where the user is so that for instance if the user is at or near a football ground when a match is being played that market can be promoted to their homescreen. This is not supported below Android 2.0, below Amazon Silk 2.0 and below Blackberry phones 6.0. Multimedia: Allows access to the phone’s video and audio players and is obviously required for displaying live sports feeds and also for offering commentaries. It also has relevance for games audio elements. Multimedia is not supported below Android 2.3 or below Blackberry 7.0. Webworkers: This is a very useful piece of functionality allowing multiple activities (threads) to be conducted at the same time. This means the user does not have to wait for a response from a server to confirm that his bet has been placed before returning to a page and looking for his next bet. Support for webworkers is not available below iOS 5.0, below Amazon Silk 2.0 or below Blackberry 6.0.


Canvas API: Allows 2d drawing and is relevant for games developers as it covers animation and interactive layers enabling HTML5 games to look like Native games. For instance angry birds can be played within a browser quite comfortably with this support and there are no browsers/operating systems in this review that do not support the Canvas API. SVG: This means ‘scalable vector graphics’ and without getting into technicalities is a very useful tool for games developers. It is not supported below Android 3.0 and not at all on Amazon Silk which can be problematic for building in certain animations that are typical, for example, in slot games. Motion Sensors: These include the accelerometer, gyroscope and magnetometer and for the betting industry its main use is to sense and switch between landscape and portrait mode. However, this is not available below 4.2 on iOS, 3.0 on Android, 2.0 on Amazon silk, is only partially supported on Google Chrome and there is no support on Blackberry phones at all. Virtual Keyboards: Enables the developer to offer different virtual keyboard for different requirements so that when a phone number is being entered for example, the phone keypad is offered rather than the default keyboard. Whilst this may be considered a ‘nice-to-have’ by many it is one of the examples of attention to detail and user experience that Native applications really benefit from. Android does not support virtual keyboards below 4.0. CSS3 Basic: Enables opacity, backgrounds, text effects and rounded corners to be applied and is supported in all but Blackberry 5.0. CSS3 Transforms 2d: Enables 2d animations including rotate, translate, scale, skew and matrix and is used for loading icons among other things. Support is only limited to Blackberry 5.0 and below Android 2.0. CSS3 Transforms 3d: Enables more advanced scrolling both horizontally and vertically. Support is lacking below Android 3.0 which is significant, and there is no support at all on Blackberry phones or the Kindle Fire. CSS3 Animations: Is important for building concertina menus and carousels but there is no support on Amazon Silk, below Android 2.0 or below Blackberry 6.0. Note also that supporting multiple carousels has problems with memory access on Androids and earlier iOS devices.


Fixed Position Support: This is required to be able to fix headers and footers and is one of the key features that makes users feel that they are using an app rather than a web page. Not supported below iOS 5.0 (although web clipping the URL then gives access to this feature on earlier versions), below Android 2.2, on Amazon Silk or below Blackberry 7.0. Network Information: Enables connection types to be identified such as 2G, 3G, 4G or WiFi and a different version served up or offered as an option to users on lower bandwidth connections. This is particularly relevant to the betting industry and users at large sports venues who are competing with tens of thousands of other individuals for data bandwidth. Most web apps have enough features, functionality and graphics to render them useless in these low bandwidth environments and so offering a lower level text-only solution perhaps with simple single bets only might be highly desirable. This information is not available below Android 2.2 or on Blackberry phones at all. HTML Media Capture: Enables access to the camera for taking pictures or recording video and audio. It would allow augmented reality functionality such as taking a picture of a football match on the television and being shown the latest odds for that game. This is currently only partly supported in iOS 6.0+, on Android 3.0+ and Google Chrome. Web Audio: Would allow the user to stream live commentary whilst still navigating through the rest of the application to place bets or see other information. It is only supported in iOS 6.0+, Google Chrome and Amazon Silk 2.0+ Notifications: Is a very useful feature of Native apps which allows an app that is closed to notify the user of a change, update, or promotion, or anything else that may be useful. This is only supported in Amazon Silk 2.0+ and Blackberry Tablet 2.0+ which is nothing useful. At the current time this functionality in HTML5 can only be supported when the app is open.


Solving Browser Incompatibilities As indicated above, with some clever product design and technical architecture it is possible to create a base application with functionality supported across most handsets/operating systems and with additional functionality served up for those devices that have additional APIs and support available. Mfuse has spent many years developing its Mobile Application Development Platform (MADP) to do just this and it is this platform that enables us to develop applications quickly across devices with premium variants offered on the top handsets. A separate Mfuse whitepaper is available that explains in more detail the technology behind this MADP and how it significantly increases our developer efficiency and time to market when developing our clients’ apps. Other Solutions Web clip: Specific to Apple devices the user is able to choose to “clip” their browser application to their home pages, creating an icon as they would have for a downloaded application. The web clip mode gives access to some more Native features in the handset and thus it is possible to create an application that looks and feels far more Native than possible within a browser. Many developers (including Mfuse) recommend this solution and always prompt the user to clip the application to their home page when first accessing the service. Native Wrappers: It is also possible to take a browser-based HTML solution and to package it up inside a ‘Native wrapper‘. This Native wrapper is typically just code for the header and footer part of the application with everything else served over the web. This has the advantage of providing an application that is available in Apple’s marketplace for discovery and downloads without having to build a completely new Native version of the application. It also means that some additional features and functionality available to Native applications can be added into the product as required. Mfuse creates Native wrappers for all its web application solutions. Adding Casino and Other Games: Firstly we should consider that for Casino games the download vs. browser argument has already played itself out in the last 10 years on desktops. Online Casino games were only available as download products in the early years but as browser technology improved users tended to find the convenience of being able to navigate to games from within their browsers. Games have been available in browser form for a while although until recently the


technology used for graphics capability was Flash/Shockwave and only Android supported this. With the release of Adobe’s Edge Animate software (basically flash re-written in to a full system that allows the flash designer or programmer to transition to the HTML5, CSS3 and JavaScript platforms) the possibility for the games developer across browsers/handsets has improved. It is now possible to create rich high-quality animated games on some of the more recent browsers that have all the visual power of the Native and flash-based apps but in a format that runs on any desktop, mobile and tablet device from day one. Given users have proven on desktop that they prefer to access and move between games in this way a betting company choosing to build games (or take games from a supplier) can now legitimately choose a browser-based solution which makes integration into browser-based betting applications also possible.


Conclusions for Sports Betting Applications There is no doubt that if you want to have the fastest app, with all the very latest user interfaces, features and functionality that you have to build a Native application. However the cost of doing so in both time and money is significant and requires different technical skills. Arguably Native applications do not currently have a killer feature that means that a Native application has to be built although it is our view at Mfuse that SIRI integration when this is available would easily justify the additional cost. So for now building Native wrappers that have limited additional functionality but allow a browser-based solution to be packaged up for distribution in the app store is the sensible half way house and we continue to recommend that solution to our clients. Web applications, once they start to utilise some of the more interesting graphical features and user interactions have elements that can be written once and deployed across most devices with more advanced features served up only to those devices that can handle them. The Mfuse MADP solves the majority of the problems in building browser applications in this way enabling faster time to market and less developer days. Utilising web applications, web clipping on Apple and packaging up Native wrappers, Mfuse is able to offer the best products across the widest range of Smartphones in the market. Mfuse are more than happy to discuss these issues and their solutions in further detail. Please do contact us for more information or for a free review of your mobile betting solution. Mfuse Limited www: www.mfuse.com 3rd Floor, Mitre House tel: +44 (0)20 7154 2070 177 Regent Street email: [email protected] London W1B 4JN

Mfuse - The Native vs HTML5 Debate - Whitepaper - Nov 12

Technology

Transcript of Mfuse - The Native vs HTML5 Debate - Whitepaper - Nov 12