Mfuse - Native vs HTML5 - Whitepaper - Nov12

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: info@mfuse.com
London W1B 4JN

Mfuse - Native vs HTML5 - Whitepaper - Nov12

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Mfuse - Native vs HTML5 - Whitepaper - Nov12 (20)

More from Paul Galbraith (10)

Mfuse - Native vs HTML5 - Whitepaper - Nov12