Balance of convenience and flexibility
or why I switched from Titanium to native iOS Development
A few weeks ago I developed my first iPhone app (Pushster) with the Titanium framework. If you’re not familiar with it, in simple words, it’s a environment to develop apps with Javascript and compile it to different platforms (iOS, Android, Windows, HTML5).
What’s promised
"Write less code (reuse 70% to 80% for the different platforms) and save a lot of time."
And that’s actually spot on. At least for the controller logic part.
One language to rule them all
As a web developer I already knew Javascript and therefore just had to study the components and the fewprinciples how to combine those. It’s way easier than learn a complex language like Objective-C with a hole
new syntax (especially if you come from a Javascript, Java, PHP or similar background). Not to mention that you would need to know Objective-C, Java, C# and Javascript if you would actually run on all
supported platforms.
What you get
20% to 30% less code
The most work on the app (if it’s not to complicated) is in styling it.
And that brings two problems:
- An iOS app does not look like an Android app and again not like a Windows app.
- There are just a few components you can style. For the most part you start nesting views.
Setting different styles for the different platforms wouldn’t be that bad if there would be a good MVC pattern throughout the framework. But there isn’t. At the moment they introduce a new system called Alloy.
It’s kind of what C# has had for a long time with WPF and Android with its layout components. You define your layout structure with a kind of xml language and style it with css. Unfortunately the current system
isn’t really stable and the most modules available for Titanium are still based on the old “everything in one file” approach.
Try keeping multiple designs with multiple components (which work different on each platform) in one source file. It’s start to get pretty crammed. The fact that you need to add multiple views to generate things
like a padding from one element to another does not help here ether.
Lack of experts
Whenever you’re working with a framework of any kind, you will find two kinds of people working with it.
- The ones who could also get it done without it, but know how much time and effort they are saving.
- And the ones how wouldn’t get it done without it.
Don’t get me wrong, there are many very smart people working on the Titanium project. Way smarter people than me. I can’t imagine what kind of effort and knowledge they needed to put into the project that it’s possible to compile Javascript to native apps in different languages.
Unfortunately those guys aren’t the ones available to answering questions on QnA boards. They are busy solving the big problems. It’s mostly the other part of people hanging in there and searching for the answers. They even promote that in a comment of Marijn Deurloo (CEO,
imgZine) on the Titanium website.
About 70-80% of our code can be reused across apps. That saves us a lot of time and a lot of skill. Its very hard to find different native skills and combine them in one team, but it is comparatively easy to educate people in JavaScript.
Make things easier and accessible to more people is not a bad thing at all. It’s the reason I use it. But it comes with a price. In this case the possible help and learning materials.
Bugs
If all of the above wouldn’t be the case, this would still be enough of a reason to switch. Every software contains bugs. Some are serious, some aren’t important and there are many where you can work around them. But still, every software, every framework and platform contains them.
The problem in using platforms like Titanium is that you’re adding an additional layer of possibilities for errors on top. All errors of iOS will still be “available” with the Titanium version, but you get all the errors of Titanium for free too.
In my case I had a problem, that the app would crash when filling a list view, when resuming to the app from a push notification. For which reason ever the system wanted to access one more element in an array then was available and the app crashed with a IndexOutofBoundsException. This error does just occur when you’re compiling it with Titanium SDK 3.1.*. The only way to work around it is compiling it with version 3.0.2.
Only problem with this workaround: You don’t get the important new features. In my case, the option to add multiple icon sizes for icons needed for iOS 7. I now have to decide whether to let the app crash or not to have icons for iOS7.
In the end
At the moment the app is only available for iOS. Rolling out to multiple platforms would multiply the benefits but also the problems. As a developer today we always have to dance on the fine line between convenience and flexibility. There’s always a framework for something, but you’re always trade convenience for flexibility.
For me the less effort of learning a language has resulted in a dead end. I’m switching to native iOS development and away from Titanium. As soon as you’re diving into those native platforms, you’re going to notice that there are again frameworks and components to help you with certain tasks, like styling. Let’s see how that will work out.