Cross Platform Mobile Development – An Opinionated ... - Rex St John

quarterceladonMobile - Wireless

Dec 10, 2013 (4 years and 7 months ago)


Cross  Platform  Mobile  Development:  An  Opinionated  eBook
Rex  St  John
Choosing Your Mobile Platform: It’s Complicated



Emptive Apology



Goals Of This Document



Cross Platform Mobile Devel
opment: Why It Matters



Going Native

Pros and Cons



Cross Platform Solutions

Pros and Cons



Hybrid, HTML5 and Mobile Web Applications



Native Single Platform Solutions

Pros and Cons



Javascript Overload



Your Cross Platform Design Strategy Is Of Utmost Importance



“It Just Feels Wrong.” Save Time Res
pecting Your User’s Platform Choice



A Technical Argument For Following Design Guidelines



Principals Of Mobile Platform Selection



A FAQ For Selecting A Technology Platfor



Choosing Your Mobile Platform: It’s Complicated

This month I have been asked at lea
st a dozen times by different startups, clients and fellow
engineers about cross
platform mobile technology solutions like PhoneGap, Titanium,
RubyMotion, Flex 4 (AIR for devices),

and others. Are they good? Should I use them? Why
should I pick one ov
er another? Should I go native?

Sprinkle on top of this the meteoric rise of Javascript MVC frameworks like Backbone.js,
AngularJS, Sencha Touch, jQuery Mobi
le and Ember.js. The number of possible configurations is

After answering


in numerous ways, I decided to do what comes natural for every
software engineer: Automate my response by assembling a definitive document

I can hand
over to anyone
searching for answers

Emptive Apology

I will almost certainly leave out yo
ur favorite technology platform, language or solution. There are
too many for me to even possibly
This document contains a collection of

data points

(facts and opinions)

to consider in making a choice that is ultimately yours.
Read the links and
think for yourself.

Cross  Platform  Mobile  Development:
An  Opinionated  eBook
Rex  St  John
Goals Of This Document

I am not writing this to promote any specific solution though I have tried and built products with
many. What I do want is for you to save time, headaches and money by helping you m
ake an
informed choice about how to approach the problem of mobile platform selection.

Above all I want to emphasize that design and user experience choices are economic choices.
Picking the wrong design will cost you time and money. Picking the right de
sign and combining it
with the wrong platform will cost you time and money. Your engineers will struggle to make a
design which is not suited for a given platform work.

Your users may hate the result.

The best option you have is for your engineers to review all designs for technical feasibility before
attempting to go into prod

and square them thoroughly with the design guidelines provided
for each platform (and general good UX sensibility).
More on that later.

Cross Platform Mobile Development: Why It Matters

Generally these articles start with

some sort of discussion about why the topic is important so I
start there.

Two things. First:
Software is eating the world
. Second,
mobile software is eating software
the web
nd your TV
and your game console

your watch
nd your thermostat
and your
smoke detector
and your car
…(you get where I am going with th
is by now).
In short: the number
of platforms is large, the amount of development resources is scarce and the amount of money to
be made is staggering.

With all these possible mobile devices wouldn’t it be great if you could write one application and
oy it everywhere?

Who has the design and development resources to possibly individually
target all of these devices?

These are
good questions.

Every client

or CEO

in the world gets a far away, dreamy look in their eye when they hear the
words: "Write once
, deploy everywhere." To them it means market share, it means getting $5 of
value for every $1 spent

on design and development

However, this promise comes with a serious
array of caveats


need to be considered
Too often, the promise of cross

compatibility comes with a high cost (with some exceptions, especially games).

Going Native

Pros and Cons

All native

is one of the first strategies you will probably consider. Y
ou simply use the tools
provided by Microsoft, Google, Apple or Amazon to

build your application exactly to a respective
mobile operating

system such as Android or iOS.
The Pros of going “all native” are numerous.

