Xamarin PhoneGap Ebook

EBOOK
//// XAMARIN AND

PHONE GAP
A Comparison of Two Approaches to

Cross-Platform Mobile Development
Introduction
Todays mobile landscape is fragmented like never before. In the
consumer space, the sheer number of mobile devices and their
operating system variantsnot to mention constant innovation
and new product introductionsis a huge challenge for the
enterprise on all platforms. The rise of Bring Your Own Device
(BYOD) and consumer-grade experience expectations within
enterprises also pose difficult questions.
Brad Dean
Kevin Ford
Ken Ross
/////
XAMARIN AND PHONE GAP: A COMPARISON
TABLE OF CONTENTS
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Compile Time . . . . . . . . . . . . . . . . . . . . . . 15
About Xamarin . . . . . . . . . . . . . . . . . . . . . . . 5
About PhoneGap. . . . . . . . . . . . . . . . . . . . . . 5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Methodology. . . . . . . . . . . . . . . . . . . . . . . 6
A note about performance testing . . . . . . 6
Developer Experience . . . . . . . . . . . . . . . 7
Languages Used . . . . . . . . . . . . . . . . . . . . . . 7
Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Access to Native Functionality & APIs.16

Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . .
PhoneGap Windows App Support. . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .
Developer Ecosystem. . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16
17
17
17
18
Performance Metrics. . . . . . . . . . . . . . . 18
Code Reuse. . . . . . . . . . . . . . . . . . . . . . . . 8
Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Code Reuse Caveats. . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
9
9
Developer Tooling . . . . . . . . . . . . . . . . . . 10
Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
UI Development. . . . . . . . . . . . . . . . . . . . 11
Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Long Term Maintenance. . . . . . . . . . . . . 12

Ecosystem Stability. . . . . . . . . . . . . . . . . . .
Code Maintenance . . . . . . . . . . . . . . . . . . .
Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
14
Code Organization. . . . . . . . . . . . . . . . . . 14
Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
PhoneGap. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
i // MAGENIC
App Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Start Time . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Display Long List . . . . . . . . . . . . . . . . . . . . . 19
Memory Usage. . . . . . . . . . . . . . . . . . . . . . .19
Performance Summary. . . . . . . . . . . . . . . 20
CPU Intensive Tasks. . . . . . . . . . . . . . . . . . 20
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
User Experience Comparison. . . . . . . . 21

Differences in Technology. . . . . . . . . . . . . 21
Side-By-Side Comparison. . . . . . . . . . . . . 21
ANDROID. . . . . . . . . . . . . . . . . . . . . . . . . . .22
Login Screen
Xamarin/PhoneGap . . . . . . . . . . . . . . . . . . 22
Dashboard
Wait Indicator
Add Incident Picker
Worker Queue
Incident Detail
Context Menu

iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Login Screen
Dashboard
Wait Indicator
Add Incident Picker
Worker Queue
Incident Detail
Context Menu
Responsiveness. . . . . . . . . . . . . . . . . . . 35
Touching vs. Keyboard/Mouse. . . . . . . . . . .
Long Lists. . . . . . . . . . . . . . . . . . . . . . . . . . .
Page Transitions. . . . . . . . . . . . . . . . . . . . .
New Features. . . . . . . . . . . . . . . . . . . . . . . .

Compliance with Platform Design
Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .
35
36
36
37
37
37
Other Factors. . . . . . . . . . . . . . . . . . . . . . 37
Importance of Xamarin Build Settings. . 37
MDM Products. . . . . . . . . . . . . . . . . . . . . . . 38
Toolset Licensing Cost . . . . . . . . . . . . . 38

Licensing Costs. . . . . . . . . . . . . . . . . . . . . . 39
Other Licensing Considerations . . . . . . . 39
Third Party Libraries . . . . . . . . . . . . . . . . . 40
Application Updates . . . . . . . . . . . . . . . . 40
Summary. . . . . . . . . . . . . . . . . . . . . . . . 41
/////
When beginning new mobile product development or reevaluating existing mobile product
portfolios, a key strategic decision point is selecting the mobile development platform that
will best support realization of business objectives, as well as integrate with the enterprise
ecosystem. There is an ever-increasing variety of factors which must be considered, each
coming with advantages and tradeoffs, when evaluating competing mobile development
approaches, such as native, hybrid, or cross-platform development.
Committing to a mobile framework requires more than just considering the technology.
Factors include:
Innovating quickly and fully exploiting a mobile devices capabilities
Maintaining the codebase on a long-term basis
Re-usability of existing code and extension libraries
Developer knowledge of the framework and availability of talent
User experience and app performance
In this eBook, we will examine and compare two popular cross-platform mobile
development tools, Adobe PhoneGap and Xamarin Platform. Adobe PhoneGap, a hybrid
HTML solution, is the commercial version of Apaches open source Cordova project and uses
HTML5 and JavaScript for development. Xamarin Platform is a cross-platform development
tool that uses C# to develop mobile applications compiled to native binaries. We will explore
how these development technologies very different approaches to the cross-platform
challenge work well or leave room for improvement.
The basis for our comparison is an application we created for both the iOS and Android
smartphone ecosystems. It is an incident tracking application backed by Azure App Service,
Storage, and Azure Active Directory services. It contains features that would normally be
included in an enterprise-class application such as authentication, authorization, access to the
devices hardware, and persistence of the applications data in the cloud. This simple incident
tracking system allows a manager to enter new incidents that need resolving, assign them
to workers, and see the progress and comments on incidents in a workers queue. Since the
application is for both iOS and Android, it is assumed that any information, including pictures
and recordings entered on one platform, are usable by the other. The following shows a high
level layout of the application screens without platform-specific design elements. Later in this
document we will go over the UI in detail and compare the platform-specific designs that were
able to be achieved on both the Xamarin Platform and Cordova.
1 // MAGENIC
/////
It is crucial to understand which of these two cross-platform development approaches is

best suited for your organizations mobile product development program before embarking
on a lengthy and cost-intensive development project. We will explore the relative strengths
of these two platforms based on our development experience to help provide an overview of
the merits of each.
Overview
When determining which mobile platform technology to use to build a mobile application,
we find the following checklist of questions effectively surface important considerations.
This matrix illustrates which platform will better solve different criteria that may go into
your development platform decision. It is important to note that there is no platform that is
best at everything, so selecting the best mobile development platform is always an exercise
in weighing tradeoffs. Based on our mobile development experiences and the comparative
sample application development for this eBook, here are our conclusions:
2 // MAGENIC
/////
Criterion
Description
eBook Discussion
Best Platform
Target Audience and UX Level
Who is your audience and what are their UX

expectations? If your users are very sensitive to
having the app feel right on the platform or
you are representing your brand, then a more
native experience is preferable.
UX Comparison
Xamarin
CPU Utilization
Are you writing a CPU intensive application?

Do you have a client side application with CPU
intensive tasks or need access to graphics
libraries (games are a great example of this type
of application)?
Performance Metrics
Xamarin
API Access
Do you need low level API access? Do you need

to do something that involves working with
the intricacies of the native platform, such as
selecting the container and encoding type for
audio recordings?
Developer Experience
Xamarin
Initial Investment
Is cost a significant factor? Is your primary

concern the cost of licensing and initial
development cost? The more platforms you write
for, the larger the cost advantage of PhoneGap
usually is.
Toolset Licensing Cost
PhoneGap
Initial Development Timeline
Is time to develop a large factor? Do you have

an immediate deadline and need the technology
that is likely to do the initial development of the
application faster?
Please Note: PhoneGap only excels in this area
if little or no work is needed for custom plugins,
otherwise this may be a tie.
PhoneGap
EMM
(Enterprise Mobility Management)
Integration
Are you working with an EMM system that wraps

native binaries? If you already know that you
need to integrate with an EMM system, it is
critical to make sure the development platform
will work with it.
Tie
Internal Skill Sets
What is the skill set of your internal staff? If you

