Comparing Titanium and PhoneGap

blog product titanium

July, 2014 : The following blog post is an updated version of a blog post written by Kevin Whinnery in May 2012. The original version can be found here.

When building for mobile devices you can take one of three approaches: Web apps, Hybrid Apps or Native apps.
Web Apps are websites designed to fit in mobile screens and are accessed by typing a URL in the phone’s browser. There are multiple UI frameworks that can make your Web app look like a native app, or you can build it using media queries to make it responsive to the web browser’s dimensions.
Hybrid Apps are Web apps that are packaged in a custom full-screen browser to resemble a native mobile app, with extensions that provide access to some hardware features, but your user interface is still written in HTML/CSS and rendered by a web browser.
Native Apps are written using different languages depending on the platform. Native apps have full access to the hardware and the user interface is rendered by the platform SDK.
PhoneGap is a framework to build Hybrid Apps, while Titanium is a framework to build Native Apps, so that makes them different right from the start. The decision of which one to use has not much to do with the technical details of each, but rather with what you’re trying to build. In this document, we’ll go into the technical details of both to give you a better understanding of how each product approaches the problem.
From 10,000 feet, PhoneGap and Titanium appear to be similar. They both provide tools for cross-platform mobile development. Both also require the use of JavaScript and web technologies in some capacity. Both Titanium and PhoneGap are open source software with permissive licenses (the Titanium SDK is released under the Apache 2.0 license – PhoneGap, which might also be called a “distro” of the Apache Software Foundation-governed project “Cordova”, is similarly licensed).
But that’s really where the similarities end. While both technologies exist to enable cross-platform mobile development, the philosophies and approaches to solving this problem have very little in common. Also, the business goals driving each project from the perspective of the sponsoring companies (Adobe for PhoneGap and Appcelerator for Titanium) are very different. I will attempt, from my perspective, to describe these technical, philosophical, and business model differences in some detail in the text to follow.
We’ll first examine at a high level how both technologies work. We’ll also see how both technologies are extended with additional native functionality. For each technology, we’ll understand the key strengths and weaknesses with their chosen approach to cross-platform. The technical differences will quickly become obvious, but after these overviews and comparisons, we’ll explore more about the philosophical and strategic differences between the platforms and where they are going.
Let’s start by exploring PhoneGap and how it works.

What is PhoneGap Trying To Accomplish?

The purpose of PhoneGap is to allow HTML-based web applications to be deployed and installed as native applications. PhoneGap web applications are wrapped in a native application shell and can be installed via the native app stores for multiple platforms. Additionally, PhoneGap strives to provide a common native API set which is typically unavailable to web applications, such as basic camera access, device contacts, and sensors not already exposed in the browser.
At a higher level, PhoneGap might be considered the vanguard of the emerging W3C Device API standards, as they attempt to bring that future to web developers in the present. Today, only Mozilla makes web applications first-class citizens with their FirefoxOS. Microsoft is also making interesting strides for Windows 8 with regard to first-class API access to web applications. But the goal of PhoneGap is to seize a subset of these rights for web applications today.

End-User Workflow, Tooling, and Interface for PhoneGap

To develop PhoneGap applications, developers will create HTML, CSS, and JavaScript files in a local directory, much like developing a static website. In fact, some PhoneGap developers cite as a bonus of the tool that they can develop in a desktop web browser most of the time, without needing the native toolchain at all.
To run a PhoneGap application on a native emulator/simulator, developers will generate a project for each of the native platforms they wish to support, configure that project’s “webroot” directory in Xcode, Eclipse, or whatever native toolchain is needed, and then run the project using that tool. The precise steps are outlined in their getting started guides, per platform. Often, symbolic links are used to route the “www” folder across multiple native projects to a common directory location.
Installing a native-wrapped PhoneGap application to a device requires a similar workflow. However, to augment that process and alleviate the need to have native SDKs installed locally, Nitobi (recently acquired by Adobe) had created a service called PhoneGap Build, which will generate installable applications in the cloud. Functionality to support PhoneGap build deployment has recently been integrated into Adobe’s Dreamweaver tool.
The tools used with PhoneGap are the standard tools of web development, such as Firebug, Web Inspector, and your text editor of choice. There is also an emerging tool for remote debugging known as Weinre that is becoming more commonly used. Overall, the fact that in the end your web app will be wrapped in a native browser is mostly abstract during the development process.
There are also many different vendors supporting the Cordova technology, such as HP Anywhere, IBM Worklite, SAP, SAP Platform, as well as the Adobe-owned PhoneGap, each of these offering its own IDEs with additional supporting components.