Cross  Platform  Mobile  Development:  An  Opinionated  eBook
Rex  St  John
Lets begin with the obvious: When you use technology tools provided directly from the source,
you get much faster t
urn around times and more reliable support.
giants have learned
to be kind to their application developers
. Google and Apple

and often release beta versions of


changes months in advance to give
application creators

ample time to adop
t new
standards, user interface practices or integrate advanced new features

Tech giants like Apple or Microsoft

often produce the best
development tools for their own
For example,
includes advanced features for dealing with dynamic layou
managing Core Data, testing applications in a simulator and more. Google has partnered with
IntelliJ to create
Android Studio


has a number of Android specific features to ease

creation of Android Apps.
The same is true of Windows Phone.
Overall, g
oing native

getting excellent development support for your platform of choice.

Going “All Native” has design implications as well. Each mobile platform has extensiv
e design
guidelines that, if followed, can speed application design and development.
I will go into the
design part of the equation later on.





do not occur on any other platform. Apple
recently introduced A
irDrop and multi
peer connectivity

on iOS 7 for example
. For a long time,
free GPS directions were only available on Android through Google Maps. You could build an
entire empire by cleverly using

specialized features of each platform.
If your applica
requires these features, your choice



been made for you.

Finally, and more qualitatively, in my experience the most advanced class of developers tend to be
extremely platform centric. They prefer to select and master a very specific te
chnology stack
because it speaks to their entire life philosophy. Convincing developers of this type to switch into
a different realm is like attempting a classically trained cellist to take up the trombone.

Platform selection is not always just a practic

it is partially a “soft power” choice.
Developers who care about open source are drawn to Google or solutions like RubyMotion and
eschew Apple

or Microsoft
. Likewise, developers who care deeply about perfection and design
often gravitate natural
ly towards Apple and cannot be separated from XCode.

Ok, there are some notable cons to going All Native: You will only get one application when you
are done which can only run on a single platform. In addition to that, I have heard it said that
HTML5 bas
ed solutions and perhaps some of the cross
platform tool sets may allow much faster
turn around times and, in some cases, may be valuable for prototyping purposes. If your goal is to
et to a testable product increment and time is important, you might wish
to consider alternatives
to going all native.

Cross  Platform  Mobile  Development:
An  Opinionated  eBook
Rex  St  John
Cross Platform Solutions

Pros and Cons

Through the magic of cross
compilers we are provided with

of solu
tions such as
MonoTouch, Unity3

and Titanium which allow you to write your application in

a language of
your choosing and then compile to native code

for a specific platform
. This carries with it a
number of benefits including the ability to program in a language of your choosing while being
able to target and distribute on any number of othe
r platforms.

The clear benefit of these solutions is that you can market your application to a much wider
audience across a much wider range of devices and not have to worry about getting tied down to a
single platform.

There are some downsides. Flex 4

and AIR for devices provide

a great example of how
these types
of solutions

can go wrong.

Many application developers built apps using AIR only to see Adobe
drop support for the platform and effectively “orphan” these applications for future

Yes, I know Adobe “Open Sourced” Flex…sort of like how Old Yeller was taken
behind a shed and “Open Sourced” after being bitten by a rattlesnake.

By choosing a 3


solution, you rely on the provider of your technology stack to keep pace
with the r
apidly changing array of mobile operating systems, devices and features as they occur in
real time.
You may not get access to the latest and greatest features introduced by Apple,
Microsoft or Google because you have to wait until all platforms adopt these

features before they
will be supported

Can you afford to never be quite on the “cutting edge” of what these platforms have to offer?
that how you plan on competing against the 900,000 apps in the iOS app store or the Google Play

Even more s
inister are device
specific and operating system version specific annoyances. Your
app might look wonderful on one version of Android and look awful on another version. Your
splash screen may look perfect on an iPhone but not render properly on an iPad. Yo
u will almost
certainly encounter niggling detail problems like this no matter how hard you try on many
common cross
platform solutions where the end product is compiled into native code. These
details can add up and turn into maddening quality control pro
blems as you integrate
increasingly more advanced UI and animations into your user interface. Beware.

