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

quarterceladonMobile - Wireless

Dec 10, 2013 (3 years and 8 months ago)

74 views

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

................................
.........

1

Pre
-
Emptive Apology

................................
................................
..............

1

Goals Of This Document

................................
................................
..........

2

Cross Platform Mobile Devel
opment: Why It Matters

................................
....

2

Going Native
-

Pros and Cons

................................
................................
...

2

Cross Platform Solutions


Pros and Cons

................................
...................

4

Hybrid, HTML5 and Mobile Web Applications

................................
.............

5

Non
-
Native Single Platform Solutions


Pros and Cons

................................
.

6

Javascript Overload

................................
................................
................

7

Your Cross Platform Design Strategy Is Of Utmost Importance

.......................

8

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

........

9

A Technical Argument For Following Design Guidelines

................................

9

Principals Of Mobile Platform Selection

................................
.....................

11

A FAQ For Selecting A Technology Platfor
m

................................
..............

12


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),
Moai

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
staggering.


After answering
these

inqu
iries

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

I can hand
over to anyone
searching for answers
.

Pre
-
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
consider
.
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.


2
 
Cross  Platform  Mobile  Development:
 
An  Opinionated  eBook
 
Rex  St  John
 
 
 
2
 
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
uction

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
will
start there.


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

your watch
,
a
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
depl
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

that

need to be considered
.
Too often, the promise of cross
-
platform

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
 
3
 
 
 
3
 
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.
Technology
giants have learned
to be kind to their application developers
. Google and Apple

and often release beta versions of
upcoming

OS

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
products
.
For example,
XCode
includes advanced features for dealing with dynamic layou
ts,
managing Core Data, testing applications in a simulator and more. Google has partnered with
IntelliJ to create
Android Studio

and

has a number of Android specific features to ease

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

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.


Most

platform
s

have

differentiated
features
that

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
the

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

already

have

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
al
choice;

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.

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


Pros and Cons

Through the magic of cross
-
compilers we are provided with
are
classes

of solu
tions such as
MonoTouch, Unity3
D

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
developments.

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
rd

party

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?
Is
that how you plan on competing against the 900,000 apps in the iOS app store or the Google Play
store?

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
that

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
-
platform
Cross  Platform  Mobile  Development:  An  Opinionated  eBook
 
Rex  St  John
 
5
 
 
 
5
 
annoyances
which might occur when trying to do something like compile Javascript into
Objective
-
C to make use of UIKit controls.

Unity provides a host of powerful gaming
-
specific
tools
that

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
vigo
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
inf
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
mind.

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
natively.
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
devices.


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
egurgitate
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

input

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

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

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
-
platform
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
experience
here
.

Overall my feeling is this:

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

(and
web)
? 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
evices
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

potential

problem with HTML5 web apps.

Non
-
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.
RubyMotion
, 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
ge.

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

in common with other cross
-
platform application development
tools
. Often
,

you will not be able to make use of advanced plat
form
-
specific IDE
features;

often
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
that

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
n
individual
developer who really, really doesn’t want to learn another programming language and
never plans on sharing your
appl
ication in the context of
a much larger organization.

Javascript
Overload

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
individually
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
lesser
-
featured

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
-
web
-
app
solutions to produce front
-
end interactivity and funct
ionality. Or you could write your own like
everyone else. It’s up to you.

8
 
Cross  Platform  Mobile  Development:
 
An  Opinionated  eBook
 
Rex  St  John
 
 
 
8
 
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
-
to
-
day basis.

Your Cross Platform Design Strategy Is
Of

Utmost
Importance

 
“Most  people  make  the  mistake  of  thinking  design  is  what  it  looks  like.  People  think  it
’s  
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
 
Design

(
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
i
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.

E
ach

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

a
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

choices
.

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
compl
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
mobile.


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

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

You
must realize that
mobile d
esign
decisions are ECONOMIC decisions

for

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
-
platform
application will be some sort of “middle
-
ground” design wise between all the platforms you are
targeting.

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

generally

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

of

internal enterprise app
lications specific to a single problem domain

or
organization
.


It Just Feels Wrong
.”
Save Time
Respect
ing

Your User’s
Platform Choice

U
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.

Y
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

risk

get
ting

uninstalled.

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.

1
0
 
Cross  Platform  Mobile  Development:
 
An  Opinionated  eBook
 
Rex  St  John
 
 
 
10
 
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
that

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
 
1
1
 
 
 
11
 
your iOS application, you will inevitably waste development time coding custom iOS controls or
integrating with a 3
rd

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
and
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
app
.

My advice

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

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
intractable

with fingers

while being
readable

on small screens
. No blue links.


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

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

Principals Of Mobile Platform Selection


1.

Respect your user

s choice of platform
.

2.

Always vet design with engineering to avoid unnecessary work
.

3.

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

4.

Native is nearly always the

best


solution for a variety of reasons

for most UI based
application

with the
possible
exception of games
. Best does not mean

fastest

to develop
,



easiest to develop


or

cheapest.


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

and better overall reliability for
your
application
.

5.

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
ound
tim
es
.

6.

With greater cross
-
platform reach comes greater need for quality control and extended
polish time across many device
s
. 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

7.

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

8.

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
stores
.

9.

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
future
product stability and functionality
. Its like playing Chinese telephone with
1
2
 
Cross  Platform  Mobile  Development:
 
An  Opinionated  eBook
 
Rex  St  John
 
 
 
12
 
extremely sophisticated technology platforms

things get lost along the way or
overlooked.

10.

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

out
from the crowd. Cross
-
platform application
development
by its nature
,

may slow

you
from using advanced
, differentiated

features of any single platform
.

11.

No matter how hard you try, HTML5

web

apps will never feel

or work
exactly

like native
apps
. Your us
ers will know it instinctively
.

12.

All of the above is highly subjective

and contextual
.

A

FAQ

For Selecting A Technology Platform


Time to decide? Answer these ques
tions for yourself.




Do you require advanced media features (sound, gestures, multitasking,
3D)?

o

Go native

o

Use Unity3D

o

Avoid HTML5



Are you making a prototype?

o

HTML5 is good for creating something that works very quickly

o

Native solutions often take more ti
me to spin up
.



Is your only available engineer a

platform

P
rima

D
onna?

o


Sounds like your choice is already made for you.



Are you making a game?

o

Go native or use Unity3D. Unity is pretty awesome.

o

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?

o

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?

o

You can probably get away with

a solution like

HTML5 in some cases provided
the application is useable
.



Is your design super fancy?

o

Go native.



Is your design very table / content viewing

oriented with low interactivity /
media needs?

o

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?

o

Use RubyMotion or some other platform
that

lets you write your exact la
nguage
of choice
.



Limited funds?

o

Cross platform solutions

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

o

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



But…HTML5!

o

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.