
Titanium vs Phonegap vs Native application development - goyalpulkit
http://www.sapandiwakar.in/technical/api-research-study-iphone-and-android-applications/
======
M4v3R
I'm currently developing an app, targeting both iOS and Android, using
Titanium. So far it's going great - I have one codebase with only a few
platform specific branches for UI, and completely platform independent
business logic.

It's remarkable how little code you have to write to achieve good results with
Titanium. Plus, contrary to what article saids, you CAN use external
Javascript libraries, but they have to be adopted to CommonJS before usage.
There are also many components written by the community.

The downside of Titanium is that they don't cover 100% of APIs that both
platforms provide. For example, there is no Radio Button / Radio Group APIs
for Android, you have to invent your own solution. I'm sure there are more
gaps like this. But even considering this, you'll probably end up having a
working prototype much faster using Titanium.

Edit: For anyone more experienced - is there a better Android emulator out
there? The stock one is _painfully_ slow, compared to iPhone Simulator.

Edit 2: Developing with Phone Gap seems attractive, but then you dive in and
discover that you have to either load up enormous UI library to mimic native
behaviour (which always is far from perfect) or reinvent the UI and touch
mechanics yourself. Ouch.

~~~
briancooley
In my experience, the best way to test Android is on device(s). You're going
to want to test on device anyway, and it's very easy to do, so just skip the
emulator.

Keep in mind that the iOS Simulator is a simulator, not an emulator. You'll
have the full CPU and memory of your dev box, so there will be a fair number
of bugs that occur on the device but you won't see in the simulator.[1]

[1] A tool that's useful for testing in the iOS Simulator is Network Link
Conditioner, which allows you to simulate 3G connections on your dev box. You
can download it from developer.apple.com through your developer account. From
XCode: click on the menu item XCode>Open Developer Tool>More Developer
Tools... and you'll be taken to a web page with a downloadable disk image
containing the Network Link Conditioner Systems Preferences pane under
Hardware I/O Tools.

------
Zigurd
The article just brushes the surface of these issues:

Web applications are appropriate for information applications. Not a surprise,
since the Web originated in hypertext. Web apps are good for presenting and
navigating ad hoc multimedia information. If the target of a Web app is
appropriate, a Web app will be the least expensive way to go.

Native apps produce the best looking, most touchable, and fastest apps, but be
ready to pay to get results that are significantly better than a Web app. Make
sure you are doing something that requires direct manipulation, and that takes
advantage of how the underlying OS works. On Android, for example, make sure
your app takes advantage of Android's fragment-based UI features, inter-app
cooperation, and device hardware, if applicable.

Cross-platform panacea SDKs like Titanium result in lowest-common-denominator
apps. If you are considering Titanium, you should probably make a Web app.
There is only a narrow category of apps for which cross-platform SDKs yield
the best result.

~~~
user49598
Disagree, Titanium is not lowest common denominator. It takes a stance that
you should develop your UI specifically for the deployed platform but gives
you a consistent api for doing so.

With titanium the vast majority of your applications logic is un-touched
between platforms and you generally have about 50% reusable front-end code.

If you structure your application properly, swapping out UI pieces by platform
is simple.

~~~
Zigurd
User interface is only the surface manifestation of OS architecture. Both
Android and iOS have very distinctive userland technologies layered over open
UNIX-like kernels. While a cross-platform SDK might give you access to almost
all of both platform features, it is very unlikely to be able to abstract
those features in a way that results in portable code.

For example, Android's component-based app architecture runs very deep in
Android implementations. If you subvert it, or plaster over it with an
abstraction, you lose the ability to minimize your app footprint by having
relatively small components "destroyed" or swapped out of memory in Android's
unique approach to making Java memory management work across component and
process boundaries.

Windows 8 for mobile devices is yet another distinctive OS, with a unique
kernel and similar, for still very distinctive managed language runtime, plus
legacy compatibility.

We're in an era of OS and managed language runtime innovation. Each one is
striving to provide the optimal feature set, and that often involves the way
in which apps and components of apps communicate and cooperate. plastering
over the semantics of those large and deep architectural differences is going
to result in a lowest common denominator result.

------
cageface
I'd expect an article with this title on the front page of HN to offer a bit
more than the obvious bullet-point rundowns of each of these approaches.

------
ziggamon
Been using Titanium extensively in the company I run, and to this day it has
been the biggest mistake we've done, followed by not migrating away from it
soon enough.

Every win you get for "writing code only once" you pay for tenfold (at least)
in working around quirks, lack of documentation, unsupported native API's,
performance issues, building issues, unannounced API breakage, etc, etc etc.
On iPhone it's bareable, although far from pleasurable. Android is to this day
barely beta quality despite the company claiming "hundreds of thousands of
developers".

Custom modules can usually be built to work around core stuff not working, but
involves "guess and try" programming for a long time, as not all APIs are
documented/exposed.

Bug reports lie around for months and years, sometimes really critical ones
that break major functionality. Pull requests in github also lie untouched for
indeterminate amounts of time.

In fairness, things have gotten much better in the last year, but still far
from being workable, and to anyone thinking of building anything bigger than a
quick prototype of anything in Titanium I'd suggest to rethink, and do a quick
Google, that would reveal the hordes of frustrated people and bad reviews.

------
icoder
I was kind of hoping for an article that actually started where this one ends.
Since I run a mobile focused startup, I think a lot about what to put your
money (well, time actually) on: PhoneGap / Titanium / native (or simply web
browser based).

PhoneGap seemed like a wonderful thing when I first started working with it.
Even if speed is not an issue, the 300ms click delay is, and so are all the
hassles to get around this and around other peculiarities. And that's only
when testing on a single platform. Same holds true of course for in-browser
apps. So far I found myself spending way too much time on debugging and coming
up with workarounds. The problem being that the more freaky you get with
JS/HTML/CSS, the less compatible things will get, so the more time will be
spent debugging.