Finally, you must arrive at a design that respects all platforms and provides a consistent, useable
user experience which does not confuse the users of e
ach individual platform your application
appears on.

Design practices

exist on Android often

do not work on iOS or Windows and
attempting to find that happy design medium will prove to be nearly impossible.

I wanted to make a special note on the topi
c of Unity3D.
Generally speaking, video games can and
often do implement very customized user interfaces

and user experiences. Unity3D does not rely
on any platform specific user interface controls and is therefore immune to many cross
Cross  Platform  Mobile  Development:  An  Opinionated  eBook
Rex  St  John
which might occur when trying to do something like compile Javascript into
C to make use of UIKit controls.

Unity provides a host of powerful gaming

add tremendous value to game developers. The fact that Unity applications ru
n in a
separate runtime means that your Unity game may be immune from a number of problems which
will occur in other solutions like Titanium

or PhoneGap

Hybrid, HTML5 and Mobile Web Applications

Here is the part where I will risk setting off the most
rous of possible flame wars

so I will
proceed with great caution.

I have worked on some very high profile PhoneGap applications and
spoken with a lot of fellow engineers in the space who are much more advanced Javascript and
HTML5 developers than I can eve
r hope to be and I will share what I have gathered.

This is a topic that is particularly heated by the array of business interests who have a collective
stake in promoting their individual visions for the future of application development. Some of the
ormation available online may be categorized as a form of evangelist propaganda so I
recommend doing thorough research of your own in addition to reading this passage. Think about
who is promoting the message and why they are promoting that message before
making up your

It is possible to create very attractive, useful HTML5 applications for mobile devices and then
make the claim that HTML5 is “ready.” However, you have no way of knowing the amount of
engineering and corner cutting which has gone into

producing these showy apps nor do many of
them come with counter point applications comparing the difficult of creating those same apps
In some cases, you can arrive at a workable HTML5 application for mobile devices only
by making changes to th
e design of your user experience to avoid features that often prove
troublesome in a web view.

HTML5 promised the world a lot of amazing things and delivered on some of those things.
However, very rich user experiences with engaging support for gestures,

high quality (and
responsive) animation and complex integrated media have been slow to materialize on mobile

From what I have seen, many people who selected solutions like PhoneGap

felt ultimately let
down by the results they achieved and revert
ed back to purely native mobile. You can read one
comprehensive analysis of the state of HTML5 applications
over here
. I won’t r
everything that is written there but I agree wi
th most of it: HTML5 is not a good choice for very
rich, interactive applications…you know, the kind your users expect and the kind that get you
traction in the app store.

Need to display some table
s of data
, images

or show some


forms? Fine, HTML5 can do that.
The second you start introducing advanced gestures,
animations and media things break
You can often

prototype apps much faster in HTML
…but the final polish of the applicatio
Cross  Platform  Mobile  Development:
An  Opinionated  eBook
Rex  St  John

makes it stable, useable and consistent across the board will take much longer than on a
native platform.

A mistake I have seen made several times goes like this: A client is sold a mobile application
design before selecting the technology platfor
m. Inevitably, when presented with the array of
possible choices (all native, cross platform, hybrid) many clients will choose cross
stories over native stories for the marketing reach and distribution. Generally designers will
present a very neat

and “Whizzy” interactive interface with complex animations…wouldn’t you?
However, many of the cross
platform solutions can only deliver on these advanced designs with
extensive QA in comparison with their native counterparts. Never sell a design to a clie
nt until it
has been thoroughly vetted by an expert technical resource. Sanity checking your design in
advance will save you time, money and credibility with your client.

Further readin
g on this topic (in the interest of presenting a balanced viewpoint):

Sencha has vigorously attempted to demonstrate the viability of HTML5 as a mobile application
choice by rapidly building and deploying
a mobile version of Facebook called FastBook

