native vs cross-platforminfo.apadmi.com/rs/138-mcb-142/images/native-vs... · development for...
TRANSCRIPT
Mobile App Development
Native vs Cross-Platform
So, you’ve decided to build
a mobile app. You want it to
work on both iOS and Android,
but you’ve also heard that
you don’t have to build these
separately anymore. You’ve
heard that it’s not only possible
to write one app that will run on
both platforms, but that this will
halve your development time
as well as the associated costs.
Sound too good to be true?
These are cross-platform apps,
and before you go looking
for a developer to build this
for you, it’s worth having an
understanding of what cross-
platform actually means from a
development and performance
point of view – namely, what it
can and can’t do.
With a good understanding of
what kind of cross-platform
or “hybrid” apps can do, how
they compare to their natively-
developed counterparts, as
well as the pros and cons of
each, you’ll be able to make an
informed decision about the
best way to develop your next
mobile app.
What isCross-Platform?The idea behind cross-
platform is simple: your
developer creates an app with
one codebase, meaning that it
will run on many devices in
the exact same way. At least,
that’s the dream.
The idea isn’t new; in 1995 Sun
technologies created a new
programming language, Java,
with the tagline “write once, run
anywhere”. Instead of compiling
code into an executable which
would run directly on the
central processing unit (CPU), the
idea behind Java was to compile
it into bytecode, which would be
interpreted and run by a Virtual
Machine (VM).
A VM is effectively a simulation
of a computer system, which
provides a layer between the
app and its operating system
(OS). A VM can be created for each
system architecture (such as Unix,
Windows or MacOS), eliminating
the need for developers to write
multiple versions of their apps
for each platform.
Fifteen years ago, J2ME was
created as a slimmed-down
mobile phone version of
Java, and was a very common
development platform used in
Symbian-based smartphones and
feature phones alike. However,
it had one major problem despite
its popularity: fragmentation.
Fragmentation is the problem
of having multiple versions of
Java implemented in slightly
different ways, with varying
levels of functionality and
support on different devices.
In practical terms, “write
once, run anywhere” became
“write once, test everywhere”.
That was fifteen years ago, so
where are we now? For a while,
development for mobile went
back to native development with
Objective-C for iOS and Java for
Android. However, in the last
few years, several “hybrid” app
software development kits (SDKs)
have emerged. These platforms
all offer the same promise as Java
did 22 years ago – “write once,
run everywhere” – but how true
is this?
The short answer is: it depends.
The rest of this paper explains
what options are available
if you’re considering an app
for your business, so that you
can decide for yourself which
technology is the best fit for
your project.
What’s changed?
NATIVEDEVELOPMENT
To fully understand cross-
platform development, it’s
important to get to grips the
“tech stack” you’ll be adopting.
This term refers to the different
layers of back-end technology
that fit together to make your
app what it is.
The tech stack you will need to
utilise for a natively developed
app will be quite different to
the stack adopted for a cross-
platform app.
Let’s start at the beginning with
native development...
The first aspect of any mobile
development project is to
identify which hardware you
want the app to run on. These
days, Apple and Android
devices are the norm.
Due to the large number of
devices available, it’s usual to
limit how many devices your
application will be actively
tested on during development.
The more devices you want to
include, the longer the testing
phase and the more complex
your project becomes. Plus,
aside from the mounting costs
and time-consuming nature of
testing so many devices, there
are thousands on the market to
choose from – testing them all
simply isn’t an option.
Each screen size will also need
to be considered. In some cases,
a multitude of tailored layouts
will need building too, as you’ll
need to account for different
“form factors”. These refer to
the physical size and shape of a
device; for example, with iOS,
the iPhone and iPad can only be
purchased with a limited set of
screen sizes and resolutions. For
Android, there are dozens more
form factors, so the devices you
want to directly support should
be carefully planned.
IOS DEVICE ANDROID DEVICE
Device support
IOS DEVICE ANDROID DEVICE
IOS ANDROID OS
Next comes OS choice.
Although this initially seems
obvious (iOS and Android),
the issue here is version
support. With each new OS
iteration comes a new set of
features and bug fixes for
the previous OS version. So
by choosing to support older
OSs, you’re adding extra cost
and complexity to support the
older OS version, and without
more development, your app
most likely won’t be able to take
advantage of the new updates
found in the latest OS. Plus, as is
the case with device choice, each
supported OS increases how
much testing is required.
Android adds even more
complexity to this decision
though, as the original
equipment manufacturers
(OEMs) such as Samsung and
HTC, prefer to further customise
the OS release provided by
Google. This can result in unique
“features” that differ from the
stock Android implementation,
which can cause yet more time-
delays for your developers.
Operating system
There is a perception amongst
some people that Android apps
do not seem to perform as well
as iOS apps do. This is all down
to the VM that sits between the
OS and the app itself.
As we discussed earlier, Android
applications are created using
Java and this requires a VM.
Although this rarely causes
fragmentation issues, it’s this
layer between the app and
the hardware which stunts
performance. This layer isn’t
present with iOS, which is why
they seem to run quicker.
For most apps, the power of
modern mobile CPUs is so
great that this won’t even be
noticeable. However, if your
application has extremely high
processing requirements (such
as a gaming app) this could
cause issues.
IOS DEVICE ANDROID DEVICE
IOS ANDROID OS
APPJAVA VM
APP
Android VM
Writing applications natively
requires two codebases, one
each for iOS (Objective-C/
Swift) and Android (Java/
Kotlin). Code cannot be shared
across the two applications
unless that code is written
using C/C++, with a Java Native
Interface (JNI) layer created
for Android. This is a complex
task and provides little access
to device functionality,
which is only exposed via the
Android APIs, although it can
be useful for sharing low-level
proprietary algorithms.
However, with a carefully
planned design, a common
architecture can be created
that can be shared between
the applications. This saves
time during both development
and maintenance.
The development tools provided
with these platforms are of
exceptionally high quality,
simplifying and streamlining
the development process. They
include tools for debugging,
performance testing,
refactoring, source repository
integration, unit testing, user
interface building and database
creation.
Application Program Interfaces
(API) can also cause problems
though. APIs are continuously
A few of the most commonly used APIs include:
Camera Bluetooth GPS
NFC
AccelerometerPush notifications2D and 3D hardware accelerated graphics
Virtual and augmented reality Fingerprint reading
Speech recognition
Application development
improved and added to, allowing
developers access to everything
from database functionality to
3D graphics.
While these are all widely
available smartphone features,
they can cause headaches for
developers, as many may not
be available in cross-platform
SDKs. If your app plans require
any of these APIs (see right), it’s
worth making sure your chosen
platform offers the correct
support for it. When reviewing
a finished product, a natively
developed app (providing the
code has been well written) will
always perform faster than its
cross-platform alternative.
Pros and cons of native development
PROS CONS
Supported by OS manufacturers
Excellent development tool support
High performance
Full access to all device features
Languages designed for large scale application development
Requires two codebases tosupport Android and iOS
Requires knowledge ofat least two languages
WEB-BASED HYBRID PLATFORMS
When discussing “cross-
platform” or “hybrid” apps,
there are several methods of
development which need to
be considered, and the first
we’re going to discuss are
web-based platforms.
These platforms use HTML, CSS
and Javascript to create apps
that are hosted inside a native
app’s web browser component.
The platform provides mappings
in the form of Javascript APIs, so
that native functionality can be
accessed by the developer.
As you can see from the above
diagram, these web-based
platforms add a significant
amount of complexity to the
tech-stack. The problems
can come from many areas:
• Running your app inside a
browser which is itself inside
an app is slower than running
it natively
• In the past, both iOS and
Android have changed the
in-app browser control, thus
creating fragmentation between
OS versions
• The in-app browser control is not
part of the application – it’s part
of the OS. So, with each new OS
release, the control can change
and your existing apps can break
• Different in-app browser
controls interpret web standards
differently. So, in the same way
that desktop versions of Internet
Explorer, Chrome and Firefox
need to be tested to make sure
they handle the differences
correctly, so do iOS and Android
in-app browsers
• Some OS features are not
exposed through Javascript
APIs, or support differs between
Android and iOS
• Platforms are slow to keep track
of OS updates
What does all of this mean for
you? Well, if only a couple of
test devices have been chosen
in order to keep testing costs
down, the initial development
process can seem relatively
painless. However, once testing
starts on all target devices, any
number of OS, browser and
device-specific bugs can crop up.
You may also see problems
arise in your chosen app
stores for devices that you
haven’t explicitly tested, and
any savings made during
development are quickly lost
during final testing or post-
launch support. If this risk is
not known or planned for from
the start, deadlines soon slip
while costs rapidly increase.
On the positive side, if you have
a team of web developers and
your application’s user interface
(UI) is relatively simple, with
limited processing requirements
and a short lifespan, web-
based hybrid apps might offer
a suitable solution. This is
because your team of Javascript
developers can correct any bugs
found in the short-term without
spending weeks, months or even
years dealing with the fallout
of long-term app updates and
optimisation for new OS updates.
IOS DEVICE ANDROID DEVICE
IOS ANDROID OS
APP
APP
BROWSER
JAVASCRIPT VM
HYBRID SDK
JAVA VM
BROWSER
JAVASCRIPT VM
HYBRID SDK
PROS
Single code base for both Android and iOS
Free to use (in most cases)
Good for simple, short-lived applications or proof of concepts (when dev team is
primarily skilled for web) Updates lag behind OS updates
Exposing missing native functionality is difficult and may require skills
your team doesn’t have
CONS
Can require platform-specific, OS version-specific, and device-specific fixes
Animation effects are inconsistent across platforms, OS versions and devices
Missing functionality/bindings
Pros and cons of web-based hybrid platforms
React is a framework created
by Facebook to create web-
based applications. React
Native is a variation of this
framework designed to create
mobile applications.
React Native works in a similar
fashion to web-based hybrid
SDKs, except that the application
doesn’t run inside a web-control.
It runs on a Javascript VM which
is supplied by the framework
and hosted within your app.
The language also isn’t standard
Javascript, it’s ECMAScript – an
evolution of Javascript. The UI
code is written in Javascript and
React, interpreted at runtime
and mapped onto native UI
elements. If we cut the jargon, all
this means that your users enjoy
a native-like app experience
provided by the OS.
REACT NATIVE
IOS DEVICE ANDROID DEVICE
IOS ANDROID OS
APP
REACTIVE NATIVE SDK
JAVA VMJAVASCRIPT VM
APP
JAVASCRIPT VM
REACTIVE NATIVE SDK
Although it may be technically
possible for a React Native
application to share most of
its code between both iOS and
Android applications, this isn’t
very common – in fact, this isn’t
the intent of the platform at all.
Facebook created React Native
so that they could train their
developers in one programming
language for all their products.
Although the Facebook app
is written using React Native
on both iOS and Android,
they actually maintain two
separate codebases. The SDK
contains a number of platform-
specific components such
as ProgressBarAndroid and
SegmentedControlIOS, which
allow the developer to use the
native UI controls of the OS,
at the expense of cross-
platform compatibility.
At the time of writing, React
Native is still in beta (version
0.50), so it’s still evolving. It’s
currently being updated every
two weeks, so if you’re thinking
of developing with React Native,
it’s crucial to integrate these
updates on a regular basis, fix
any issues in the application
code that are caused as a result,
and allow ample extra time
to make these changes. This
maintenance overhead will also
be carried through to the post-
release project phase, and will
likely be an ongoing cost for
the foreseeable future.
React Native offers very little
support for native libraries
(such as camera, Bluetooth,
accelerometer and so on). This
leaves the developer with two
options: write the feature in
native and provide the glue code
to make the feature available to
React, or don’t use the feature at
all. If you’ve chosen React Native
because of your team’s skillset,
this may be an issue, but it’s also
an added cost to create and
maintain the glue code.
Performance on Android isn’t
currently at the level of iOS either,
especially on lower-end devices.
PROS
Single programming language “Learn once, write everywhere”
Free
Good for simple apps that don’t require OS features
Relatively easy to integrate natively written code
Slower than native (exceptionallyslow on some Android devices)
Updates every two weeks
CONS
Still in beta
Almost always requires 2 codebases
Very little native functionality mapped
Documentation poor and out-of-date
Pros and cons of React Native
Xamarin is a cross-platform
technology created by the
developers behind Mono,
an open-source C# .Net
implementation, and was
acquired by Microsoft in 2016.
Xamarin provides a C#-based
development platform to
create apps that have near-
native performance on both
Android and iOS.
How do they do it? Well, for iOS,
Xamarin compiles C# code into
native ARM assembly code –
this means it runs directly on
the CPU, in the same way that
a native iOS application would.
For Android, things are a little
more complicated. Xamarin
provides a VM based on
the Mono open-source C#
implementation which runs
XAMARINalongside the Android Java VM
(rather than on top of it), and
this sits on top of the Linux
operating system that runs
underneath Android. This
means that Xamarin code runs
at a similar, if not faster, speed
than natively written Java code.
ANDROID JAVAMCW.NET APIs ANDROID BINDING
ACWMONO ART
LINUX KERNEL
Xamarin provides the
framework (.Net specifically)
for developing engine and
business logic code.
For the UI, there are three
options: Xamarin.iOS, Xamarin.
Android or Xamarin.Forms.
Xamarin.Forms is a platform
agnostic UI framework that
allows for the creation of simple,
cross-platform UIs. If a more
advanced UI is required, then
your developer will need the
platform-specific UI mappings.
In practice, this means that
the engine and business
logic of an app can be shared
between iOS and Android, but
the UIs themselves are built
to be platform-specific. If the
application is an enterprise
solution, the UI can be kept very
simple, in which case Xamarin.
Forms can be used to provide
almost 100% cross-platform
code sharing.
Microsoft Visual Studio is used
for the development, which is free
for small or indie projects. For
larger teams, expect a cost of $999
per year, while for enterprise
this reaches $1,899 per year.
Xamarin has a lot of potential
and hits the mark in a number
of areas, but you should always
consider why you’re choosing a
cross-platform tool in the first
place. If your app has a large
engine or business logic layer,
then this can be shared across
platforms with Xamarin.
However, if your application
is UI-focused and requires
integration with any of those
platform features we listed
earlier (camera, Bluetooth, GPS,
fingerprint scanner etc), you
might have to think again, as the
code is unlikely to be shareable.
If this is the case, the savings
from building via Xamarin
won’t make up for the extra
costs involved.
PROS
Single programming language
Good development tools
Well supported
Near-native performance
Can integrate native code
Not all OS features are supported
Requires two codebases in most cases
Not free
CONS
Pros and cons of Xamarin
After evaluating the most
popular cross-platform
frameworks currently
available, there’s still no single
stand-out platform of choice
to rival native development.
Savings in terms of cost and time
can be made, but only if your
application requirements fit into
a narrow set of circumstances.
Most of the solutions incur
a significant performance
hit, and can limit the amount
of graphical polish that’s
expected from modern mobile
applications. This is why so many
app developers end up re-writing
them in native, motivated largely
by poor end user reception and
1-star app store reviews.
The goal of writing an app
that not only runs on multiple
platforms with a single codebase,
but has the same time and costs
associated with it, still isn’t
possible. At best, it’s likely that
a 30% saving from the cost of
two native apps is possible,
depending on app complexity
and the number of supported
devices required.
Native applications still provide
the best user experience, are the
easiest to support and maintain,
and offer the most stability
where longevity is concerned.
Conclusion
www.apadmi.com
We’re experts in mobile
technology.
Since we began in 2008, we’ve
built mobile apps and solutions
for some of the UK’s biggest
brands, including the Co-op,
BBC, NHS, EE and Argos. We’ve
also recently collaborated
with Amazon, hosting a
number of tech lunches and
skill workshops across the UK
to educate people about the
revolutionary enterprise uses of
voice recognition technology
like Alexa.
We’re passionate about all
things technology, recently
expanding to include two
new business arms. Apadmi
Ventures seeks out new and
exciting technology start-ups,
providing them with everything
from financial investment to
technical expertise to help them
get
off the ground.
Apadmi Labs, our research
and development experts, aim
to discover new and more
effective ways of working using
technology such as artificial
intelligence and machine
learning.
We create.
We innovate.
We invest.
We’re Apadmi.
We create extraordinary mobile experiences
© Apadmi Ltd 2018 0118/LA