Saturday, May 26, 2012

GeneXus vs PhoneGap vs Titanium

In there is an excellent comparison between two good products used to develop mobile applications: PhoneGap and Titanium.
Since we released GeneXus X Evolution 2 with the ability to generate Smart Device apps, both developers and companies are asking us how we stack up when compared with these two. There is much to say about this topic, so in this article I will cover just the most important aspects of the comparison.

Let’s start with the basics:

What is each product trying to achieve? 

PhoneGap: Development of HTML-based web applications, while installing them as if they were native applications.
Titanium: A cross-platform JavaScript runtime and API for mobile development.
GeneXus: Model Driven Development to create cross-platform Smart Devices applications.

GeneXus is a lot more that a “mobile application generator”. To start with, an application created by GeneXus is a “true” native code application: Objective-C for iOS, and Java for Android and BlackBerry.

In addition, mobile applications need more than the UI. In general they are “connected” applications, and therefore need a server back-end. For this reason GeneXus also creates the database and service layers (derived from the same model) that expose the business logic to the mobile application. The database can be Oracle, SQLServer, MySQL, Informix or DB2, and the business logic may be generated in .NET, Ruby or Java.

This means that, for GeneXus, the concept of application is very different than for the other products. “Application”, in GeneXus, involves the ENTIRE application, from the data layer to the client presentation layer. As a plus, GeneXus can be used to generate the “web portion” of an application too.

Philosophical Differences

The development philosophy of GeneXus has been historically different from “mainstream” development. In fact, the concepts closer to our core philosophy are those around Model Driven Development (MDD). We do not believe HTML, Javascript, Java, Objective-C, .NET (Mono) or any other particular technology should be the centerpiece around which developers build their software.

For GeneXus, languages are just an assembler to obtain final applications, simply a tool to obtain the objective, and (most importantly) an interim tool that will change over time. Based on this, it is not important for us if tomorrow’s applications are programmed (say) using a functional language, or a paradigm completely opposite to the current one. Languages are merely a way to reach the goal. Never-ending discussions like “native vs. web applications” are not relevant. What is really important is the model representing your application.

It is for this reason that, in GeneXus, our intention is to provide a way to declare the application, and not to actually code it. For instance, you can declare that you want:

A List/Detail interface over an entity, and that will result in two, three, or more forms, depending on the entity being displayed.

To show a list of entities, and then choosing whether to display them in a simple grid, a map, a magazine viewer, or chart.

Authentication, via Facebook or Twitter.
Declaring in a model allows for an abstraction level infinitely superior to coding in Javascript or any other third-generation level language.

Weaknesses of the GeneXus Approach

If you're used to “coding everything”, then MDD can feel quite rigid. The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't tweak every last detail the way you want.
Since GeneXus is a modeling platform with more than 20 years of development, it provides a flexible and extensible model so that most of those details can be configured. While in the short term our approach can lack some particular features of the target platform, this is solved by a model built to be extensible from the ground-up.

GeneXus Strengths

GeneXus allows developers to separate themselves from the different platform details (as PhoneGap and Titanium do) but that’s not all the value it provides. Unlike them, it also includes abstractions and patterns to develop applications in a way that positions the developer closer to the domain of the application than to the technological details. This way has been proven to be more sustainable over time than coding in a third-generation language.
GeneXus also conceives the application as a whole: Data Layer, Business Layer, Services Layer, Security Layer, UI Layer. The mobile component is one component of the application: an important one for sure, but still only one part.

The core strength of GeneXus is that models last longer than any leading technology, and models are what you build in GeneXus. Applications were once built on iSeries or Windows platforms, and today they might be on mobile or web platforms. The technology changed, but the model behind those applications is still valid.

In regards to Smart Device applications, the model allows designing the application independent from the platforms but not ignorant of them. The same application, generated from the same model, will not look the same in, say, iOS and Android. GeneXus is cognizant of the design patterns for each platform, so you will never see, for example, an application generated with GeneXus for Android that has a “Back” button in the action bar.

The model has also many strengths:

Model extensibility 

GeneXus provides two main extensibility concepts to make the model more flexible:

User Controls

If you want to include in the model a specific UI control (for example, based on any found in, it can be used in GeneXus by adding a simple wrapper for the control in Objective-C or Java.

External Objects

This refers to extending an API to use native functionality that is not (yet) built-in. For example if you want to interact with NFC, you can develop a wrapper to do the mapping of the API calls, so it can be included and used in the model.

Design is not “one size fits all”

The model allows for elements to vary depending on the platform. A very simple example is that you can, say, add more information to a screen if the device is an iPad, without having to write any specific logic to achieve this.

Grid based design

The Form designer uses a “grid-based” approach, which allows placing “tables” (containers) with relative (percentage) sizes at design time, and they are transformed to pixel values at runtime. As a result, developers don’t have to create multiple screens because of small variations in the form factor, density, or other screen characteristics.

Separation of Concerns

The model also provides an abstraction for all visual design elements called a “Theme”. Everything related to visual design (such as colors, backgrounds, borders, images) is defined in the theme separately from the screen layout, and can be tweaked for each platform without having to create multiple form definitions.


Although Titanium, PhoneGap and GeneXus all help you create smart devices applications, they are quite different in the way the achieve this. GeneXus creates the whole application (data layer, business logic, web, and mobile) based on a model. GeneXus is a good option in the medium and long term because of its philosophy of software creation: declaring over programming in low-abstraction languages.

1 comment:

  1. Como uruguayo digo que lastima, que lastima que Cordova apache nos ha hecho pedazos en tecnología Smart, ya estamos un paso antes, una solución puede ser que Genexus funcione como cordoba implementando html, css, js y código Gx en la vista generando código nativo para las distintas plataformas. Eso puede ser posible?