to combat
statements made by
Mark Zuckerberg to the effect that HTML5 is an inferior mobile platform
. I
encourage you to take a look at the project, read their opinio
ns and see what they have to say.

Another high profile break up with HTML5 came from Linkedin. You can read about their

Overall my feeling is this:

Can you fin
d 25 examples of people doing amazing graphical things in HTML5 on mobile

? Probably. Did those people have to struggle immensely and make design sacrifices
Probably. Will those amazing experiences look and work great on a wide swatch of mobile d
and operating systems

without an unholy amount of testing and QA
? Probably not.

There are million
s of applications in the market;

your users are spoiled by an array of extremely
high quality competition. Can you afford to provide them with merely a
n “ok” user experience
while your competition is providing deep, immersive, interactive, responsive applications to
compete against yours? That is the


problem with HTML5 web apps.

Native Single Platform Solutions

Pros and Cons

I don’t have

a good phrase for this type of solution but generally speaking they allow you to do
things like write iOS or Android applications using another language like Ruby.
, for
example, is a project created by

a former Apple employee that allows you to create your entire app
using Ruby. The converse of this might be a solution like
Ruboto for Android
. It doesn’t have to be
Ruby, it could also be Python, C# or some other langua

Cross  Platform  Mobile  Development:  An  Opinionated  eBook
Rex  St  John
These solutions have problem

in common with other cross
platform application development
. Often

you will not be able to make use of advanced plat
specific IDE

they are not updated as quickly as they need to be. Often the promises they make are not entirely
delivered on.

Again, you are relying on someone’s second hand implementation of a large, complicated
operating system develo
pment environment. If the underlying operating system changes and
adds a bunch of new features, you might be left waiting for long periods of time for support for
those features to arrive.

Apple, Google and Microsoft are the final, ultimate authorities on

their respective mobile software
operating systems and tools. If you get your tools second hand, you run the risk of being left
behind or not supported as
fully in the future.

My experience with tools such as these has been limited to watching frustrate
d engineers throw
dilapidated application source code out and replace it with fully native code while cursing the
name of the engineer who left behind the mess

they are being forced to clean up. It could
happen to you.

The only way I could truly advi
se anyone use these
single purpose
solutions is if they are a
developer who really, really doesn’t want to learn another programming language and
never plans on sharing your
ication in the context of
a much larger organization.


Everyone who starts writing Javascript immediately takes it upon himself or herself to create a
new Javascript MVC framework. This has resulted in millions of Javascript frameworks. By the
time I finish writing this sentence, there will probably b
e 15 new ones with cool names like
zomg.js and narwhal.js. Attempting to write about them
is a pointless task.

I will say that, generally speaking, the core of your decision is configuration vs. flexibility. A
framework like AngularJS gives yo
u less and allows you to customize more. Frameworks like
SproutCore or Ember or Sencha gives you a lot and you must learn a lot to be productive.

So what do you want to spend your time doing? Rolling your own framework out of

components o
r learning a larger framework that does everything for you (provided you
can figure out how to do it?).
You decide.

Any of these frameworks can be combined with PhoneGap or other common mobile
solutions to produce front
end interactivity and funct
ionality. Or you could write your own like
everyone else. It’s up to you.

Cross  Platform  Mobile  Development:
An  Opinionated  eBook
Rex  St  John
PhoneGap applications I have been involved with often rolled together a half dozen different
Javascript utility libraries and glued them together with some sort of intermediary stru
cture to
make it all work together in a rational way. In short, you will have to mix, match and combine
different libraries to find what works for you.
Beyond that I cannot comment because these
individual libraries are likely maintained and updated indepe
ndently by their respective
communities and anything
about them is subject to change on a day
day basis.

Your Cross Platform Design Strategy Is


“Most  people  make  the  mistake  of  thinking  design  is  what  it  looks  like.  People  think  it
this  veneer  

that  the  designers  are  handed  this  box  and  told,  ‘Make  it  look  good!’  
That’s  not  what  we  think  design  is.  It’s  not  just  what  it  looks  like  and  feels  like.  Design  
is  how  it  works.”  