My current opinion about this matter is: I'd rather spend this time on coding
the whole thing twice. This is of course, all under the assumption that
Android + iOS support will do.

Yes, then there's Titanium. I haven't tried it. But as with PhoneGap, I think
that adding an abstraction layer creates a dependency, and this by itself is a
downside (which requires justification). I feel that once you're working with
native UI, you could just as well work with 'native' IDE & code, because that
brings you much closer to the actual system (and benefit from its strong
points) and you are not limited to whatever has been opened up for you by the
abstraction layer. But I've been coding since I was like 8, and I already
worked with Java a lot. So adding one more language seems doable.

But perhaps I should try Titanium first before using it. Then again, trying
takes time that could also be spent on learning objective C.

So, that's basically what I would have liked someone else his/her perspective
on, something I miss in the article.

------
marknutter
The article offers little value, but I'm always interested in conversation
about this topic so I'll add my experiences here:

I'm on a contract with a company that has run the full gambit of mobile
strategies over the past year. They started out by outsourcing native
development of their mobile app overseas. After about 9 months of development
they determined that for whatever reason, whether it be communication issues
or poor product planning, the apps weren't where they wanted them to be so
they decided to do a complete 180 and go with the HTML5 approach, which is
what I've been working on.

We decided to go with the Sencha Touch framework because it's the most
complete native-style mobile framework out there today. We've managed to
recreate the native apps in just over 2 months, which is impressive
considering it was a rewrite from scratch. A week ago we submitted to the app
store and it was approved by Apple.

Performance on the iPhone 4s is surprisingly close to that of a native app,
which gives me hope for the future of the phonegap approach. Phones and
javascript engines are only going to get more powerful, so in a few years this
experience should be ubiquitous for most people.

However, we're at a point in time where there are a lot of older devices,
mostly running Android, that don't run HTML5 apps as nicely as they do native
ones. For instance, our app is very usable on a 2 year old Android, but
scrolling isn't very smooth and transitions are mostly non-existant due to the
fact that hardware accelerated CSS3 animations aren't supported. I should
mention that our app is mostly data (it's a productivity/collaboration app),
so that helps.

I'm primarily a web developer but I've started diving into native iOS
development for a side project where UX is more important. Native development
isn't as bad as I had feared, but it certainly takes more time. If you're not
very good at it, you'll end up with an app that really performs no better than
what could have been done using HTML5. Bad code is bad code, no matter what
it's written in. What keeps me from being sold on the native approach is the
increasing fragmentation we're seeing on the marketplace. The thought of
having to maintain three separate code-bases for Android, iOS, and Windows
Mobile gives me cold sweats. Sure, there are strategies for sharing the basic
logic between the three, but not nearly as turn key as simply dumping the code
into Phonegap like we've done with our Sencha app.

In my humble opinion, given that we've seen near native performance on
bleeding edge devices, I think that native apps will only be necessary for
games and intensive content creation apps like iMovie and iWork. The vast
majority of the apps out there today would work just as well as HTML5 apps.

~~~
rimantas

      > The vast majority of the apps out there today would work
      > just as well as HTML5 apps.
    

Except that you will need to load a bunch of frameworks to get the
functionality which iOS already provides.

~~~
marknutter
Not a "bunch of frameworks". In our case, just one, that being Sencha Touch.

------
vlucas
I've worked with Titanium extensively, and a lot of this article is just plain
wrong regarding Titanium. It seems like Sapan just read some older docs or
articles on Titanium and did a write-up for traffic.

* Titanium uses the V8 JavaScript engine on both platforms (not JavaScriptCore or Rhino anymore)

* Titanium does not support the Windows phone platform (at least not yet), and the desktop app support has been discontinued so it technically doesn't even support Windows anymore either

* Titanium also produces Web/HTML as as output target for mobile web sites if desired (with little/no code changes)

* You can still embed webviews if you want and make "web wrapper" apps, just like PhoneGap (so yes HTML and CSS IS possible)

* Using external JS libraries IS possible, and is highly encouraged through the use of CommonJS modules

I appreciate comparison articles for the sake of the discussions that follow,
but this much bad information is just not excusable.

~~~
sgt
Be warned though, it's not easy to debug the embedded webviews. I put some
HTML5-based charts into a Titanium app and it took so long that I wished I'd
gone full native ObjC from the get-go.

------
unwind
I realize this is a bit nit-pickery, but the text has a bunch of broken smart-
quotes in it that makes it really hard to read.

------
dclowd9901
My choice to go with Phonegap really comes down to the capabilities I want the
app to have. If I only really need a wrapper that gives access to a camera
(hell, GPS even works out of a browser), then an app like Phonegap is more
than enough. And I have no doubt that in the near future, phones will be able
to handily run HTML5 and CSS3.

Really, I think the argument comes down to what do you want your end product
to be, rather than what do you want to have to deal with as you're making it.

~~~
marknutter
> And I have no doubt that in the near future, phones will be able to handily
> run HTML5 and CSS3.

With the iPhone S we're pretty much there. HTML5 apps run beautifully on it.

------
jraines
Just want to point out that you can use external JS libs in Titanium. I use
underscore.js and several others. For simple apps it's a great platform --
you'll hit one or two weird gotchas, but still knock out the app quickly.

When I attempted a larger project though, I wanted to ragequit by about the
12th time I typed a comment like "//Doing it this way because (Date.parse
doesn't work | Retina images don't scale right | the documented API is wrong)"

------
user49598
How is this front page? It's barely informative and not completely correct at
parts.

------
Georgeios
Thank you for point to point study! I am starting to build mobile phone apps
and this post has provided me a nice overview.

