Appcelerator vs Android SDK

Question

I have been looking at appcelerator it seems pretty fine! Without a doubt, one of the advantages of appcelerator is its support for multi-platform. I am interested in building an android app and maybe a iphone app later on. So it is not crucial to support multiple platforms at the moment.

If you disregard supporting multiple platforms and just focus on android development. Is appcelerator still advantageous? Does it lack any features of "Android sdk"?

(When I say "Andorid sdk" I mean development with Eclipse with native Android sdk, if it makes any sense)

Answer 1

We looked at Appcelerator when starting our Android project. We knew we would have to do an iOS client next, so Appcelerator was enticing.

We decided not to go that route because it doesn't support all the native features of each device.

For example, we decided early on that our user interface in Android would need a widget. No support for that in Appcelerator, as it's specific to Android. [This was a few months back -you may want to check again].

Compromising on the user interface was too much for us. We decided to go with C/C++ for the app logic and use Android SDK for the user interface.

Our apps now have two pieces: C/C++ as much as possible to the "brains" and the native (Android/Cocoa Touch) for the UI to take advantage of the UI experience.

Works of course for platforms that can integrate C/C++.

The parting advice: design your user interface first, then find a tool that can implement it. Users have high expectations of the UI in portable devices. Compromising on it early on may be the KOD for your project.

[EDIT] Every so often I see an upvote for this question. I would like to update with what we learned in the past two years:

• Using C/C++ for the common parts of our application has paid off. It does require a slightly more complicated build process, but the savings are gigantic if the piece of code being shared is complex (as in our case).
• For the user interface piece we are beginning to look into hybrid apps (some UI elements in HTML). There are still debates out there about HTML interfaces (Facebook and LinkedIn are two that move to native code for the UI), but also some reports that when chosen carefully it works. There is a great talk from Flipoard on that; with slides here.

---

UPDATE Oct/2014

In March/2014 Smashing Magazine published an excellent article comparing native iOS, native Android, PhongeGap (Cordova) and Appcelerator Titanium. They show the development of a simple app in each environment.

This is the last part of the series. At the top of this part there are links to the previous parts of the series and at the bottom there is the comparison of the approaches. There are also interesting comments from readers at the end.

---

UPDATE May/2015

Still get an upvote for this question every so often, so I would like to share what we have done since I wrote the first part of the answer.

We are now working on a project that also has a web client. We have now the iOS client, the Android client, plus the web client.

JavaScript is the natural choice for the web client.

Since we want to share as much code (at the business logic layer) across these clients, it means we need to find a way to run the JavaScript code in iOS and Android.

And that's what we ended up doing.

This is a summary of how we handle it:

• For all clients: all data structures are defined with Google's protobuf. This allows to automatically generate the serialization/deserialization code for iOS and Android.
• iOS: run the JavaScript code with the help of JavaScriptCore (a good overview here).
• Android: run the JavaScript code with the help of Google's V8 engine.

The bridge between JavaScript and the iOS/Android layer can be a bottleneck, especially the serialization of the objects. We had to optimize a few things and learned a few lessons to stay out of trouble.

Generally the experience has been positive. We saved significant amount of time by sharing the code across all clients.

If I had to start another project like this one (that requires sharing code with web and mobile clients), I would also take a look at what Google did for inbox. It wasn't available when we started. Looks promising.

---

UPDATE August/2015

And the world keeps turning...

I would also take a good look at React Native if I had to start a new mobile app now.

It's based on JavaScript, bridging web and mobile development more easily.

There is a great tutorial in Ray Wenderlich's site.

---

UPDATE February 2016

My shortlist for cross-platform development is down to two:

• ionic
• React Native

I've been paying more attention to ionic because our web app uses AngularJS and so does ionic (Cordova + AngularJS). React Native will force the team to learn another framework (of course the argument is the opposite if your web app uses React).

Nevertheless, I'd seriously consider React Native, even having to learn another framework, because of the reported performance and look-and-feel of the app. From React Native's site:

With React Native, you can use the standard platform components such as UITabBar on iOS and Drawer on Android

If you are starting now, I recommend you take the time to at a minimum complete their tutorials so you get a better feeling of each framework. Each tutorial can be complete in one to two hours:

• ionic tutorial
• React Native tutorial

For a simpler approach: Smashing Magazine just published (at the time I wrote this update) a good article showing how to use the native navigation elements to make the app feel (well...) native, while using web views to render the content. The article goes into the details of how to make the HTML/CSS usable in the mobile devices (it's not just pushing the HTML/CSS you already have).

Answer 2

If you only focus on develop apps for Android platform, I recommend you should use native Android (Eclipse + Android SDK as you said) instead Titanium.

Reason: Titanium is suitable if

1. You want to develop apps quicly, or

2. Your apps is simple, or

3. You see Java is so difficult (maybe :p ), so you choose the easier (Javascript of Titanium).

And here is the reasons why you should use native Android instead Titanium:

1. You want to develop a complex app, or

2. You want to customize app appearance. It's very important. Imaging you make an app for client, and they need their app to be customized for more eye-catching. Choosing Titanium means you must use their control, which lacks of ability to customize. It'd be better if using native Android that you can customize everything you want.