Steve  Jobs

with a Big D

e.g. compr
ehensive user experience design as opposed to a more narrow
conception of design restricted to just making icons and business cards)

is the single thing which
bridges all of your applications, regardless of what platform you are on.

You will probably have

the same colors, branding, features and functionality that compels your
users to choose your product and represents the value your company provides to the world across
every website and mobile app your company creates.
Therefore, it is highly logical to
nclude a
treatment of

cross platform design as a topic.

Cross platform mobile product make

design, which is alre
ady famously hard, even harder for
several reasons.

First, m
obile is infested with warring technology giants who are very opinionated about h
ow they
want things done on their respective platforms: Microsoft, Google, Samsung, Amazon and Apple
are a few of the most notable ones.


and every one of these platform
s wants to do things "Their way.

Apple has voluminous user
experience guidelines

so does Android
so does Windows Phone

nd if you don’t follow them,
you may run the risk of outright rejection of your hard
written application regardless of how long
you spent on it.

This cross platfo
rm “design warfare”
will almost certainly

impact your design


Second, the supply of excellent user experience designers is low…perhaps even lower than the
number of engineers on the market. I have anecdotally heard numerous industry contacts
ain of shortages in the availability of excellent product designers.

A user experience
designer who was trained and skilled for working on the web must be retrained to work on

Cross  Platform  Mobile  Development:  An  Opinionated  eBook
Rex  St  John
Third, the tec
hnologies supporting the design guidelines for each platf

are often rigid and
platform design guidelines almost always increases the amount of development
time and resources required to build your application.

must realize that
mobile d
decisions are ECONOMIC decisions


how your de
veloper will spend their time
, not just pretty
pictures in Photoshop.

Fourth, cross
platform technologies that can compile and work in multiple platforms often do not
provide complete support for many native functions or controls that might appear on one
platform but not on another. The result is that no matter what you do, your cross
application will be some sort of “middle
ground” design wise between all the platforms you are

This middle ground bears with it the potential to be a dan
gerous “no mans land” of mediocrity
where you please no one by attempting to reach everyone. There are millions of apps combined in
all of the world’s various app stores

trust me when I say
it is


far better to have a great
app on one platform t
han an “ok” app on all platforms

unless your end user is obligated to install
as in the case


internal enterprise app
lications specific to a single problem domain


It Just Feels Wrong
Save Time

Your User’s
Platform Choice

sers of a given mobile platform have been trained to expect a certain set o
f user interface
controls, patterns and gestures. If you deviate from the guidelines of a platform, you run the risk
of confusing, annoying and losing your users.

Your Android user

is an Android user because they liked the way Android felt to them. Your iOS
user is an iOS user because they like the way iOS looks and feels. If you give them an Android
experience on their iOS device, you may annoy them.

our iOS user has 900,000 othe
r iOS applications to choose from. When an application annoys
them, they uninstall it within seconds and find a better application. Respect your user’s platform
choice or




A Technical Argument For Following Design Guidelines

If y
ou get the sense that I am harping on this point, it is because I am harping on it. I can not
warn enough against haphazard design of mobile applications. Again: Designing your mobile
application without regard to design guideline
s will cost you time and
money, especially if you
have selected to go ‘native’ as your cross platform strategy.

Cross  Platform  Mobile  Development:
An  Opinionated  eBook
Rex  St  John
Below are some images of standard Android menu interface patterns. You will see a floating white
menu options list floating over a greyed out background and an example o
f a drop down
“popover” menu

loads from an icon in the Android Action Bar

and hovers over your view
when you open it

These look straightforward

but none of these design controls or patterns exist natively in the
main competing platform iOS. In

fact, if your designer attempts to shoe horn these patterns into
Cross  Platform  Mobile  Development:  An  Opinionated  eBook
Rex  St  John
your iOS application, you will inevitably waste development time coding custom iOS controls or
integrating with a 3

Party library which has already done the work for you.

