Phonegap (hybrid approach)

Pros

• Ability to develop apps in HTML5 ( means more web devices are captured)
• Overall speed of iterative development is high (it’s almost like refreshing the page)
• Easy to debug (remote WebKit console in Emulator)
• It’s JavaScript!
• Huge amount of JS-frameworks for touch devices (Sencha, iUI, jQuery mobile, iWebkit, etc) ready for use
• Ability to make bindings to native hardware by writing Objective-C plugins
• Good  documentation & large community

Cons

• Overall performance of demos is poor
• Contact list demos with huge amount of data just crash Safari (tested on hardware)
• Building custom GUI is limited by HTML/CSS, there is a huge risk of ending up with unresponsive UI
• A particular weakness of Phonegap is that it’s being migrated into Apache incubator & development/docs seem a bit messy
• Adobe recently bought Phonegap & most probably their focus will shift towards Adobe’s AIR platform

Titanium (native approach)

Pros

• Javascript, no need for Objective-C
• Resulting app is Native!
• Possibility to fully customize GUI
• Produce HTML5 version of your application (works in browser!)
• Ability to write cross-platform code for Android as well (also native!)
• Titanium IDE (a free integrated development environment based on Eclipse, ex-Aptana)
• Ability to make bindings to native hardware by writing Objective-C plugins
• A shift towards iPhone development first (Android comes second) — which is adequate for current market shares of both
• Community & company behind Titanium seems to be pretty responsive
• Appcelerator recently raised 15 million series C funding, which means they are serious about the platformm & will
  continue to improve it
• Appcelerator is known to be largest third-party app publisher on both iOS and Android and is used by companies like NBC, Zipcar, eBay

Cons

• Even though it’s Javascript, you’ll have to learn Titanium mobile API
• Some developers had hard time debugging their apps & catching memory leaks
• Documentation is somewhat messy & not as perfect if compared to Phonegap, however there is a positive improvement trend since the beginning of this year
• A sort of platform lock-in, which means that in the long run it will be way too hard to switch to other mobile technology

Just to make it clear, Titanium does not produce fully native code from your javascript. It does not compile your code to ARM opcodes, what it does, in fact,
is binary javascript interpreter (Webkit’s JavascriptCore on iPhone, V8 on Android)

A note on hybrid approach

By hybrid approach I mean usage of HTML5/javascript with hooks into native iOS/Android API calls.

Of course, both Titanium and Phonegap fall into the category of “hybrid” but the key difference is implementation:
while Phonegap application runs inside browser, Titanium’s app runs inside javascript interpreter

Hybrid approach seemed like a real option, but in fact for custom/responsive GUI app you’ll inevitably need a lot of
code to support native UI.  Hybrid works for small features like accessing accelerometer, camera, phone’s contacts, etc.

It seems that creating complex & responsive UI in HTML5 is not really possible, thus UX will be pretty
limited. Hybrid approach for the UI part is not a good fit from the development point of view:

• Large amount of platform specific UI code (Obj-C) + javascript leads to technology fragmentation which is generally bad
• a lot of quirks to connect native platform & javascript app leads to poor app design which will hurt you in long run

Conclusion

As you might guess, in the end it all comes to what type of application you’re going to build. If it’s mostly data-access, satellite mobile
application to your mainline app, than Titanium might be an option to consider. If you’re building something more similar to Path,
you’d better start right from hiring Objective-C folks.

And yet another warning, if you’re looking for cross-platform mobile application development, Titanium might not be a good choice.
Bad news, there’s no silver bullet here. Though, it does provide some mechanisms to do it well, but the dream of writing one single codebase
and ability to produce native apps for multiple platforms is very hard to achieve.

• Native app for iPhone & Android (rich UX, more happy users)
• Huge company behind Titanium,  paid support which means you’ll not be left with your problems alone
• Hundreds of successful apps already made with Titanium which fit Nimble API model (i.e. they are not standalone)

References

• Phonegap giveaways on CSS animations and location services
• Native app or html5?
• How Titanium really works?

Appcelerator Titanium is a very promising technology which allows you to write native mobile applications in Javascript for both iPhone & Android.

After playing around a bit with Titanium Mobile, I decided to showcase technology strengths to our stakeholders, particularly by letting them use KitchenSink demo for iOS.

In order to distribute iOS application into real hardware you’ll have to pass through a bunch of  Apple’s obstacles including:

• Registering as an apple developer & getting valid certificate
• Registering your app ID
• Creating provisioning profile for specific iPhone UDIDs
• Mess around with certificates/private keys to properly sign your application

It turns out that it’s not that easy to produce valid AdHoc distribution of your iOS app in Titanium, in this post I’m going to show you how to do it.

Before we start, make sure you have latest Xcode & Titanium SDK/Studio installed, as of the time of this writing Xcode version was 4.2.1, and Titanium mobile SDK was 1.8.1

For demo purposes we’ll use KitchenSink application provided as a showcase of Titanium mobile:

Clone & run KitchenSink in emulator

git clone https://github.com/appcelerator/KitchenSink.git

Open Titanium Studio and select File->Import->Import Existing Titanium Project

Configure project for iphone only

Run project on iOS simulator

At this point,  Titanium will create an Xcode project for KitchenSink application. Wait for it to compile and run, then exit Simulator.

Open generated Xcode project

Run Xcode, and open KitchenSink.xcodeproj , Objective-C code could be found at kitchensink/build/iphone

Manage project schemas

In Xcode, open Product->Edit scheme:

For each schema (KitchenSink, KitchenSink-iPad, KitchenSink-universal) select Archive and make sure that
Build Configuration is set to debug

Configure code signing for build targets

For each target, select Build Settings -> Code Signing -> Code Signing Identity

Make sure to select valid provisioning identity that you previously created on Apple’s provisioning portal for a particular iOS device/application. In my case, it was called com.nimble.KitchenSink and provisioning profile was called KitchenSink_AdHoc.  For identities to be recognized by Xcode you should have been installed Apple Developer’s certificate as well as your organization certificate into MacOS keychain.

Archive (produce final IPA file)

Select KitchenSink target, then from the main menu choose Product->Archive

Wait for Xcode to compile & archive. You may find resulting Archive in Xcode Organizer:

Click “Share” and provide the same identity which was used for Code Signing section above:

Save resulting IPA file along with corresponding KitchenSink_Adhoc.mobileprovision   profile.

Install it on device

That’s the easiest part if you’ve done everything right.  Just drag&drop  mobileprovision & ipa  files into iTunes and run sync with an actual iOS device.

If you missed something for code signing, during iTunes sync, you might encounter errors like this:

The executable was signed with invalid entitlements.
The entitlements specified in your application’s Code Signing Entitlements file do not match those specified in your provisioning profile.