have an internal skillset in .NET or HTML5/CSS/
JavaScript, it may help speed development on
one platform or the other.
Depends on internal skill set
3 // MAGENIC
/////
Criterion
Description
eBook Discussion
Best Platform
UI Customization
Do you have existing single page applications

that you want to leverage part of the technology,
want an HTML experience, or use a design firm
that created an application that looks and feels
similar to your website? Some designers want
an open canvas to create applications that feel
the same on both platforms, which HTML5/CSS
tends to be better at than trying to reskin native
controls to look the same. Also, it is possible that
some existing HTML5 applications, particularly
ones written as single page applications, can be
converted to mobile applications with a potential
to save code.
Please Note: As a standard practice we do not
recommend this approach for mobile design;
for most mobile scenarios it is preferable to
make an application that adheres to platform
design standards.
UX Comparison
PhoneGap
Developer Productivity
Do you want the benefit of compile/runtime type

checking for development and testing? In many
cases, errors can be identified in the compilation
process for languages with compile time type
checking. It can be argued that this helps speed
up the development process and creates a more
stable and maintainable product.
Xamarin
Ecosystem Stability
Can you work with an ecosystem that may have

significant flux? Flux in a development platforms
ecosystem can cause portions of an application
to be rewritten or the underlying libraries to
become unsupported. There is a level of flux
in all platforms, but some have more than
others. Currently the number of libraries and
frameworks in the HTML5/CSS/JS ecosystem are
in a high state of flux.
Other Factors
Xamarin
Feature Support
Do you need access to the platforms latest

features, such as 3D Touch? Do you need an
application with access the latest features of a
platform? Xamarin has tended to offer Day One
support for most new features. PhoneGap usually
has a delay before Cordova and associated
plugins are updated.
Xamarin
Open Source Utilization
Do you have any restrictions on the use of

Open Source technologies or license types? You
are likely to need to pull in some open source
libraries for both platforms. There are also
commercial options of both platforms.
Other Factors
Tie
4 // MAGENIC
/////
About Xamarin
Xamarin Platform [Xamarin] is a cross-platform development technology from Xamarin, a
San Francisco-based mobile development technologies company. Xamarin grew out of the
Mono project in 2011 and allows C# developers to create native executable apps for OSX,
iOS (including Apple Watch), Android (including Android Wear), Windows Phone, Windows
Store, and Windows 10 Universal apps.
Developers can use the Visual Studio environment to develop, build, and debug, or use
Xamarin Studio, a lightweight IDE, on Mac or Windows.
Xamarin apps can be written in one of two flavors: using the classic Xamarin Platform and
the new Xamarin.Forms framework which is a library that sits on top of the Xamarin Platform.
Xamarin.Forms, first released in 2014, allows both reusable backend code as well as UI,
enabling up to 95% code reuse. UIs are rendered in native controls on iOS, Android, and
Windows Phone, staying true to the host platforms overall user experience.
The Xamarin Platform, either Xamarin.iOS or Xamarin.Android, targets a specific mobile
platform. While back end code and libraries are still reusable, it allows 100% API access and
granular control of the UI and platform-specific functionality (e.g., Android Material Design,
Apple Pay, Google Play Services).
In brief, select the Xamarin Platform when you want to create truly native user interfaces for
each platform, possibly with significant UI differences. Select Xamarin.Forms when sharing
the UI code (creating a single UI) is more important than creating unique platform UIs.
Note that Xamarin.Forms also has the capability to implement platform-specific features
and UI to help create experiences unique to each platform. However, frequent use of those
features may indicate the Xamarin Platform may be the better choice; its the choice weve
made for this eBooks sample application.
Xamarin applications of either flavor can be distributed through public or private app stores.
About PhoneGap
PhoneGap is the Adobe-branded version of Apaches open source Cordova project. It is a mobile
development technology referred to as a hybrid. Hybrid applications run in a native container
on the device but applications are created primarily using HTML5, JavaScript, and CSS.
The advantages of a hybrid development technology like PhoneGap over a traditional
website is that a devices native hardware can be accessed through plugins, allowing for
Java and Objective-C/Swift code to be used to control the device. Since these plugins are
exposed as PhoneGap plugins, the developer only needs to know HTML5 and JavaScript
to take advantage of them. However, if a plugin does not exist, it requires the developer to
write the necessary functionality in Java or Objective-C/Swift.
5 // MAGENIC
/////
Additionally, unlike mobile web sites, PhoneGap applications can be distributed through
public or private app stores.
Methodology
We compared Xamarin and PhoneGaps approach to mobile development from a variety
of different angles. Determining the appropriate development technology is rarely as one
dimensional as looking at which tool performs better in some narrow field or which enables
a given user experience; there are many factors that should be considered individually and
together to decide which is the best development technology for a given scenario.
We compared four primary areas we believe are relevant to building enterprise applications
using the sample application, including:
Performance
User Experience
Cost
In addition, when results were particularly notable in other areas of enterprise interest, we
made note of them.
The sample application was developed using the PhoneGap and Xamarin ecosystems based
on the same design and requirements. Please note that the sample application was not
explicitly designed to benchmark performance or UI differences, but instead to simulate a
common enterprise mobile application scenario.
A note about performance testing
Performance testing on HTML5/CSS/JavaScript applications can be notoriously difficult
to measure. This is mostly due to the asynchronous nature of many HTML5 and JavaScript
operations and knowing when operations actually complete.
From a users perspective, performance can be measured in terms of simple things, for
example: how long does my application take to load, how long does it take for a page
transition to take place so I can see everything and start using it, and how responsive is the
application to user input.
For strict start-and-stop timings we exercised the application through the UI, paying
attention to when operations began and ended. For those interactions where the user could
see a clear start and stop, such as opening the application, we repeated the function ten
times, recording the results on a GoPro camera. The recordings were then examined to
determine precisely when the operation began and, from the users perspective, when it
was complete.
6 // MAGENIC
/////
Developer experience has a large impact on the ease with which an application can be
created, how easy it is to maintain, and what help a developer is likely to require when
writing the application.
Choosing a technology with little or no supportor with an inferior development
experiencecan result in an application that is unstable and difficult to find qualified
developers to maintain. In addition, support is a determining factor in readily finding
developers who are able and willing to work with a given technology.
Languages Used
We used a variety of libraries and frameworks that are likely to be found in Xamarin and
PhoneGap applications for our sample so it would be representative of what may be created
and deployed using these technologies. Other than the cost of the Xamarin tooling and
Visual Studio IDE, all libraries used were open source or otherwise had no direct cost.
Xamarin
The Xamarin application followed a Model/View/View Model (MVVM) pattern to take
advantage of cross-platform binding opportunities. Other packages were used to allow
cross-platform code sharing.
MVVMCross
An MVVM library to create cross platform applications. The current version (3.5.1) was
used, though some classes from the upcoming versions were pulled in to work with
Android Material Design components.
ACR MVVMCross Plugins
Extensions to the MVVMCross platform to allow native cross-platform functions such as
dialogs and networking.
URLImageViewHelper
A library for downloading, caching, and displaying images over http for Android.
SDWebImage
A library for downloading, caching, and displaying images over http for iOS.
Xamarin.Mobile
Cross-platform library for accessing media files on a device.
JSON.NET
Newtonsofts library for manipulating JSON in .NET.
7 // MAGENIC
/////
PhoneGap
It is possible to create a simple app using nothing but the PhoneGap.js / Cordova.js library.
However, mobile UI development libraries like Ionic are becoming increasingly popular
and make development easier. This is because the user is given a CSS framework to create
mobile applications that look like mobile applications instead of starting with HTMLs blank
canvas. Our PhoneGap application follows a Model View Controller (MVC) pattern and uses
the following libraries:
PhoneGap
Wraps our HTML and CSS into a native app.
Ionic
Provides Angular directives for PhoneGap apps and provides a strong UI framework.
ngCordova
A collection of AngularJS extensions for the Cordova / PhoneGap API.
AngularJS
A framework for creating MVC applications, usually a single page application (SPA).
Other Plugins
Plugins needed to access hardware components such as images or the camera.
Code Reuse
Xamarin
Xamarin has several ways to reuse code. The most common structural ways are through
the use of shared projects and portable class libraries. There are also coding patterns,
such as MVVM, that help support the concept of separation of concerns and as such create
a reusable pattern. As noted previously, we used MVVMCross to achieve this.
LINES OF CODE
% OF TOTAL
Shared Code
2,612
42%
Android-Specific Code
1,282
21%
iOS-Specific Code
2,357
38%
Total
6,251
PhoneGap
PhoneGap had nearly 100% code reuse. Views and controllers work on all devices and do
not need to be shared. We did, at times, check in the controller for the current platform
type (iOS and Android) and then use IF statements in the views to show different HTML
based on that value. For example, the add button on the dashboard is shown in the title bar
in iOS and as a floating button on Android.
8 // MAGENIC
/////
LINES OF CODE
% OF TOTAL
1,152
99%*
Android-Specific Code
< 1%
iOS-Specific Code
< 1%
Shared Code
Total
1,160
*although, the PhoneGap application did not fully satisfy the app requirements
Code Reuse Caveats

