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