The software too
l kits underlying mobile application user interfaces
(UIKit in the case of iOS)
were coded to look and work a certain way. If you attempt to design an Android style application
build it for the iPhone, you will do more work and spend more time and mone
y. You may also
run the risk of having your application rejected entirely.

At the very least, your user will say to themselves: “This doesn’t feel right” when they use your

My advice

if you plan on adopting “all native” as your mobile technology appr
: Make sure
your designer spends high quality time reading, internalizing and memorizing the user experience
guidelines for the platform

you intend on targeting
This study period has the potential to save
you a lot of time and money and will almost c
ertainly improve your end product.

If you are going the HTML5 route, do not design your application like a website and do your best
to adhere to standards which have been widely adopted for making items touchable and

with fingers

while being

on small screens
. No blue links.

If you are selecting a cross
platform solution then find a nice middle ground

makes sense
across all devices…it is unlikely that you will be able to please everyone.

Principals Of Mobile Platform Selection


Respect your user

s choice of platform


Always vet design with engineering to avoid unnecessary work


Obey native platform guidelines when going all native, they will save you time and money
and increase your applications


Native is nearly always the


solution for a variety of reasons

for most UI based

with the
exception of games
. Best does not mean


to develop

easiest to develop



It means you will get a more reliable end product with
much greater technical support
, high end
product polish

and better overall reliability for


Use cross
platform solutions for prototyping in general or when facing limited budgets,
very basic designs

(low in
intensive animations or media)

or need rapid turn ar


With greater cross
platform reach comes greater need for quality control and extended
polish time across many device
. You may save time up front but you will lose time when
attempting to get cross
device polish

when using HTML5 or a solution like Titanium


Native platforms nearly always have the best tools and support
(except for possibly


It is
nearly always
far better to have a great application on a single platform than a
mediocre application on many platforms given the volume

of competition

in most app


Apple, Google and Microsoft (or other platform provider) are the ultimate authorities for
their respective platforms. Using a th
ird party solution will always result in added risk for
product stability and functionality
. Its like playing Chinese telephone with
Cross  Platform  Mobile  Development:
An  Opinionated  eBook
Rex  St  John
extremely sophisticated technology platforms

things get lost along the way or


Advanced platform features, gestures and UX patterns help your
applications stand

from the crowd. Cross
platform application
by its nature

may slow

from using advanced
, differentiated

features of any single platform


No matter how hard you try, HTML5


apps will never feel

or work

like native
. Your us
ers will know it instinctively


All of the above is highly subjective

and contextual



For Selecting A Technology Platform

Time to decide? Answer these ques
tions for yourself.

Do you require advanced media features (sound, gestures, multitasking,


Go native


Use Unity3D


Avoid HTML5

Are you making a prototype?


HTML5 is good for creating something that works very quickly


Native solutions often take more ti
me to spin up

Is your only available engineer a





Sounds like your choice is already made for you.

Are you making a game?


Go native or use Unity3D. Unity is pretty awesome.


Game support has generally increased acros
s platforms for iOS, Android and
Kindle and there are many available native game frameworks

Does your user need to install and use your application because it is an
enjoyable application to use?


Go native

or use Unity3D

Can you dictate the use of the application to your
end user e.g. many
enterprise situations where the user needs to use the app for work?


You can probably get away with

a solution like

HTML5 in some cases provided
the application is useable

Is your design super fancy?


Go native.

Is your design very table / content viewing

oriented with low interactivity /
media needs?


You can probably get away with a common cross platform tool set like Titanium
and your user won’t mind

Do you hate learning new things?


Use RubyMotion or some other platform

lets you write your exact la
of choice

Limited funds?


Cross platform solutions

but keep in mind it will effect the design of your app


Again, it is better to have a really good app on one platform than a mediocre app
on many platforms



Yes, I know. You’ll g
et over that feeling after trying to figure out why your
advanced interface is dysfunctional on half of the Android devices you test it on
while working perfectly on the other half.