How PhoneGap Works

As we mentioned previously, a PhoneGap application is a “native-wrapped” web application. Let’s explore how the web application is “wrapped”.
Many native mobile development SDKs provide a web browser widget (a “web-view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls and displays the resulting HTML as the UI when the application is launched.
If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to (in different ways, depending on the platform) asynchronously communicate with JavaScript code running inside of the web view. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture – the “bridge” means something slightly different in Titanium, as we will see later.
PhoneGap takes advantage of this to create a JavaScript API inside a web view that is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is the different per platform, but on iOS, when you call for a list of contacts, your native method invocation goes into a queue of requests to be sent over the bridge. PhoneGap will then create an iframe that loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by eval’ing a string of JavaScript in the context of the web view from native code.
There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.

Extending PhoneGap

Writing native extensions for PhoneGap requires that you:

  1. Write a JavaScript interface for your extension which will use PhoneGap’s API to queue up messages to be sent to native code.
  2. Register your extension with the native project in some way – on iOS, this is done in the Cordova.plist file.
  3. Write native code that PhoneGap will route requests to from the web view, and implement any native code needed

Basically, developers can participate in the same asynchronous messaging system which powers the core PhoneGap native APIs.

Strengths of the PhoneGap Approach

PhoneGap’s primary architectural strength is that it is so small and simple. It does what it does, and it does that well. The PhoneGap team has intentionally implemented only the lowest common denominator of native APIs for the web browser-based app. Because the native API set is so small, it has been relatively easy to port PhoneGap to many different environments. Basically, any native platform that supports a web view or web runtime can be a PhoneGap platform.
Non-visual native extensions in PhoneGap are also very simple. The requirements for registering native code to receive messages from the web view are very modest. Simple native extensions can be developed rapidly. This plug-in architecture was also well executed in my opinion.
There is also strength in the fact that native APIs and native app development are almost completely abstract to the end developer. Anyone who can write HTML, CSS and even a small bit of JavaScript can wrap up a web page in a native container and distribute it as such. The barrier to entry in using PhoneGap to package web pages as native apps are extremely low.

Weaknesses of the PhoneGap Approach

The quality of the user interface in a PhoneGap application will vary based on the quality of the web view and rendering engine on the platform. All user interface screen controls are rendered in HTML and anything were done to make your app look and behave like a native app (animations, screen transitions, etc.) are simulated using HTML, CSS, and JavaScript. The Webkit-based rendering engine on iOS is strong and provides the best performance. The Android web view is functional but has some notable limitations. On other platforms, the web view performance can be suspect depending on the OS version.
There are also the standard cross-browser issues web developers have always had to deal with. UIs will need to employ progressive enhancement, media queries, and that entire bag of tricks to remain usable on multiple platforms. It helps that many mobile platforms are adopting Webkit, but there are still significant differences even in Webkit based environments.
Mobile browsers are getting better all the time, which will help mitigate those problems. But approaching native-quality UI performance in the browser is a non-trivial task – Sencha employs a large team of web programming experts dedicated full-time to solving this problem. Even so, on most platforms, in most browsers today, reaching native-quality UI performance and responsiveness is simply not possible, even with a framework as advanced as Sencha Touch. Is the browser already “good enough” though? It depends on your requirements and sensibilities, but it is unquestionably less good than native UI. Sometimes much worse, depending on the browser.
PhoneGap also cannot be extended with the native user interface. The end developer’s application its self lives inside a web view, and the user interface is rendered in HTML. One can message to native code and create native UI that goes on, over, above, or adjacent to the web view, but it’s difficult or impossible to integrate a dynamic, HTML DOM-based UI with native UI components. Appcelerator would know – we tried to associate native UI with DOM elements early on, and needed to scrap that effort as the results were unpredictable and of insufficient quality.
There is also the other edge of the “lowest common denominator” sword. Very few native APIs are exposed to PhoneGap applications by default, which makes platform integration limited. There are a variety of plug-ins that exist to plug some of these holes, but in my personal experience, they have varied in quality and maintenance. This could very well continue to improve over time though – there is a strong community around PhoneGap.
We’ll dive more into the philosophical aspects of PhoneGap soon, but let’s explore these same technical areas for Titanium first.

What is Titanium Trying to Accomplish?

The goal of Titanium is to provide a high level, cross-platform JavaScript runtime and API for mobile development (today we support iOS, Android, Mobile Web, BlackBerry 10, and Windows Phone coming soon). Titanium actually has more in common with MacRuby/Hot Cocoa, PHP, Xojo or node.js than it does with PhoneGap, Adobe AIR, Corona, or Rhomobile. Titanium is built on two assertions about mobile development:

  • There is a core of mobile development APIs that can be normalized across platforms. These areas should be targeted for code reuse.
  • There are platform-specific APIs, UI conventions, and features which developers should incorporate when developing for that platform. Platform-specific code should exist for these use cases to provide the best possible experience.

So for those reasons, Titanium is not an attempt at “write once, run everywhere”. We think there are great, user-experience enhancing features across multiple platforms that developers should be using. We think that native apps should, take advantage of familiar, high-performance native UI widgets. However, we think it is unnecessary that native developers need to learn platform-specific APIs to draw a rectangle or make an HTTP request.
Titanium is an attempt to achieve code reuse with a unified JavaScript API, with platform-specific features and native performance to meet user expectations. When you write a Titanium application, you are writing a native application in JavaScript. Titanium is a framework for writing native apps, versus an abstraction from the actual platform you are targeting.

End-User Workflow, Tooling, and Interface for Titanium

To develop native applications with Titanium, the developer is required to install the native toolchains for the desired target platforms, just like any other native developer. After those tools are installed, however, the developer usually only interacts with the Titanium SDK’s Node-based CLI. This is done either directly through the command line or (more commonly) through Titanium Studio, our Eclipse-based IDE.
Using the Titanium toolset, you will generate an application project directory that contains a configuration file, localization files, and a directory to contain the images, assets, and JavaScript source you will be writing to power your application. You’ll not be writing HTML and CSS code; you will be writing your code using Alloy, an MVC framework that organizes your code in Views written in XML, Stylesheets provided as JSON objects (very similar to CSS), and controllers written in JavaScript. All UI elements are provided by the underlying native SDKs and accessed by the methods of the Titanium API, so the result is a native app and not a web app that looks like a native. You could however still create Hybrid apps that contain both native and HTML-based UI, which is equivalent to implementing PhoneGap inside Titanium, but that’s out of scope for this discussion.
Using this toolchain, your application is run using the actual em/simulators for the platforms you’re targeting. Titanium Studio also provides step-through debugging, code completion, and other IDE-level features.
Installing a device for testing is also typically done using our build system. In Studio we provide a wizard interface to configure any code-signing dependencies, and then handle the deployment of your application to a connected device. You can also use the native toolchains to deploy or package your applications if that is your preference.
When it comes time to ship your application to the stores, our build system will handle the creation of the final application packages for you. This is done locally on the developer’s machine using the native toolchains. The upload process will be the same as it is for native-only developers.
While developing a Titanium application, the underlying toolchains are mostly abstract. They must be present for development, but the end developer is rarely required to use them directly. The fact that native apps are being developed, however, is not abstract. User interfaces are created with cross-platform AND platform-specific components, and your applications should be dealing with things like background services, local notifications, app badges, configuration, activities/intents (on Android)… all things that are exposed via the Titanium JavaScript API.

How Titanium Works

There’s quite a bit happening behind the scenes in a Titanium application. But basically, at runtime, your application consists of three major components – your JavaScript source code (inlined into a Java or Objective-C file and compiled as an encoded string), the platform-specific implementation of the Titanium API in the native programming language, and a JavaScript interpreter that will be used to evaluate your code at runtime (V8 for Android, or JavaScriptCore for iOS).
When your application is launched, a JavaScript execution environment is created in native code, and your application source code is evaluated. Injected into the JavaScript runtime environment of your application is what we call “proxy” objects – basically, a JavaScript object which has a paired object in native code. Colloquially we will often refer to “JavaScript land” and “native land” in a Titanium application, as they are kind of parallel universes to one another. The proxy object exists both in JavaScript land and native land, and serves as the “bridge” between the two.
In your JavaScript code, when you call a function on the global Titanium or Ti object, such as var b = Ti.UI.createButton({title:'Poke Me'});, that will invoke a native method that will create a native UI object, and create a “proxy” object (b) which exposes properties and methods on the underlying native UI object to JavaScript.
UI components (view proxies) can be arranged hierarchically to create complex user interfaces. Proxy objects which represent an interface to non-visual APIs (like filesystem I/O or database access) execute in native code, and synchronously (or asynchronously for APIs like network access) return a result to JavaScript.
Hopefully, this helps directly address two common misconceptions about Titanium – at no point does Titanium require the use of a web view component. The developer can create a web view as a native UI widget, but the web view is not used to evaluate the Titanium source code. Nor is JavaScript code cross-compiled to Objective-C or Java in Titanium. Your JavaScript source is evaluated at runtime.

Extending Titanium

Titanium is extensible with both non-visual and UI capabilities in native code. By implementing a Proxy and/or View Proxy interface in native code, developers can create new native functionality for Titanium applications exposed in JavaScript. We expose the same interface we use to create Titanium’s own internal interface to module developers both on iOS and Android.

Strengths of the Titanium Approach

Since the goal of Titanium is to provide a higher-level API for native mobile development across platforms, you will get access to a wide array of native features and functionality out of the box, from user interface components to socket interfaces to notification system integration. The goal of Titanium is to reduce the functionality gap between Titanium and pure native apps to something approaching zero. We’re likely to never support an entire platform’s API out of the box, but we want to cover 90% of the most common use cases and provide a platform where the other 10% can be added by people that need it.
Since Titanium can be extended with visual components that plug into the same view hierarchy as the rest of the application, you’re able to (ultimately) implement any user interface that is possible on the underlying native platform. Need a TableView to scroll at 60fps with special native code? You can do that. Want to seamlessly integrate an OpenGL drawing surface for a game, and keep the logic for the run loop in JavaScript? It can be done by creating a native module, which is exactly what Lanica did with Platino. You can integrate these UI extensions directly into the rest of your application built with the core Titanium APIs.
The look and feel of a Titanium application, when using common UI widgets, is also a strength of the platform. There is no visual emulation going on (either through the application of CSS, or the rendering of UI widgets using OpenGL or Flash). When you create a NavigationWindow, it is backed by an actual UINavigationController on iOS. The animations and behavior match what a native app user will expect because you’re using the same UI control.
Since Titanium provides a high-level native programming API in JavaScript, the barrier to entry for native programming is significantly reduced for anyone who has used an ECMAScript based language (which is a lot of developers). Atwood’s Law is alive and well through Titanium.

Weaknesses of the Titanium Approach

The scope of the Titanium API makes the addition of new platforms difficult – implementing the Titanium API on a new native platform is a massive undertaking. For that reason, the Titanium platform is only available on what has been deemed the most critical mobile platforms at present: iOS, Android, Mobile Web and Blackberry 10. This, however, will be solved with the new compiler, Hyperloop. With Hyperloop ~90% of the compiler is common for ALL platforms, leaving only a mere ~10% for platform-specific code.
Also, with the introduction of Alloy, our official MVC framework, we’ve seen that most of the performance problems have disappeared, as Alloy properly generates optimized code based on Common JS Modules.

Philosophical Differences

By now, the technical differences between PhoneGap and Titanium should be pretty clear. But beyond those differences, the goals and direction of each project are different as well. The stated goal of the PhoneGap project is to, eventually, cease to exist. As stated earlier, PhoneGap is intended to be the leading implementation of emerging browser standards around device APIs. In theory, once browser vendors implement the features of PhoneGap, the platform will no longer be necessary. PhoneGap itself isn’t intended to be a platform – it’s a shim to add native app-like functionality to web applications. The web is intended to be the platform.
PhoneGap’s new sponsoring organization, Adobe, is also very much interested in the advancement of the web as a platform. In recent months, Adobe has been aggressively building out tools to enable the development of HTML 5/CSS 3 web applications. It seems obvious to me (and many others) that Adobe sees a diminishing role for Flash as standard web technologies evolve.
At it’s core, Adobe is a tools business. Platforms are a channel through which Adobe can sell tools. Once, that platform was Flash. Now, that platform is the web browser (in addition to Flash). It’s difficult to say how PhoneGap factors into Adobe’s product roadmap, but in a lot of ways it serves a similar purpose as Flash. PhoneGap is an attempt to create an abstract runtime environment to enable cross-platform deployment.
If Adobe can sell tools to develop for the web, and the web can be used to develop more types of applications, then that’s a clear win for Adobe. Which is fine, by the way – nothing wrong with selling tools.
It’s worth noting, however, that Adobe is not the governing body of the Cordova project, on which PhoneGap is now based. That project is owned and governed by the Apache Software Foundation. It remains to be seen what the interplay is going to be between the two projects, but my gut instinct is that they won’t diverge much. I think their goals will remain philosophically aligned.
Appcelerator is also interested in and supportive of the advancement of the web as a platform. Everyone wins when the web gets stronger as an application platform. The difference is that we view the web as one great platform among others, with a unique character and set of strengths and weaknesses. We don’t expect the web to become the only mobile application platform. We think that platforms like iOS, Android, BlackBerry, Windows Phone, and the like will continue to be influential, and will provide great experiences for users. That choice and competition will be a good thing for consumers but will remain a problem for developers.
What Appcelerator provides to developers begins with allowing them to target native platforms from a single codebase, while retaining the features, performance, and tight platform integration that the users of that platform expect. However, this is the tip of the iceberg. The Appcelerator Platform is a turnkey solution that covers all aspects of the mobile app development lifecycle. Today you can build enterprise-grade applications using the Titanium API and Alloy, build middleware services using Node.ACS, store data on ACS, interactively build APIs that connect to multiple data sources using our API Builder, perform automated testing of your apps on different devices and simulators and obtain crash reports, all from a single dashboard.
Which tool or approach is right for you? Like all things in software development, it depends. There are no silver bullets. But hopefully, this description and comparison will help you make the right choice for your situation.

Previous articleWhat Makes a Visually Appealing App?
Next articleFrom the Appcelerator Engine Room: Engineering Update


  1. Hello Kevin,
    Great that Appcelerator is planning for Windows Phone support on titanium. You said that “Windows Phone is coming soon and eventually”.
    When can we expect the first windows release?

    • We’re currently in an evaluation process for Windows Phone support. We don’t have any ETA on when a Windows Phone release will happen, but we know we want to do one eventually. We think the platform is evolving in the right direction.

  2. Really great article explaining the difference between PhoneGap and Titanium. I am titanium developer at the moment (i played with PhoneGap before that), recently i have found KenodoUI with that framework you can create really native looking apps with PhoneGap or Titanium hybrid model.

  3. Excellent article Kevin. You should broaden this to a discussion of Native v Titanium v Web apps. And then encapsulate it and put a link up front on the Appcelerator home page. A lot of traction can be attained by Titanium if clients realise that they don’t need to write native apps, but can get the performance or near performance from Titanium. There is still a big problem of perception, as when speaking (in my world in the UK) to clients, advertising agencies and recruitment agencies that they either haven’t heard of Titanium or don’t understand what it is and how it is different to native or web app programming.
    PS the “Build Native Apps” link on your home page is broken.

  4. Well done Kevin! I just wanted to second what Simon said on two counts: 1) This is exactly the type of info clients need – esp. re: great prototyping tool; 2) Would be great as a feature article in popular dev publications – helping to raise awareness. Excellent!

  5. Well balanced article:) i have used both platforms for quite some time
    and find myself using titanium for meatier projects due to it’s
    “native” like performance.
    I know you mention this but I strongly feel that there needs to be more tutorials and examples made available to help people get to grips with titanium.
    Aware of all the video press but quite a lot deal with advanced subjects. Plus the examples in regards source can be a bit overwhelming to pull apart.
    Really think some smaller tutes such like what “mobile tuts” publish would be a huge help. So they could cover best practices for structure (common js but mini project based), examples of small apps that could cover popular use cases (making an image gallery, loading and customising a tableview etc). Then people have clear and friendly examples that they can use as building blocks for creating their own apps.
    You naturally won’t be able to cover everyones requirements but some simple tutorials that explain the basics would fill a void right now and get people moving and also reduce the amount of stuff posted to Q&A:)

  6. @Jack: If your aim is writing “hello world” equivalent apps, then Titanium is probably not for you. If your aim is to build apps with the highest level of quality, performance, and native integration on your target platforms, then Titanium IS for you.
    To be fair, the developer doesn’t “pay” for the loss in performance using a solution like Phonegap. The user does. They will make themselves known when it comes time to rate your app.
    Also, are you aware of the mobileweb SDK RC available now? It will allow you, using the same Titanium API, to build native apps for android, ios, and blackberry, while simultaneously building HTML5 compliant web apps. So basically, that extensive reach that was reserved for web-based platforms is now within the reach of Titanium developers.
    Real businesses using Titanium: NBC (#1 app in Apple App Store), Bravo, Reuters, and SAP just as a sample.
    I think if you gave Titanium an honest look you’d be surprised how much the benefits far outweigh the minimal gain in executable size.

  7. If you start using Titanium, you have only 2 choises in future:
    -rewrite everything on native;
    -change framework (who need 3MB hello world?).
    If you start using PhoneGap you have no limits – just have to “pay” little for speed. jQuery Mobile, Dojo mobile, jqMobi…so on and more. You can make website and app in same time – welcome to jQuery mobile. App Size will be MUCH LESS then with appcelerator, speed – same, development – smarter (lets be honest – titanium coding approach not so good).
    And you can see that – every real business company stay away from appcelerator…

  8. I have just read a study from VisionMobile about cross platform tools which was based on a survey ( in the end of 2011.
    Based on that survey, Titanium got less score than the average in the following categories:
    Number of platforms supported 3.8 -0.4
    Runtime performance 3.6 -0.2
    Learning curve 3.7 -0.2
    Development and debugging experience 3.2 -0.5
    Vendor support and services 3.5 -0.3
    1= Unacceptable, 5= Excellent
    In the first column you can see the score of Titanium. The second column presents the deviation from the average of other tools.
    1.) Since that survey is based on approx 6 months old data, how have the thins changed(improved) since then?
    So far I have narrowed down my search to Titanium and MoSync.
    According to that survey, MoSync got higher score overall but I am mainly interested in the Javascript/Html5 part which, as far as I understand correctly, does not go through the MoSync’s optimization process like the C++ code.
    How does Titanium’ approach compare to MoSync’s Html5/Javascript Wormhole approach in terms of performance?

  9. @Laszlo: Let me see if I can shed a little light on why the results of report may be a little skewed. I’ll work through each of your points and questions.
    # of platforms supported: We will typically be behind in this as we have a much deeper integration with each underlying platform. We want developers to be able to deliver the highest quality, truly native apps with Titanium, not just web apps in a native webview. That said, the reach of Titanium now is limited only to whatever can run a browser with the mobileweb sdk, currently with an available release candidate. This includes mobile devices as well as desktop browsers.
    runtime performance: This surprised me, until I read the report. It’s doing an “apples and oranges” comparison of cross platform frameworks that don’t exist to solve the same problems. The main issue is that while Titanium is pretty much capable of any type of app, our strongest apps are generally data and native UI driven applications. Titanium makes use of the native UI and performance, so runtime speed in that respect should be right on par with native. The reason this report likely has us below others is because you’ll note that all the highly rated frameworks for performance focus on graphics rendering. Frameworks designed to make games and high end graphics will always _appear_ to have higher performance, but the fact of the matter is that while these game engines typically make use of only a single native opengl rendering context, we make use of all the underlying platform’s native UI. The performance hinges on the device itself, not Titanium.
    Learning curve and debugging: I can see how these might be lower than others because Titanium is an entirely new development paradigm for mobile. Write JS, make native apps. It’s not been done before, or since, and we are introducing something unique to developers. With this unique approach comes the price learning its ins and outs. Fortunately, though, all the learning curve rests on learning the API as Javascript is a fairly easy language to pick up. Especially in comparison to the other languages driving mobile development (primarily Objective-C and Java). It may seem foreign at first, but once you start learning, you’ll advance quickly.
    Vendor support and services: I’m not sure what they are measuring with this one. Can you elaborate?
    The things that have changed in 6 months are pretty drastic:
    – Android’s performance has gotten on par with iOS with the introduction of the V8 javascript engine.
    – The mobileweb sdk has increased developers’ reach to many other platforms, devices, and even desktop browsers.
    – Blackberry support will be available to the entire Titanium community in the coming months
    – Titanium Studio, our free, full-fledged IDE for Titanium development, has matured greatly, adding tons of features and making it _significantly_ easier to develop mobile apps, particularly for multiple platforms.
    And those are just the big highlights. There’s literally been thousands of feature adds, enhancements, and fixes in the last few months as Appcelerator has grown its engineering team.
    I’m no Mosync expert, so I don’t want to misrepresent it here. I do know that they have both an HTML5/JS API as well as a C++ one. What I assume this means is that they have some native hooks, as well as access to a few native UI components, via the C++ which you would then somehow integrate with your HTML5/JS. The Wormhole library that you reference seems to be a stock list of some of these integrations done already so that you don’t need to code C++ yourself. It does seem a little lacking in that department as compared to Titanium, particularly some of the more popular components like MapViews, Android Intents, and some iOS-specific UI components. I’d encourage you to compare the native API listings between Titanium and Mosync to see which best suits the needs of your app.

  10. @Humberto: There’s no technical limitation on what can be done with regards to gaming and graphics with Titanium. You can make use of the current openGL or Box2D modules in the marketplace, or write a more specialized module yourself. Titanium has primarily, though, focused on delivering native UI, services, and functionality throughout the whole of the underlying platforms it supports, providing a much deeper integration than any other cross-platform mobile framework out there.
    Gaming and graphics via an opengl rendering context, which is how a majority of the gaming cross-platform frameworks work, is a single focus on a single component with a single purpose: gaming. These frameworks do a terrific job in that space, but neglect the rest of the things that Titanium makes available in terms of UI and platform-specific features because they aren’t critical to that single purpose.

  11. We’ve done since now two apps based on titanium. One of them used an hybrid approach. We stated that there’s clearly a price to pay for the hybrid solution(performance and fluency of the UI).
    Our work is mainly digital apps and books for children. This mean using all multimedia capabilities, voice recording, images, sounds, animations , … in a very quick response UI.
    Since I’ve followed this battle between mobile cross-platforms I’ve always stated that the native approach of titanium was the better solution.
    After reading @Laszlo post and @Tony reply I’ve question about what are the graphics and gaming limits, above witch titanium is not the best solution, or have some significant drawbacks?

  12. @Tony, thank you for your detailed answer.
    About the vendor support and services, although the study does not specify it explicitly but I have read complaints from developers on and few of them feel that Appcelerator was not supportive enough towards their development community.
    But again, those complaints are more than 1 year old now.
    So how can you see it, did you manage to cope with these kind of issues?

  13. Dom elements can be handled with display none in webview.
    At our incubator, some companies use phonegap and others use titanium. Both get the job done, so like you said, deciding which one to go with really depends on what’s right for you and your skill set.
    The solution to many of your web Ui problems can be solved here

  14. I am sorry but I did not make myself entirely clear in my previous comment.
    I think, the “Vendor support and services” grade measures the developer satisfaction with the support from the vendor.
    The complaints on the above site might explain why this score was lower than the average in the past.

  15. I had a good look at mosync vs appcelerator and have to say on first look went with MoSync. I am a C/C++ coder and it was mainly familiarity. I then went on the extend MoSync and found very simple c libraries and some common ones (sqlite for example) would just not compile. So for me the attractiveness of a c compiler for lost. As for the MoSync wormhole technology, it’s nice, but performance is rubbish and the resulting UI is nowhere near native.
    As for the Vendor support and services. This is something the Appcelerator team could really learn from. Appcel JIRA is full of really old bugs or features requests that have no comment or timeline (take TIMOB-1309 for example). The Q&A section seems to be rarely visited by Appcel staff and the only support is incredibly expensive.

  16. Thank you very much for this great article. It’s interesting to know the philosophy behind architectures.
    Just when I was thinking which one to pick (probably will try both over the next few months to appreciate the differences myself).

  17. through comparison of both platform. A philosophical but i agree with the future tread of application and platforms described in the article. thanks :))

  18. Kevin thank you very much for your article.
    It provides a clear insight into the most prominent mobile development tools, what you have explained here makes complete sense and has helped me put ALL the pieces of the puzzle in place.

  19. Great high level explaination and comparison, thanks very much! I think for me its better to stick with straight native until these frameworks mature to the point where their adoption is dwarfed by their benefits. Sounds like they are each going at the problem using differing approaches, whichis likely a good thing.

  20. Kevin,
    My name is Bill Cullifer, executive director for the membership supported
    I am writing to you today with a request for interview. Specifically, I’d like to interview you regarding your article, Comparing Titanium and PhoneGap. is a not for profit professional association with thousands of members worldwide including those that teach. One of our key goals is to educate aspiring and practicing professionals including those that teach at the high school, community college and at the university level. To that end, I’d appreciate the opportunity to talk with you.
    If you can spare 10-15 minutes for an over the phone/skype interview please let me know.
    For your information, I am highlighting additional details about the podcast below.
    The format for the podcast includes audio and text and a flash rendering with an image of the person being interviewed.
    The podcast typically run 3-5 minutes with links to additional content.
    The topics range from Web Design and Development and just about anything Web related and of interest to Web professionals.
    Audience: members and subscribers are a diverse group of individuals. Most are generalist with responsibilities in Web Design, Web development and Web Business. The organizations represented range from the enterprise, small to medium businesses to freelancers and independents as well as educators and those working for government agencies and education.
    Distribution: subscriber base currently stands at 28,000 Web pros.
    Timelines for Interviews:
    We typically like to conduct our interviews from the hours of 10am and 6pm Pacific Standard Time. (PST)

  21. Thank you for a fantastic article, on the differences between these two developer options. In my view, Titanium offers a superior engineering workflow and product. I am moved to consider Titanium for all the reasons you’ve stated, and I agree with your philosophical approach. That said, I’ll likely choose PhoneGap again for our next project.
    The primary reason I see PhoneGap winning over developers, has to do with what your article did not address: the App Stores. Both Apple and Amazon have a submission process that is painfully slow and unpredictable. This impacts production schedules, marketing, the perceived quality of the product, and ultimately the user.
    By way of PhoneGap’s shim model, you can imagine how simple it is to circumvent these production obstacles. For instance, our current app is basically a thin-client to our servers, where the entire experience can be updated immediately – including the thin-client code itself. Fat-clients could do the same, by periodically checking our server for updates (again, bypassing any App Store re-submissions).
    What are your thoughts on this aspect of deployment? Is this kind of development model feasible with Titanium, and if so, to what degree (i.e., core vs dynamic JavaScript)?

  22. Hi,
    thanks for article. One of the most interesting article I seen on mobile strategy and comparison.
    However, through my software architect experience I would say that dealing with the diversity by providing an (or some) standardized interface is maybe an error.
    Diversity may be managed in a different way.

  23. Many Congrats on writing such a nice and in depth article. Importantly unbiased …
    When I started reading article I thought it would be like all Titanium.. but no, its really very practical comparison.
    Being a web developer since last 6 years,I would gone to PhoneGap directly but your article gave me thought about performance like native apps.I am yet to decide which framework I am going to use for my coming projects.
    But many thanks for article, it was great.

  24. Hi,
    Recently I started working on titanium.The main thing is its consuming lots of memory compared to native one.Never tried phonegap.Suggestions are invited

    • Does this remain valid after the decision to use webkit in what i understood is that is also going to use a javascript engine, in that case, will be there be any major difference between PhoneGap and

      • Yes. The usage of a JavaScript engine in is similar to how a JavaScript engine is used in ti.current. It interprets the JavaScript and executes native code for UI creation, rather than the PhoneGap approach of rendering the UI via a web browser. just removes some additional layers, making even more of the program execution happen in native code vs. JavaScript (even though it’s coded originally in JavaScript)

  25. The best article I read that describes not only the differences between Titanium vs. PhoneGap, but also Hybrid vs. Native and the common misunderstandings.
    Kevin, Thank you!


Please enter your comment!
Please enter your name here