Counting lines of code is not the most accurate measure of code reuse or the associated
effort to create the application. Different languages are more likely to have more lines or
longer lines than others. For example, the opening parenthesis for PhoneGap was placed
on the same line as the control structure, which is a common convention for JavaScript.
In Xamarin, the opening parenthesis went on a new line after a control structure, as per
normal C# convention, which had the impact of inflating the overall Xamarin line count.
Additionally, Xamarin uses the storyboard designer for iOS, so there are no direct lines
of code written and the XML generated is quite lengthy. For these comparisons, all HTML,
interface XML, and storyboard efforts were not counted; only custom C# code for Xamarin
and custom JavaScript code for PhoneGap were used.
Finally, it is important to note that the PhoneGap application did not fully satisfy the
requirement that the recordings be able to be played back on either platform. In order to
satisfy that requirement, we would have had to write Objective-C/Swift and Java custom
plugin logic for both the iOS and Android PhoneGap applications. This would have had the
impact of increasing the lines of code written for the PhoneGap application, reducing the
percent of shared code and introducing other languages into the mix.
Conclusion
In general PhoneGap enjoyed a large advantage, both in terms of percentage of code that
was cross-platform and much less code being written overall. However, if you have to work
with features not supported by PhoneGap, you need to write custom plugins in the platformspecific languages for each target platform. If we had done that, this advantage would have
been significantly less than this test indicates.
Based on our experience with Xamarin.Forms, we are confident we would have seen over
90% code reuse if we had used that instead of the Xamarin Platform.
9 // MAGENIC
/////
Developer Tooling
The following toolsets were used in the development of the Xamarin and PhoneGap projects:
Xamarin
Visual Studio 2013
Resharper (https://www.jetbrains.com/resharper/)
XCode [for iOS Storyboard work]
We used Visual Studio, Microsofts premier development environment with a long history
of enhancements, as the IDE for the Xamarin work on this project. Built into Visual Studio
are a variety of tools, including source control integration and package management using
Nuget and the Xamarin Component Store. Both of the package management tools were
used in the solution and they were found to offer a good ability to find, reference, and
manage the versions of different packages.
Visual Studios integration with Xamarin also allowed advanced debugging capabilities.
Break points were added and worked as expected to step through code. Ultimately, the
debug experience was good when connected to the iOS simulator, Android emulators, or
physical devices.
For work with iOS, we paired our Windows Machines to OSX devices with Xamarin installed.
This allowed us to compile and deploy out to physical iOS devices or run our application
in the simulator. If iOS is a target platform, an OSX machine has to be involved and are
generally paired, one per developer, for Xamarin development.
XCode was used for iOS UI development work in the Storyboard. There is the ability to work
with Storyboards as well when using Xamarin in either Visual Studio or Xamarin Studio,
but we have found that XCode offers a more reliable storyboard editing environment,
particularly when it comes to constraints. However, there is no difficulty in editing the
storyboard in XCode and using it in the Xamarin project.
Resharper offered many tools in the Xamarin solution to help maintain the quality and
consistency of the codebase. This type of tooling can be customized to identify issues with
the codebase as well as help enforce development standards.
PhoneGap
Atom (atom.io)
Ionic Lab (lab.ionic.io)
OSX Terminal
The development environment for the PhoneGap project used open source tools like
GitHubs Atom editor. While this is a decent editor it doesnt have the power of the Visual
Studio environment and provided an experience that was not as integrated as the one
provided by Xamarins Visual Studio integration.
10 // MAGENIC
/////
These tools do provide for package management and build integration with Bower, Grunt,
and Gulp. They generally require a fair amount of scripting and have less of a visual
interface as compared to Nuget or the Xamarin Component Store. Additionally, Bower does
not have as nice a visual catalog. Having said that, the underlying scripting ability of Grunt
and Gulp can create a powerful configuration management tool for the build process.
Debugging was primarily done using the debugging tools in Chrome and Safari. Both of
these tools allowed remote debugging on physical devices and simulators. These were
effective tools but were outside the bounds of the Atom IDE. This left a more disconnected
development environment than was provided by Visual Studio. Additionally, it is unclear if
something like TypeScript were used in such a project if the TypeScript would be debugged
or the generated JavaScript.
Conclusion
A fair amount of discussion could be had of the comparative merits of such toolsets. A free
tool is not necessarily a poor quality tool; Googles recent Android Studio is a good example
of a toolset that is both high quality and free. Having said that, the combination of Visual
Studio and Resharper that were used to create the Xamarin project is a well-respected and
powerful combination.
UI Development
Xamarin
The Xamarin Platform allows for the creation of native UIs, normally StoryBoards in iOS
and XML in Android. Inside Visual Studio both platforms allowed for a visual designer. This
allowed us to take advantage of platform-specific design paradigms like Androids material
design and adhering to iOSs changing Human Interface Guidelines.
The experience in Visual Studio for Android XML development provides a strong designer
experience. Usually design was done in the XML layout screen, switching to the designer to
get a visual idea of how it will be rendered at runtime. The MVVM Cross library allowed for
data binding that could be put directly inline with the Android XML. For those that created
coded UIs that capability is allowed as well, so the designer and Android XML could be
skipped entirely.
This iOS experience was not as clean. Visual Studio allows for the editing of StoryBoards
but not of Xibs. Additionally, the Visual Studio instance needed to be constantly connected
to an OSX machine. We found that the Visual Studio storyboard integration was not always
reliable, particularly when it came to creating constraints. In most cases we edited the
storyboard directly in XCode. It is important to note that editing the storyboard in XCode
and using it in our Xamarin project provided no technical problems for us.
11 // MAGENIC
/////
Unlike with Android, the MVVM Cross bindings could not be directly added to the physical
design and had to be created in code for the iOS project. Also, creating UIs with flexible
layouts was not nearly as easy with iOSs constraint system as it was with Android XML or
HTML5. The storyboard also contained multiple screens and was problematic from a source
control merging perspective if multiple developers work on different screens at the same
time. Like with Android a coded UI could be created, skipping the use of storyboards.
PhoneGap
The PhoneGap UI creation experience was similar to what you would expect when creating
an HTML5 application. Generally the HTML was coded by hand without the use of a designer.
The UI work was checked by running the application in a browser. This was a reasonably
quick experience but didnt provide the same interactive view of the UI being created as
was possible in the Xamarin project.
The use of the Ionic framework made creating a UI that looks correct for the platform
relatively straightforward. However, displaying layouts differently on each platform did
require a certain amount of extra coding. For example, showing a floating action add button
on Android and a add button in the navigation bar in iOS required some slightly different
html. With Ionic it was relatively easy to specify what HTML to be used for a platform but it
had to be checked for accuracy at runtime.
Conclusion
Xamarin definitely had the better design time tooling for user interface creation. Designs
could be created and usually viewed for accuracy all within the development environment.
However, the technologies were not the same requiring the user interface to be written
twice. It is also important to note that the Android development experience was far
superior to iOS with Xamarin. This was partly due to the Xamarin storyboard designers
connection to the OSX machine being somewhat slow and unreliable and partly due to
weaknesses in the underlying iOS storyboard and constraint technologies that are outside
of Xamarins direct control.
PhoneGaps tooling wasnt nearly as nice and applications needed to be run to see the
results of the HTML design. However, much less interface code was written and in general
much less time was required by the developer dealing with view logic and creation.
The developer also had the advantage of only needing to know a single user interface
development technology stack when the Xamarin development required knowledge of both
the Android and iOS native development technologies.
Long Term Maintenance

Both the Xamarin and PhoneGap solutions were created using supplemental third-party
frameworks that provided structure and enhanced maintainability.
12 // MAGENIC
/////
Ecosystem Stability
The HTML5/JavaScript/CSS ecosystem has gone through a high degree of flux over the
last several years. Even popular frameworks are not immune to this phenomenon. For
example, the PhoneGap solution was created using Ionic, which sits on top of the AngularJS
framework. The Angular team announced that Angular 2.0 will fundamentally redesign
parts of the framework with no direct upgrade path and will likely require substantial
refactoring of existing Angular 1.x projects to use.
While many developers may know HTML5/JavaScript/CSS, there is significant fragmentation
within that community regarding the frameworks themselves, as well as new frameworks
like Facebooks React, that frequently come up and take mindshare among the community.
This makes it difficult to chose the right framework for PhoneGap that will support a long
term maintenance scenario.
While this sort of flux does happen on occasion with similarly popular .NET frameworks, it
is not nearly as common as with the HTML5/JavaScript/CSS ecosystem. Xamarin solutions
require fewer dependent frameworks, relying more on design patterns and core C#
language skills, with extensibility provided from readily available NuGet packages or via the
Xamarin Component Store
Code Maintenance
The underlying languages themselves take very different approaches. C# has a type system
that supports compile and runtime type checking while JavaScript currently does not.
There are arguments to be made that compile time type checking leads to more stable and
maintainable applications. As mobile applications change or grow, compile and runtime
type checking makes it easier for developers to maintain functioning code . It seems that
the value of this has not been lost in the JavaScript world, where extensions like TypeScript
that do transpile checking are popping up. This is an area where if you currently find type
checking to be important to long term maintenance, then C# and Xamarin are better
positioned to deliver.
Unit Testing
A final thought on maintenance: as mobile applications become more common in the
enterprise, they are being increasingly held to enterprise development standards. One
way this manifests itself is in the need for unit testing and associated build server tie-ins.
Both Xamarin and PhoneGap can deliver in this space. Xamarin works with standard .NET
nUnit testing frameworks, while PhoneGap uses common JavaScript testing frameworks
like Jasmine. Optimal unit test design revolves around isolating units of work, which
is commonly done via dependency injection and mocking. Dependency injection and
mocking frameworks are quite common in the .NET world and many such libraries work
with Xamarin. However, care must be taken so that any unit test that runs on a physical
iOS device is not written in such a way that the mocking framework uses disallowed
functionality such as reflection.
13 // MAGENIC
/////
Due to the lack of type safety in JavaScript, dependency injection and mocking frameworks
are uncommon and other methods must be used to isolate units of work. In fact, an
argument can be made that development and unit testing may need to be more complex
to handle the potentially unknown nature of data that is passed into a unit of work to make
sure it properly reacts to unexpected inputs.
Conclusion
Xamarin provides compile and runtime type checking that many consider important for
long term maintenance stability of a product. Unit testing is possible on both frameworks
with Xamarin having the edge due to more common .NET inversion of control and mocking
frameworks. While both ecosystems have some level of flux, JavaScript is normally
considered the more dynamic of the two. Having said that, the HTML/CSS/JavaScript
ecosystem isnt tied to any particular vendor and will likely stay in play for the foreseeable
future. .NET is supported by Microsoft and similarly will likely stay in play for the lifecycle
of any present mobile projects. Xamarin itself, is a smaller company and does represent a
higher level of risk as their financial picture is not as clear. Even then, companies such as
Microsoft have an interest in keeping Xamarins technologies in play so we would classify
the risk of their product disappearing as low.
Code Organization
////////////////////////////////////////////////////
Xamarin
The Xamarin project uses a standard .NET cross platform project structure with a portable
class library (PCL) to contain shared code and two platform-specific libraries (one for iOS one
for Android). External packages were added using Nuget and the Xamarin Component store.
All of the shared application logic was contained in the PCL, including models, view models,
data access, and common interfaces. Additionally, it was found that some value converters
for binding were able to be shared as well so they also were located within the PCL. The PCL
represented a reusable unit that could be distributed outside of this solution as well and used
in other projects that the profile supported. Our PCL targeted profile 111 which would allow
the library to also be used in .NET 4.5 applications and in Windows Phone 8.1 applications.
Within each of the platform-specific projects are the storyboards and view controllers
(iOS), and the XML views and activities (Android) required to make platform-specific UIs.
Additionally, platform-specific code to access the hardware, such as fine control over
audio recording formats, is within the platform-specific projects. Platform-specific code
to access the hardware is called by the ViewModels within the PCL through the shared
interfaces, using the inversion of control (IoC) container that MVVM Cross provides to
resolve out the appropriate platform-specific implementation at run time.
14 // MAGENIC
/////
PhoneGap
The project structure is a modified version of the Ionic default folder structure that follows
John Papas Angular Style guide (https://github.com/johnpapa/angular-styleguide).
The default Ionic structure to have all controllers in one file, all services in one file, etc. As
John Papa explains in his style guide, this isnt a very clean way to do things. Our project
structure moves each controller, service, and template to its own file and groups items by
their type. For larger projects an alternative structure is to group by functional area and
not by type, but we felt that wasnt necessary here and would lead to a large number of
subfolders for such a small app. In this respect the layout was somewhat similar to what
it was with the Xamarin project, where individual concepts have their own file (controller,
service, directive, etc). One large difference would be if this code needed to be shared
among different projects, instead of passing around a single .dll like with Xamarin, a
collection of JavaScript files would have to be distributed.
Conclusion
Both Xamarin and PhoneGap can create project structures with a reasonable way of
handling code organization within to project. With Xamarin through Microsofts shared
projects and PCLs there is also a mechanism to organize code for use in multiple projects.
The PhoneGap solution could do it all in one project but sharing code outside of that unit
would not have been as neat. It is also notable that if the sound issues in the Cordova
project were addressed with platform-specific projects then that would have included two
additional projects of different technologies (Java and Objective-C/Swift)
Compile Time
The amount of time it takes to compile an application can have a significant impact on
developer productivity. The following compile times were all taken on the same machine,
a MacBook Air 6.2 with 4Gb of Ram and a 1.4 Ghz Intel Core 5 processor. The PhoneGap
project was build from XCode on the Mac and the Xamarin project was done from Visual
Studio on a machine paired with the Mac, as that mirrored the Xamarin approach taken.
The compile times here are for a release build, which takes significantly longer than a
debug build. For example, Xamarin built the same project in 34 seconds for iOS and 32
seconds for Android.
XAMARIN
PHONE GAP
iOS
70 seconds
18 seconds
Android
40 seconds
25 seconds
The PhoneGap project has a noticeable advantage when it comes to compile times. While
the MacBook Air is not a powerful machine, it seems that it is more than adequate for a
PhoneGap project.
15 // MAGENIC
////////////////////////////////////////////////////
/////
Conclusion
If you plan on doing work in Xamarin you will need a high end Mac to minimize the impact
of compile time. It is recommended that a high speed MacBook Pro or better be used to
minimize build times.
Access to Native Functionality & APIs
Xamarin
The Xamarin team has wrapped 100% of the native iOS and Android APIs for direct access
via C# from a Xamarin application. In general, any native API that can be accessed in a Java
Android or Objective-C/Swift iOS application can also be accessed in a Xamarin application.
The Xamarin team has also reshaped many of these APIs to be more familiar to .NET
developers without losing functionality.
For librariesparticularly third party librariesthat are not currently wrapped and
accessible from .NET, bindings libraries can be created. These are created using .NET code
to wrap the native library. In general, this process is pretty straightforward for components
with simple APIs. However, the documentation and support can be somewhat sparse when
wrapping more complex APIs.
The ability for Xamarin to access native APIs became critical when recording sound. We found
that sound needed to be recorded in a format and codec that was available on both platforms.
Since the Android MediaRecorder and iOS AVAudioRecorder APIs were directly available, the
sound could be recorded in MP4 using AAC, a format available on both platforms.
PhoneGap
Access to native functions are handled with plugins on PhoneGap. Apache maintains an
extensive plugin repository at plugins.cordova.io, which currently has over 500 plugins.
If you need a plugin that isnt currently available, you can write your own using Java (for
Android) and Objective-C / Swift (for iOS). Writing custom plugins is outside the scope of
this eBook and isnt something we looked into.
The Ionic team has started their own collection of extensions, ngCordova, that wraps many
of the popular plugins in Angular extensions. This makes it very simple to add a plugin and
then use the prewritten Angular extension to take a photo or record audio.
We used plugins for connecting to Azure, taking photos, recording audio, and playing back
audio, though as mentioned later these default plugins did not give us the full functionality
we required.
16 // MAGENIC
/////
The audio plugins gave us a problem. We used the standard device.capture calls to record
audio as described in the Cordova docs. This worked fine, however it records using the
devices audio recording application and, as such, does not provide any way to change the
audio format being used. We found when doing this we could not play files recorded on
Android on iOS devices and vice-versa.
Even searching for other plugins we were unable to find an audio recording plugin that
allowed us to record in a standard format that would allow for playback on all devices.
This left us with two options: convert the audio in the service layer or write our own audio
recording plugin in Java and Objective-C/Swift. Neither was in the scope of this project
and the PhoneGap apps were left without the ability to record and playback audio in a
cross platform fashion. The implication here is that if your PhoneGap application needs
functionality outside of what existing plugins provide you may need to plan on some level of
native development or server side conversion to bridge that gap.
PhoneGap Windows App Support
While PhoneGap support for Android and iOS is very high, Windows apps are supported but
not as well.
We did not build a Windows app for this project, but we have seen problems using PhoneGap
and Ionic with Windows Universal apps. Some workarounds are needed, including an MSDN
shim and using the $compileProvider directive.
Xamarin provides good support for Windows Phone and Windows Store apps, with recently
released Windows 10 Universal support.
Conclusion
If you need full access to the native device APIs then Xamarin will likely be a better solution
than PhoneGap. If you do decide to use PhoneGap, you should understand that may mean
eventually writing platform-specific plugins in native languages. This is particularly true of
targeting the Windows ecosystem. While code sharing technologies like shared projects
and Portable Class Libraries will serve to get your code to run on Windows and access to
the native APIs through inversion of control, the same cannot be said of PhoneGap. With
PhoneGap the Windows and Windows Phone plugin support is far behind what is available
for iOS and Android. If your PhoneGap application needs to deploy to Windows or Windows
Phone there is a much higher possibility of needing to write a custom plugin.
Dev Ecosystem
The HTML and .NET worlds each have vibrant and strong ecosystems of third party tools
and libraries, both commercial and open source. Substantial and popular libraries and
frameworks can be found in either realm.
17 // MAGENIC
/////
.NET has a large and thriving developer and partner ecosystem. With millions of .NET
developers worldwide, Xamarin provides an opportunity to extend their existing skills into
mobile. Additionally, there are thousands of NuGet packages that can be reused for Xamarin
projects, as well as a growing number of open-source and commercial components
to extend Xamarin capability through cross-platform UI controls, data visualization,
connectivity, and security.
The HTML5/CSS/JavaScript ecosystem is going through more flux, thus entailing more
concerns around long-term maintenance of the solution. Breaking changes and the rapid
rise and fall of HTML frameworks should make developers wary about which ones they
make a long-term bet on.
Conclusion
Both platform ecosystems provide vibrant and wide ranging third party libraries and
frameworks. There are many more HTML5/CSS/JavaScript developers, but Xamarin also
has a considerable following. In general, the .NET stack that Xamarin sits on top of has less
flux than PhoneGaps HTML5 ecosystem.
Performance Metrics
///////////////
App Size
When looking at the size of compiled applications there are two things to consider. First,
how large is the file that is downloaded? Second, how much space does the application
consume on the device once installed? When looking at the size of the application on the
device, we made sure to clear any cached data on the device that the application may have
downloaded. In all cases the PhoneGap application was smaller.
For the Xamarin application the linker setting was set to SDK assemblies only. This setting
provides a moderate level of removal of unneeded code from Xamarin applications; in
particular, it removes any portions of the SDK and the Mono framework that it determines are
not used, but leaves in all referenced third-party libraries. In iOS the application architecture
selected was arm64 and arm7 for both the Xamarin and PhoneGap projects. It is important
to note that these simple applications had very little in the way of image assets. In many cases
enterprise applications have a large footprint of included image assets which would reduce the
size difference on a percentage basis, that is to say it would be less of a factor.
18 // MAGENIC
///////////////
/////
Start Time
One thing a user will notice is how long an application takes to initially load and for the user
to start interacting with the application. Many times a user will keep an app running and not
need to restart, so the impact on this test can still be limited. However, it gives the user the
first impression of your application. The Xamarin versions of the app showed consistently
faster app load times, loading 25% faster on Android versus the PhoneGap version. Long
load times will not only affect the overall perception of the app, but if used many times daily
can be a source of frustration and dissatisfaction.
///////////////
The test devices used for these timings were:

iOS: iPhone 5 32GB, iOS 8.4.1
Android: Google Nexus 5, Android 5.1.1
Display Long List
We purposely set up data so one user would have 1,000 items in their resolved queue. We
then displayed this list to the user and measured that amount of time it took to display
and for the user to start interacting with it. Loading lists of items is a common scenario
in mobile applications and thus one where users are likely to notice differences in
performance loading a page.
Memory Usage
Memory tests were performed multiple times on physical devices with frequent resets in
order to ensure no artifacts or caching carried over from one test to the next.
For the iOS test, the application was exercised in exactly the same way and the session
recorded in order to provide a means of reliable review. The final figures here are an
average of the recorded values taken at the end of each test run using XCode Instruments.
Persistent bytes represent the amount of memory the application is currently using at the
end of the test. The Total Heap + Virtual show the cumulative memory that was allocated by
the app and iOS for the duration of the test. The tests indicate that Xamarin iOS application
ended using a larger memory footprint but the PhoneGap application consumed and
released a much large amount of memory while the test was running.
For the Android test, the current memory usage was queried after a similar walkthough of
the application while monitoring with Android Debug Bridge (ADB). Overall, we found that
the PhoneGap application used more memory than the Xamarin application. Two particular
areas where PhoneGap seemed to consume memory were ashmem (asynchronous shared
memory) and unknown memory usage (memory usage that could not be classified).
19 // MAGENIC
///////////////
/////
iOS
Android
XAMARIN
PHONE GAP
Persistent Bytes:
470 MB
125 MB
Total Heap + Virtual:
3 GB
6 GB
PSS Total:
165.1 MB
231.5 MB
Private Dirty + Clean:
160.0 MB
225.7 MB
Performance Summary
On iOS we found significant differences between PhoneGap and Xamarin in terms of
CPU utilization.
PhoneGap put significantly higher load on the iPhone CPU overall which, depending on the
application, may translate into lower battery life even if the user didnt notice a lag in the
applications interactions. We should also note that we did experience significant lag on
PhoneGap when scrolling and loading images in lists.
The graph at right describes the total CPU time at the end of each test run. As you can see,
PhoneGap utilized significantly more CPU even though the exact same data was used and
the same test script was followed in each case. Significantly higher CPU usage can result
in poorer performance, noticeable user interaction lag (which we noted), and reduction in
battery life if high CPU usage is sustained for long.
We experienced a similar CPU usage pattern on the Android platform though were not able to
have the same level of metrics over time from ADB as we saw from XCode Instruments. From
monitoring the app during the walkthrough we found the Xamarin app spiked at 53% CPU usage
and usually was less than 10%. The PhoneGap application spiked at 73% using the same incident.
We collected this information while monitoring the results of an ADB shell top | FINDSTR [app
id]. This monitoring also verified the memory figures collected previously. Overall, the PhoneGap
application was found to use more memory and CPU time to achieve the same results.
CPU Intensive Tasks
The sample application we created didnt contain any CPU intensive tasks. We did want to
cover this topic, however, and it is one that we have covered in previous testing between
Xamarin and Cordova. (see: http://magenic.com/Blog/Post/4/Mobile-DevelopmentPlatform-Performance) The previous testing should give us an equivalent picture.
In our previous test we created a Sieve or Erastenies for each platform. This test calculates
prime numbers, or to be more accurate, calculates numbers that cant be prime starting
with two and then whats left is known to be prime. For our tests we found the largest prime
up to 50,000,000. For these tests we found Cordova to be 22 times slower than Xamarin on
the Android platform and 14 times slower on iOS.
20 // MAGENIC
///////////////
/////
While it is interesting to look at the performance of CPU intensive tasks, it is only fair to
point out that although CPU load causes battery drain, most enterprise mobile applications
are not particularly CPU intensive. Even then, given that PhoneGap is significantly slower, it
is likely to cause higher CPU load even during common application tasks. This observation
proved true when looking at CPU usage our non-CPU intensive sample applications as well.
Additionally, tablets that can run multiple applications side-by-side are becoming more
common; consequently, applications may have to share the CPU with another foreground
application (See Windows 8.1/10 tablets and Apples iOS 9).
Conclusion
The overall tests show that apps ran significantly more efficiently on Xamarin vs. PhoneGap
on iOS and Android platforms. The applications started faster, used less memory, and ran
normal tasks with greater speed. Given the nature of the underlying technologies this isnt
particularly surprising. This is one of those areas where you need to ask yourself what do your
mobile applications need to do and is this difference in performance material to your needs?
User Experience Comparison

Differences in Technology
As previously indicated, the PhoneGap solution uses a combination of HTML5 and CSS for its
visual display while Xamarin uses the interface components native to each platform. For the
sample application, modern iOS design standards were used along with Material Design on
the Android platform.
The PhoneGap application used the Ionic framework to simulate these same iOS and Android
designs. Some minor platform-specific tweaking was used to get items like the floating
action button on the Android platform. However, no extraordinary measures were used to
get it to look perfectly native. The purpose of this comparison is to see how close a platform
like PhoneGap can get to a native user experience without expending significant effort.
Side-by-Side Comparison
In the following comparisons, the native Xamarin UI is shown on the left while the PhoneGap
version using Ionic is on the right. The screen captures for Android were taken on a
OnePlus One (https://oneplus.NET/one) running Cyanogenmod for Android version 5.1.1. The
iPhone screen captures were taken on an iPhone 6 running iOS 8.4.
21 // MAGENIC
/////
ANDROID
Login Screen
Xamarin
PhoneGap
Outside of some minor control placement issues, the most noticeable difference is in the
Sign In button itself. The native UI uses the application theme so the button shows up blue
with white text and highlights with a darker blue when you click on it. The Ionic experience
didnt, by default, honor an Android-looking theme for the button without having written
custom platform-specific styles.
22 // MAGENIC
/////
Dashboard
Xamarin
PhoneGap
The PhoneGap application does a good job of mimicking the Android material design. With
a few lines of platform-specific code we created a floating action button (this is located
lower right hand corner of the screen; the round green add button) but that looks close
to native. There are some differences, though. The floating action button by default had a
transparent + in the center and the spacing of the status items wasnt as tight as on the
native implementation.
Another interesting layout feature was that the PhoneGap screen did not provide the same
level of fine control over the spacing as was achieved in the native UI. With further work this
was likely possible by setting negative margins but the native UI offered us an easier time
giving precise control over the spacing than the HTML5/Ionic CSS controls did in PhoneGap.
23 // MAGENIC
/////
Wait Indicator
Xamarin
PhoneGap
In this comparison we look at the wait indicator. The reason we selected the OnePlus One
for this comparison is because it has a distinctive octagonal spinner for a wait indicator.
This is the kind of detail that PhoneGap applications can rarely match and leads to the
application not quite feeling right on the platform, even if the user does not consciously pick
up on the difference.
24 // MAGENIC
/////
Add Incident Picker

Xamarin
PhoneGap
Several things are slightly off on this screen, the most noticeable being the dropdown list
is far different than what would be expected with Android Material Design. There are some
other subtle differences, as well, including the underline of the test input fields not being
correct on the PhoneGap application and the control that produced the picker looking like a
normal HTML dropdown.
25 // MAGENIC
/////
Worker Queue
Xamarin
PhoneGap
The item of difference here is the appearance of the tab control. The slight red underline
on the native Android Xamarin honors the Android theme of the application; this detail is
missing from the PhoneGap application.
26 // MAGENIC
/////
Incident Detail
Xamarin
PhoneGap
For the incident detail screen there were things in the design that were harder to do in the
PhoneGap application. For example, the navigation bar in the design was transparent. This
comparison shows what a true cross-platform implementation of the PhoneGap application
would look like. Most noticeably absent is the floating action button of the Android native
design achieved with Xamarin.
27 // MAGENIC
/////
Context Menu
Xamarin
PhoneGap
The context menu in the PhoneGap application looks like a reasonable facsimile of the native
implementation, with the most prominent difference being the height of the menu and the
white space within it.
28 // MAGENIC
/////
iOS
Login Screen
Xamarin
PhoneGap
As with the Android application, the Sign In button is a good example of some of the
differences between a native UI and one created with PhoneGap. As per modern UI
standards, the iOS button has no border; however, the button on the PhoneGap application
looks exactly like it did on Android.
29 // MAGENIC
/////
Dashboard
Xamarin
PhoneGap
For the Dashboard the results were very good. The PhoneGap application used a plus in the
navigation bar as is expected in iOS instead of the navigation button. This bit of code was
iOS-specific as the floating action button code was Android-specific.
One item of interest for the PhoneGap application is that the numbers for the bars do not
show up inside the bars as they do on the Android application. This is probably something to
do with the CSS used by Ionic to recreate these controls. Custom coding or changes to the
CSS files would likely be required to correct it.
30 // MAGENIC
/////
Wait Indicator
Xamarin
PhoneGap
The wait indicator for PhoneGap is similarly missing as it was for the Android application. It
is interesting to see that the pull-to-refresh indicator is correct, just as it was for Android.
31 // MAGENIC
/////
Add Incident Picker

Xamarin
PhoneGap
Picking a name is very close to the native iOS implementation. Like Android, the dropdown
control itself looks like what would be expected in an HTML application. Another item of
interest is that the navigation bars menu is displaying with Androids stacked dots instead
of the expected iOS Action icon.
Also, what isnt visible is that the Xamarin native UI implementation has a Save Incident
button on the form instead of the Android style Send button in the navigation bar that the
PhoneGap version has. Normally a visual layout seen on Android devices, iOS users may be
confused by the icon and the flow to save in this scenario.
Both of these items could have been implemented in the PhoneGap application to give a
more native feel if platform-specific HTML had been used.
32 // MAGENIC
/////
Worker Queue
Xamarin
PhoneGap
The Worker Queue screen uses a native segmented control for the native iOS UI. The
same tabbed navigation is displayed as was used in the Android design in the PhoneGap
application. To make this screen look the same as the Xamarin implementation for a native
look, platform-specific code would need to be employed.
33 // MAGENIC
/////
Incident Detail
Xamarin
PhoneGap
Once again the PhoneGap application does a good job in matching the look of the native UI.
Most of the differences could be matched with platform-specific code, including using the
correct navigation bar menu icon for the different platforms.
34 // MAGENIC
/////
Context Menu
Xamarin
PhoneGap
This is an area where there is a more substantial difference between the native Xamarin
implementation and PhoneGaps. While PhoneGap used a more iOS-like dropdown than it did
on the Android application, it didnt match the native experience.
Responsiveness
While generally looking native, a PhoneGap application is technically very different under the
hood since it is built on top of HTML5, CSS, and JavaScriptall technologies that were not
designed with touch mobile devices in mind. This causes some usability issues when implemented
in a mobile environment, where touch interaction and fluid response are paramount.
Touching vs. Keyboard/Mouse Interaction
When handling click events, web browsers pause for 300 ms after receiving a touch event
before processing it as a click. This is done because the browser is waiting to see if the user
is going to click again, which would act as a double click. This is expected behavior when
navigating a web page with a mouse, but when building hybrid mobile apps with PhoneGap,
a 300ms delay is noticeable to the user. Since the user will never double click on a touch
centric device, its also unnecessary.
35 // MAGENIC
/////
There are solutions for the 300 ms delay. FastClick.js is an example of a library that solves
the issue by removing the 300ms delay. Ionic also has a solution built in; its ngClick directive
is what we used to remove the 300ms delay in our sample PhoneGap application. However,
we have seen cases where libraries like FaskClick.js have conflicts with some third-party
JavaScript controls.
Another limitation of PhoneGap is its lack of ability to take advantage of the newest
interactions with iOS 9, specifically 3D Touch. PhoneGap wont be able to use this feature,
whereas Xamarin can support pressure-sensitive interactions with its 100% access to iOS
APIs and events.
Long Lists
As indicated in the performance testing section we had created a test with 1,000 incidents
and loaded them in a list to show them on a single page.
Xamarin sometimes showed a longer initial loading time as items were first loaded from
Azure into models and then mapped to 1,000 individual View Models. This isnt necessarily
a problem with Xamarin, but more an advantage of the MVC pattern used by the PhoneGap
application when compared to how we implemented the MVVM code. However, when
this list was loaded, the scrolling was extremely quick and the items appeared to fly by
on the Xamarin iOS and Android apps. This is because of how native Android and iOS list
management works, which Xamarin automatically takes advantage of. A paging scheme
is used on both platforms where only the cells currently visible to the user plus one are
loaded. As the user scrolls through the list, the cells are recycled and loaded with data from
the list items currently displayed. This makes for an extremely fast scrolling experience.
PhoneGap did not handle this list well. As detailed above, scrolling to the bottom of this
list consumed a massive amount of memory. This is due to the fact that there is no paging
scheme in use and all 1,000 items were immediately loaded into the UI. The user experience
was incredibly laggy and scrolling was very slow.
This is a well known problem for HTML/CSS/JavaScript applications. To correct this, Ionic
is spending a lot of effort working out a solution. Although still in testing, and Android only,
there are new features coming that will allow large lists to use native scrolling but are
currently unavailable. This link explains those efforts: http://blog.ionic.io/native-scrollingin-ionic-a-tale-in-rhyme/
Page Transitions
Certain page transitions occurred slowly on the PhoneGap platform. In particular there was
a delay when navigating backwards to previous pages where the screen would noticeably
freeze for a few seconds. This may be related to some of the high CPU usage we noticed on
the PhoneGap platform. Experiences like these will frustrate users who are required to use
the app for productivity multiple times a day.
36 // MAGENIC
/////
New Features
Recently Apple introduced 3D Touch on their new iPhones. 3D touch relies on the reaction
to interface interactions based on how hard the user is pressing on the screen. Given
Xamarins technology and direct usage of native APIs, they were able to support this as
part of their normal day one support for API changes. It is a little harder to imagine how
PhoneGap will easily support this concept given that HTML5 does not have a concept for
detecting pressure. New features like this also currently only exist on the iOS platform, so
any UI code that takes advantage of it would by necessity be platform-specific UI code.
Compliance with Platform Design Guidelines
As previously stated, the designers of these development platforms tried to maintain
compliance with the latest iOS design guidelines as well as Android Material Design.
The Xamarin team has no difficulty meeting these goals because Xamarin is using native
controls on each platform. However, it should also be noted that to achieve good results, a
developer does need to have a thorough understanding of the two different UI technologies
and the common UI conventions of each target platform.
The Ionic platform did a reasonable job of mimicking the designs, but the side-by-side
comparisons demonstrate that the results were not perfect. Since HTML5/CSS alone starts
from a blank canvas, it is conceivable that platform design guidelines could be mimicked
perfectly. However, current frontrunner frameworks in this area still fail to achieve that
on their own and it is unlikely that most organizations could do better without spending
substantial time carefully working through platform differences.
Conclusion
Native technologies are undoubtedly the best when done correctly to maintain compliance
with platform design guidelines. However, these come at a cost of needing developers who
are familiar with multiple UI technologies, as well as a potentially substantial investment in
coding to write a UI for both platforms.
PhoneGap can be coupled with frameworks like Ionic to produce a pretty good user
experience. They require deep familiarity with only one UI coding platform and substantial
amounts of the UI coding will be shared between the platforms. The drawback of this
approach is that a truly native user experience will not be achieved. For users of an
application written in PhoneGap, there will always be something that feels off.
Other Factors
Importance of Xamarin Build Settings
During our tests we found that different Xamarin build settings can have a significant
impact on the overall performance of the application, compile time, and even the size of the
compiled binaries. More so than with PhoneGap, there are a wide variety of build settings
that can have a substantial impact.
37 // MAGENIC
/////
For example, the following APK sizes were created for Android when changing the Linking
setting:
No Linking........................................... 41 MB
Link SDK Assemblies Only................... 15.1 MB
Link SDK and User Assemblies............ 9.8 MB
Xamarin developers need to be more aware of the build settings selected than do PhoneGap
developers. There are different garbage collectors that can be selected and different
optimization and linking settings. Each of these can have a significant impact on build time,
the size of the compiled binary, speed of execution, and memory usage.
MDM Products
Both Xamarin and PhoneGap create APKs and IPAs that can be signed and installed
on devices. As such, they can both can be deployed through the normal distribution
mechanisms of Enterprise Mobile Management (EMM, or formerly MDM) products.
Many of these EMM products also come with SDKs that can be referenced from within the
code of the app itself. For example, HockeyApp has an API that has existing bindings for
Xamarin and plugins that can be referenced from PhoneGap. However, if no existing bindings
or plugins are available, then new Xamarin binding projects would need to be created in .NET
for the Xamarin solution and plugins in Objective-C/Swift and java for PhoneGap.
There are some EMM solutions that wrap existing binaries (APKs and iPAs) to inject things
like secured networking, login, and storage. However, these tools expect the binaries to
be created in the native toolsets and languages. While an IPA written using Xamarin or
PhoneGap may run fine on an iOS device, an EMM tools wrapping mechanism may have
trouble recognizing and working with them. If an EMM tool is used, particularly one that
wraps binaries with its own functionality, then care should be taken when selecting either
one of these tools to ensure they work correctly with the EMM solution.
Toolset Licensing Cost

Generally the creation of a PhoneGap application can be done with no licensing or extra
cost outside of the hardware to build and compile the applications.
On the other hand, for Xamarin licensing is the norm to create applications. Licensing is
per developer, per platform and can be paid either on an annual or monthly basis. There
are different subscription levels available depending on if the developer only wants the use
Xamarin Studio, if they would like Visual Studio, or if they want more inclusive enterprise
support options. Full information on Xamarins current pricing can be found here:
https://store.xamarin.com/
38 // MAGENIC
/////
While PhoneGap applications can be created for free there are many surrounding products
and services that can cost money within the PhoneGap ecosystem. Chief among these is
PhoneGap Enterprise which offers application distribution and support services.
http://enterprise.phonegap.com/
Adobe has additional services that can be purchased for the PhoneGap ecosystem. One
of the more popular services is PhoneGap Build which offers a build server that will
compile applications for Android, iOS, and Windows Phone. This is particularly popular for
developers who dont have direct access to a Mac (regardless of the tools you use, you must
use a Mac OSX machine to build iOS binaries).
https://build.phonegap.com/
There are developer toolsets available that also have associated costs. For PhoneGap one of
the more popular ones is Teleriks Kendo UI Mobile which offers a substantial suite of user
controls. Telerik also makes toolsets for the Xamarin platform as well as the UI for Xamarin
product, and the Telerik Platform is yet another PhoneGap services offering, similar to
Adobes (and, like Adobes, is not free).
http://www.telerik.com/platform
Licensing Costs
For the extremely budget conscious on upfront cost, PhoneGap projects can be created
from start to finish with no investment in the toolset or IDE. Having said that, the amount
of money that is spent in tooling for a standard Xamarin project is usually insignificant to
the cost of a full application. While the cost of the license may be a factor in the decision
making process, it shouldnt be the primary factor; long term development and support cost
considerations should be a larger cost consideration than toolset licensing costs.
Other Licensing Considerations
PhoneGap is created from Cordova and as such is under the open source Apache License,
2.0. This license does obligate you to include a copy of it [the license] with any software you
distribute built with PhoneGap.
39 // MAGENIC
/////
Third Party Libraries

The third party ecosystem is large for both the .NET and HTML5/CSS/JavaScript platforms.
Distribution of packages for Xamarin is done through Nuget or the curated Xamarin
Component store, the latter offering a mechanism for reviewing the quality of components
in the store. Components acquired using Nuget are usually open source and have no review
mechanism other than the number of downloads. The Xamarin Component Store contains
a mix of free and commercial add-ons and some of the best [free] components have
been developed by teams and individuals at Xamarin. Because of Xamarins focus on the
enterprise market they have also attracted the attention of all major commercial control
vendors, including Infragistics, Syncfusion, Telerik, and several others.
PhoneGap Plugins can be acquired on the PhoneGap website as well as more generic
Cordova plugins on the Cordova plugin registry. Additional components can be found in
various repositories including Github. PhoneGap can also take advantage of many of the CSS/
JavaScript libraries that are available through distribution mechanisms like Nuget in Visual
Studio. For example, AngularJS can be acquired and used in a Cordova project using Nuget.
As previously mentioned the ecosystem of components and libraries for HTML5/CSS/
JavaScript seem to be in a higher state of flux than they are for .NET. The good news with
this ecosystem is there is an ever widening variety of frequently changing toolsets and
frameworks available to use. The bad news is the same as the good news. In the .NET world
with Xamarin the toolsets and patterns seem to be more stable and mature.
Application Updates
Normally a new version of an app needs to be distributed to each client device when
updating a compiled application. However, a PhoneGap application is mostly interpreted, at
least for the non-plugin portions. In practice it is just a container that runs HTML5/CSS and
JavaScript. Technically, that code could be downloaded and run right within the application
without any redeployment.
This is certainly true for Android PhoneGap apps, even ones deployed through the Play
Store. The Apple Store has been more restrictive. Apple requires that the majority of the
applications functionality be deployed with the application itself and any changes must
go through the normal approval process. That means that a PhoneGap app that is little
more than a redirect to a public website is probably not going to be approved. However,
there is a clause in the developer agreement that allows the updating of code when using
browser technologies. While this clause is subject to some level of interpretation, it seems
that small fixes that dont substantially change the primary functionality of the PhoneGap
application could be directly downloaded without going through the [re]certification
process. For Xamarin applications, all changes require a redistribution of the package via
an app store [or via an enterprise EMM technology] unless internally it also uses portions
that are hybrid but such parts of the app would have essentially the same advantages and
disadvantages as our PhoneGap implementation.
40 // MAGENIC
/////
Summary
In general PhoneGap and Xamarin offer great solutions for creating cross-platform mobile
applications. But neither are a one-size-fits-all solution. Care should always be taken to
choose the best mobile development platform technology solution based on your mobile
applications requirements.
While both technologies allow you to create compelling mobile application experiences,
each requires trade-offs in terms of productivity, performance, and cost. Which approach
you choose may vary based on the requirements of the specific application youre intending
to develop, as the importance of each platforms strengths and weaknesses will also vary
with the nature of the application.
As we found when creating our sample application that there were challenges with
maintaining a native look-and-feel on the PhoneGap side, and the requirement for recording
audio notes that could be shared cross-platform could only be done in PhoneGap by writing
native plug-ins in both Object-C/Swift for iOS and Java for Android. However, if those
requirements werent as constringent, the ability to share nearly all of the code and UI via
PhoneGap would be quite compelling, particularly if those new requirements resulted in
PhoneGap maintaining a more reasonable CPU load.
Finally, while outside of the scope of the tests performed for this eBook, we would be
remiss if we failed to mention Xamarin.Forms. If, in your evaluation of platform selection
criteria, you found yourself at odds between Xamarin performance benefits and PhoneGap
code-sharing benefits, youd do well to take a look at Xamarin.Forms.
Xamarin.Forms is a UI library that sits on top of the standard Xamarin Platform weve
been talking about and enjoys the same native execution benefits, while also allowing you
to create a single UI that is rendered in native controls across all platforms. The primary
drawback of Xamarin.Forms from a user experience perspective is that it constrains the
user interface design to follow certain paths and patterns.
Xamarin.Forms is a good technology but not a one-size-fits-all solution; you do experience
longer startup times than the Xamarin Platform (see: http://magenic.com/Blog/Post/4/
Mobile-Development-Platform-Performance) and some complex UI layouts can also suffer
performance penalties. Xamarin.Forms has a version in pre-release that pre-compiles the
Xaml so it will be interesting to see if that improves these results and by how much. Still,
you can achieve nearly 90% code reuse using Xamarin.Forms so it should also be taken into
account when selecting your mobile technology platform.
////////////////////////////////////////////////////
About Magenic
Founded in 1995 by the same
technical minds that still run the
company, Magenic delivers software
results on the most complex modern
application projects.
Visit us at magenic.com or call
us at 877.277.1044 to learn more
or to engage Magenic today.
This eBook is for informational purposes only. Magenic Technologies, Inc., makes no warranties, express or implied, in this summary. Other product and company names mentioned
herein might be the trademarks of their respective owners. 2015 Magenic Technologies Inc. All rights reserved.
41 // MAGENIC

Xamarin PhoneGap Ebook

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Xamarin PhoneGap Ebook

Uploaded by

Copyright:

Available Formats

EBOOK

//// XAMARIN AND

A Comparison of Two Approaches to

XAMARIN AND PHONE GAP: A COMPARISON

Access to Native Functionality & APIs.16

Long Term Maintenance. . . . . . . . . . . . . 12

User Experience Comparison. . . . . . . . 21

Toolset Licensing Cost . . . . . . . . . . . . . 38

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

It is crucial to understand which of these two cross-platform development approaches is

XAMARIN AND PHONE GAP: A COMPARISON

Target Audience and UX Level

Who is your audience and what are their UX

Are you writing a CPU intensive application?

Do you need low level API access? Do you need

Is cost a significant factor? Is your primary

Toolset Licensing Cost

Initial Development Timeline

Is time to develop a large factor? Do you have

Are you working with an EMM system that wraps

Internal Skill Sets

What is the skill set of your internal staff? If you

Depends on internal skill set

XAMARIN AND PHONE GAP: A COMPARISON

Do you have existing single page applications

Do you want the benefit of compile/runtime type

Can you work with an ecosystem that may have

Do you need access to the platforms latest

Open Source Utilization

Do you have any restrictions on the use of

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

Code Reuse Caveats

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

Long Term Maintenance

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

Access to Native Functionality & APIs

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

The test devices used for these timings were:

XAMARIN AND PHONE GAP: A COMPARISON

Total Heap + Virtual:

Private Dirty + Clean:

XAMARIN AND PHONE GAP: A COMPARISON

User Experience Comparison

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

Add Incident Picker

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON

XAMARIN AND PHONE GAP: A COMPARISON