Hadi April 10th 2013, 10:55 am
Thanks a lot BardIT and Ahmed Adel, that was really helpful, I think I'll use titanium since I care about performance and stability, and I like to have the native UI of each phone
bionuc April 10th 2013, 11:52 am
The core difference in my opinion is that Phonegap is focusing on WebApps while Titanium is focusing now on allowing developers to write with JS an app and then it will be compiled to different platforms. Btw, there are other tools doing the same as Titanium
I like Phonegap for other reasons
1. It is clear because they do this inside normal development environment which allows you to update codebase if you want and use third-parties written in Objective C if you want
2. It has better support I think and documentation
3. It didn't change its way as Titanium did. Titanium was not like that when It was there
Titanium is good but it was bad in documentation and in black-boxing things and supports less platforms
bionuc April 10th 2013, 11:56 am
Long time ago, I also looked at those
2. http://www.rubymotion.com/ . It was good but not for free but was easier when you want to build a UI
I don't think any of these solutions are for people who care about performance ( thus not for games ). It might work fine but it will be hard to optimize things
Ketan May 24th 2013, 4:26 am
I like to use phoneGap because in it no need to under stand native code of any OS(iPhone/Android/Windows).
Nyron June 2nd 2013, 8:14 pm
Ahmed Adel June 11th 2013, 5:10 am
At the moment , PhoneGap is way ahead of Titanium in terms of features, activeness and community support that is driven by two industry giants: Apache and Adobe. But, of course, building PhoneGap applications that perform well needs special attention to performance and architectural details. Using heavy-weight frameworks, such as JQuery Mobile or Sencha, will make the development easier but it will affect performance greatly in contrast to using micro-libraries.
Fbn June 17th 2013, 9:54 am
If you are looking for stability stay away from Titanium
JC July 18th 2013, 12:07 am
I use titanium, develop my app as a html 5 site, but use titanium webview to run it. So I have all the advantages of Phonegap. My application runs much faster in Titanium then Phonegap this way.
Ahmed Adel July 18th 2013, 10:33 am
@Jc: according to Titanium docs here:
Titanium.UI.WebView is a built-in WebKit container. So, technically, using this approach is just duplicating what PhoneGap does and implies the performance must be equal unless you use different html5 code for each. I am interested to to see a link to your application or site and include it as a case study.
Mobilepundits August 20th 2013, 4:34 am
If you want to create an app with native look and feel using your existing web development expertise Titanium is the right choice, but if you want to port your app to different platforms and devices more easily, PhoneGap is best for you.
Ilton Garcia September 26th 2013, 6:14 am
The titanium is better in performance because the WebView pre process the JS and after the JS process the webview show the GUI, so u need 2 process for the same work (browser process and OS process).
Brian McBride July 10th 2014, 3:13 pm
So, I've been developing an app in Titanium. I like the idea that I'm accessing native UI elements. In my case, my app isn't going to be hindered by JS performance.
However, the core titanium UI doesn't map to the native UI super well. One case in point is that Titanium only supports Android 2.x animation calls. By now I would expect the Titanium API to support Android 4.0 UI functions and gracefully downgrade where necessary based on device.
After a few weeks, my take on Titanium is that it should be faster than a webview, but the Titanium API to Native API is falling behind what is current. When I see a lack of honeycomb features supported, I question the validity of Titanium now that we are approaching "L" later this year.
My clients are now expecting more animated elements in their next apps and this is proving to be more and more difficult with Titanium vs Phonegap. Even maintaining two codebases might be easier since it seems I'll have to write custom modules anyway.