Jul 2
A few months with Titanium Appcelerator
For the last few months as a part of my university studies I have been writing up some course materials for a mobile device workshop. The document that I ended up writing for that grew much more than what I expected (over 100 pages) and barely scratches the surface of the topic. However this is more a review of Titanium Appcelerator.
Platform
So to begin with Titanium Appcelerator is a platform for using JavaScript to build native applications that run on iOS, Android, Blackberry and a few other platforms. If you’ve ever written any code for Java, then the style of coding that you use here is very familiar except the language is JavaScript. JavaScript is a curious language complete with it’s own wonderful set of quirks.
JavaScript is one of those languages that is everywhere. JavaScript is the magic sauce that makes the web go and it isn’t without it’s set of warts. Perhaps the most annoying part for me is the fact that scope is excessively awkwardly defined where you find these situations where a variable is in scope when you really didn’t expect it. This has lead to all sorts of curious patterns in JavaScript to work around these features.
So Titanium uses JavaScript to build a native UI for Android, iOS and BlackBerry. Unfortunately (fortunately?) I didn’t have access to the BlackBerry compatible SDK though with that platform doing it’s best to shoot itself in the foot I don’t think it is too much of a concern. This leaves Android and iOS which were the two platforms that I developed and tested upon for this particular project.
Being a Mac person I have a bit of a bias towards iOS. This is also borne out by me owning an iPhone which means the platform is natural to me. Android ends up frustrating me no end with its flawed and missing support for items. A great example is the constant battle to connect to my university wifi network. I had managed to get it working last week with our testing Samsung Galaxy S but this week it stopped working. Apparently the network is broken however I haven’t had any problems with my iPhone which still appears to connect and work like normal. But I digress, Android seems user unfriendly – or at least unfriendly to me.
So I set up Titanium Developer on my Mac. I have various versions of XCode and the iOS SDK installed already so I had to acquire the Android SDK. That was relatively easy where I downloaded the base applications and then installed all of the SDKs. The important thing, that I found out later, is that the normal API’s aren’t sufficient: you need all of the Google APIs. It turns out to be a lot of data so you might want to be selective for a particular platform (Android 2.2 + Google 2.2 API’s). So that all gets installed and for Android you tell Titanium where it is (XCode and iOS lives in /Developer and is easy to find).
From here you create a new project. This is relatively easy though the pitfall is that it automatically creates a directory for you and if it doesn’t feel you have a particular platform installed it’ll not set up the project to handle those platforms. It turned out at one stage to be easier to recreate the project and replace the JavaScript files.
The next challenge is to get your program up and running in the Android emulator or iOS simulator. This turns out to be easier said than done for Android and often less than 10 seconds for iOS. In my timing Android’s emulator almost always took minutes to start the emulator. Some times the emulator wouldn’t load properly and other times Titanium Developer wouldn’t recognise that the emulator had successfully launched. In these cases you ended up terminating the emulator and starting again. This ends up taking minutes to launch. Eventually the emulator gets itself up after a few minutes (or many more if it fails) and then the application deploys. You find a bug or make a change then want to re-deploy and test on the device. So fortunately for Android you don’t have to restart the emulator, it simply redeploys the application however even this process takes over 45 seconds! This means there is over half a minute of deployment difference between Android and iOS.
Because of this I started heavily developing on iOS and not bothering to test on Android. I didn’t feel that I had the time to waste waiting for Android to launch and be available to me as a developer where as iOS in some cases would be there in a few seconds ready to use (10 seconds at the most). It even kills the simulator and starts from scratch with a clean launch.
The problem that you then end up with the situation where I developed for iOS but didn’t test it on Android. I had faith that if it worked properly on iOS then it would still work fine on Android presuming I didn’t use any “platform specific” functionality. The problem is that it very quickly gets to a situation where everything doesn’t work properly on Android and it requires lots of time to fix the issue. Cross-platform? Not really.
Some of these issues arise from basic differences between the platforms. Android features a lot more hardware buttons including a “menu” button which can popup a menu over the screen to click. The menu is a great way of hiding stuff away and removing it from view. This is important when you don’t have much screen space to begin with however coming from an iPhone perspective where everything is visible on screen some how (even if it is a menu option that hints at more possibilities) this turns out to be rather frustrating as you click through almost every screen until you get to the point where you need to click the menu to progress. iPhone presents everything on screen with hardware buttons to change the volume, a mute/orientation lock toggle, a lock/unlock button and a home screen button. In iOS5 the volume control will also be a shutter button via software control. The flip side is almost anything you want to do is available on screen. There are a few exceptions around pressing down and holding parts of the UI (particularly with text, text boxes, the keyboard and links) which can trigger an extra popup/popover to appear however the norm is very much to have it visible on screen. This means that iOS has a strong UI interaction based around either tabs (bottom of the screen), the “navbar” with back and forwards buttons (top of the screen) or both.
When using Titanium we run into complications. On iOS you could use a tab group and the navbar is free. It automatically puts in the back buttons and the next button (“rightNavButton”) needs to be delivered but all in all not too bad. On Android there are tab groups but no navbar which means you’re using menus. Menus aren’t available on Android but give more UI flexibility than on iOS through having more options. The trap however is that menus and tab groups don’t work together on Android. I’m not sure if this is a Titanium issue but all I know is that it doesn’t work properly when using Titanium. The extra trap is that tab groups and the navbar works fine for iOS applications launched from Titanium’s main context (“app.js”) however on Android you can’t use a menu here. So if you want a menu on the first screen in the app you need to open another window first to create an Android activity to then associate the menu with the window.
And this in itself reveals another slight difference. There is the concept of “heavy weight” and “light weight” windows. iOS doesn’t appear to make any distinction but it very much matters on Android. Another Android feature is the hardware “back” button which permits the user to go back through the interface like a stack. On iOS this is implemented as a top left button on the navbar as a convention however it complicates Android because you end up with the two types of windows. Heavy weight windows create a new context and can be an anchor while light weight windows are ignored. If you open a heavyweight window, then a lightweight window and then click the “back” button the app doesn’t go back to the heavyweight window but to the one BEFORE that one. This may even result in the app quitting. The work around ends up being that all windows have to be heavyweight to prevent a click of the back button going somewhere it shouldn’t.
So once you start working around these platform specific quirks and features you end up with the bugs. One bug I encountered was that setting a top and bottom value for an item would work great on iOS but on Android those values appeared to be added to the parent view or window pushing it down. This perhaps became most obvious when I added a multiple text area option which caused the following undesirable result:
Clearly this isn’t what was intended however the same code works beautifully on iOS devices. I’m not sure if it is a case that I’m doing it wrong or what but fundamentally it is a mismatch between the two platforms. In some cases the problems were that I was using the API wrong and each respectively platform is more tolerant of the others though this only trapped me once or twice. In one situation I was using a platform specific call that wasn’t guarded so it wasn’t run on the other platform which resulting in a weird error that I didn’t fully understand until I took a closer look at the documentation.
And reviewing the documentation is important because on some pages you see a little Apple and little Android logo at the top of the page to signify that it is available on either however you also end up with situations where stuff is only partially available on either. This is distinguished by the text “iOS only”, “Android only” or rough equivalents (yes it isn’t uniform) after the name of the function. In some cases there are also significant behavioural differences. The Titanium.Geolocation.getCurrentPosition call will NEVER (emphasis from Titanium documentation) activate radios on Android instead returning a potentially very stale result. The documentation notes that iOS may activate radios depending if it considers the location data to be “stale”. This means that the most logical and obvious function call doesn’t necessarily make sense to use. The aim of using an abstraction platform like Titanium is that those platform specific differences are abstracted away. Perhaps adding a “maximum age” parameter to the function and then have Titanium automatically do the work needed to update the location details (it is possible by setting ANOTHER handler on the location event to get the position which is the work around I ended up using but that obviates the benefit of having the data cached and not causing a battery drain). Documentation in general is dodgy with this great example from the Titanium.UI.IPad page:
Yes, the page literally just trails off.
It is clear from using Titanium on both platforms that it was originally written with iOS in mind and Android has been tacked on as an afterthought. I’d hate to see what the Blackberry work is like though given the inconsistency between iOS and Android I’m not expecting the Blackberry experience to be much better again.
To make my life easier I constrained my platform to HVGA Android and iPhone. For what I was doing I deliberately excluded working on different platforms and screen resolutions instead hard coding values. Some of this was due to iOS bugs where setting “width: auto” or “width:100%” resulted in child items not receiving touch events on iPhone. This meant that shifting it to a larger screen (e.g. iPad) or changing the orientation presented much white space. However more worryingly I tried out the application on a Samsung Galaxy S running Android 2.1 and the app looks completely different. So this is a screenshot of the emulator running the application:
The layout looks reasonable on Android but here is how it renders on the Samsung Galaxy S:
The interface is almost unreadable shifting from the emulator to the Galaxy S. Fortunately clicking on a textbox and rotating the device yields a full screen edit interface which conveniently provides you with a next button but no indication of what you’re typing into (this isn’t a Titanium issue, but an issue with the Galaxy S or Android; I had a similar problem where I accidentally typed a password into the wrong text box in the WiFi dialog when it was asking for a second username not the password as I was expecting). Perhaps I need to do something more however on the iPad the application renders without issue beyond the immense white space:
This leads me to one final issue with the platform: there appears to be no way to flexibly build a layout using Titanium Appcelerator for multiple screen resolutions that works across platforms. For iOS this isn’t so much of an issue because there is only two resolutions at two orientations (four potential combinations for layout). This means that programmatically setting the values requires at most a combination of four options. Everything else is consistent across the platforms which is useful. However that isn’t the case for Android. Android supports multiple device resolutions at increasing amounts, particularly with the introduction of the various tablet devices. This can cause a pain and perhaps I’m using their layout system wrong with the offsets and sizing however it almost feels like a requirement given the cross section of bugs that I see. The simple vertical style layout work nicely however as soon as you need to mix up the layouts you’re out of luck. Again, perhaps I’m doing it wrong but the most obvious way of doing things seemed to work well on iOS but not so well on Android.
Tools
When I started this project I was using Titanium Developer, a relatively simple stand alone tool which created the scaffolding for a new mobile project, handled compilation and launching the simulator/emulator, deploying it to physical devices or packaging it up for release into the App Store or similar. Titanium Developer doesn’t provide an editor, it is flexible with what ever you use. I tried to use Apple’s DashCode however it kept getting confused and files apparently were being deleted as a part of the process which quickly upset DashCode. DashCode’s package layout also made it impractical to use in reality. I then switched to using Aptana Studio as an editor because of it’s strong JavaScript support. Unfortunately I wasn’t able to leverage much of this but at least there was some support for code formatting and syntax highlighting. I did try some mechanism to include the Titanium API but this didn’t work so well in practice.
The majority of the project was delivered using Titanium Developer and Aptana Studio. The combination worked reasonably well though not as smooth as perhaps the tool integration options that Microsoft or Apple provide – or even to a lesser extent Google with the Java for Android. There is a distinct lack of debugging support so you’re left with logging stuff as your primary method of debugging any buggy application. This means you don’t have a rich interface like XCode to profile and debug an application which is a great loss. The logging worked nicely however iOS 4.3 gave me grief and didn’t appear to work, targeting 4.2 got it back in action though. Logging consistently worked on Android even if I had to sometimes launch the emulator multiple times before Titanium would properly attach and deploy to it. I never had this problem with the iOS Simulator even if the application itself didn’t work. This leads also means that once the Android emulator is up and running you don’t want to quit it however periodically restarting the emulator can fix things. One case in point was when I was working on the location API code it would refuse to say it had an internet connection. I restarted it and everything worked fine there after but that didn’t save me spending an hour trying to work out why my code was broken.
Appcelerator have released Titanium Studio which is an updated copy of Aptana Studio (they bought Aptana) and includes support for their new 1.7 SDK. I didn’t see much of a difference in the SDK for what I was doing and all of the issues I saw with the 1.6 SDK was still present so I’m not sure what they changed however it didn’t break any code so that is a positive. Titanium Studio does feature autocomplete that works, continues their formatter. They’ve dropped support for JSDoc or similar automatic formatting for functions which is a disappointment (Aptana Studio would automatically populate the doc block for a function with the parameters for the function which was good).
For me Titanium Studio was a great improvement. I never once had an issue launching the Android emulator (it was still slow however) like I would periodically have when using Titanium Developer. Using iOS Simulator was still smooth to use as well. Apparently the pro version of these tools (e.g. not the community free download) offer debug functionality. The “Indie” plan is USD$50/month and the “Professional” plan is USD$200/month. XCode 4 with the latest iOS SDK from Apple is USD$5 – however you’ve already paid this as it is a requirement to test iOS applications. So you get a full blown IDE with a graphical layout tool, debugger, profiler and a whole host of tools already then Appcelerator want you to pay another $50/month to get debugging for their platform? You have to pay to get access to API’s like GameKit and StoreKit that you would already have access to normally through the standard iOS SDK.
Conclusions
The benefit for Titanium is to build cross platform applications however the reality is that this is tricky enough as it is. You end up in the valley between the two peaks where you have to deal with both platforms enough times that it isn’t smooth and you lose any advantages. iPad is an interesting case where you have another UI metaphor again with a split view that you would then need to develop an interface to handle the metaphor popular on that platform. This is supported by Titanium (Titanium.UI.IPad.SplitWindow) however we’re now up to a third platform specific UI that needs to be handled. Where does it stop? Blackberry? Windows Phone 7? WebOS? Eventually the application is held together by checks for each platform.
I can’t count the amount of time I spent doing circles on something stupid trying to Google for answers, pouring over documentation and waiting for Android applications to take nearly a minute to redeploy. It was frustrating to have stuff work and not work or then have to rebuild the application because one platform needed something one way and another platform wanted it a different way. Android is even more frustrating because even though I had a 2011 MBP, it still like it is slogging along as slow as anything. Building this app was time consuming as I would spend days in some cases trying to work out why something was mysteriously failing – particularly if it did it on one platform but not the other. The only other time I felt so unproductive was when I was building a Java GWT+GAE application where I ended up with boat loads of classes just to have everything work well (mind you that was more Java’s excessive verbosity than anything).
I believe that while the use of a cross platform toolkit is useful for having the same language regardless of platform (JavaScript), to get the best results the UI layer of an application needs to be platform specific. Even on the simple application I was building it was starting to get to the point where to push it much further would require a large amount of code to just handle displaying an appropriate UI on multiple Android devices not to mention integrating the UI split view and any of the code changes required for that (yet another if statement…). You might be able to get some code re-use here and there but I don’t like being forced to pay to have one set of tools (XCode) to then have to pay 10 times the cost each month (keeping in mind that you only need to pay once for XCode so far, not every month). Once the iOS5 SDK is out of beta, I’m going to spend some time to play with that instead and see where I end up.
Extra Resources
It turns out the best documentation on Titanium are the forum posts asking how to do things and if something is broken. I found a great number of undocumented “features” and “bugs” through reviewing the forums. Google is often your friend though sometimes a trip to the documentation can be equally as enlightening when you read that you’re trying to use an iOS specific feature on Android.
- Quick Tutorial on Navigation Groups (an informative blog in general)
- Use TableView Tips
- Concise example of how to do a menu on Android
- Enabling fake GPS on Android
- Basics of Layout – This is a great comparison of the layout system
- List of Titanium Mobile Events – a concise list of each event for each part of the system in one place. Also listed on individual pages but not always easy to check
- How to use maps on Android – my app worked without this on the emulator and dev environments, I have a feeling it only matters to packaged apps
- Example of how to use a tab group
- Example of Android menu with notes about windows, activities and menus
- Blog about handling CRUD operations
- Example of creating a nav group manually
23 Comments so far
Leave a comment
This was the most informative piece that i have read! Thank you for taking the time and putting this together!
I have been pulling my hair out (yeah, i am almost bald now) for the past 2 weeks trying to port an existing iOS app (that someone else developed) to Android. So far, I got to being able to run the app on the emulator with no errors at all. For that I had to comment out more than half the code.
Thanks for the comparison. Now, I think it is better to have 2 apps for the 2 platforms instead of having conditional logic at every step and making it messy.
Oh and when i said I got to run the app on the screen, it is only a blank screen that i can see – since I had to comment out most of the code so I dont get errored out – either coz it is an iOS only feature or not supported in Android.
Ok, since apparently people are thinking this post is accurate, I feel the need to set a few things straight, since I’ve had great successes using Titanium for about a year now.
1. It seems that the majority of your complaints about Titanium have nothing to do with Titanium. You’re complaining that there are differences between the two platforms, and that Titanium lets you take advantage of platform-specific features, instead of dumbing both platforms down to the lowest common denominator. For example, yes, iOS has a navigation controller that gives you a “free” bar with a title and back button. Android doesn’t offer anything like that, but Android users know that all android phones have a physical back button for that, no menu needed.
2. The android emulator is slow, which again has nothing to do with Titanium. Seriously, Google “android emulator slow”. The difference is that iOS is a *simulator*… it’s a native OS X program that simulates an iOS device, but is very much taking advantage of your Mac’s hardware. For Android it’s an *emulator*, meaning that there’s software that’s pretending to be each piece of hardware in an Android device. On top of that, it’s written in Java (to be cross-platform), which is another level of abstraction from your Mac’s super-fast hardware.
3. Yes, the current Titanium SDK reference guide sucks. The wiki, which was re-launched long after you wrote this post, is much, much better.
4. All tools, including going native, lack an “easy” way to have interfaces that scale across all screen resolutions & orientations. This is currently on the developer to handle, and is most commonly solved by using a MVC pattern, and having multiple views that the app can choose from. Titanium is actually pretty decent at giving you options for handling different screen resolutions, although it seems you didn’t use them. That probably isn’t entirely your fault… I’m sure if the documentation was more clear, you would have found it.
I encourage you to take another look at Titanium. Even with it’s faults, it’s still the best option for truly native app cross-platform development. There’s a lot of us who spend our days helping each other in IRC, #titanium_app on freenode. Titanium engineers hang out in there too, and help whenever they can.
Well I can assure you that this post is accurate and it is a reflective blog post of my experiences with Titanium Appcelerator. I do not come to your blog post and insult you, please do not come to mine and insult me and have the tenacity to evangelise at the end. It does your community no service to have it’s zealots attack end users and then “encourage [them] to take another look”. This isn’t a community I’d like to be involved with. Most importantly you don’t actually point to any of my concerns actually being addressed and end up blaming everything else for the failings and missing the point.
If anything I think the two comments confirm the point that people are experiencing this sort of pain. It is unfortunately an accurate reflection of how the state can be.
1. The point is that this isn’t documented. You end up in this situation where you’re writing code and it doesn’t work. If you use a tab view on either platform (which works fine), you can’t use a menu if you want to use one. Where is this documented? There are tonnes of small undocumented pitfalls in cross-platform compatibility that you learn by trying something, finding it doesn’t work and spending countless hours trying to work out why the menu code you just wrote is wrong until you reduce the app and slow add things back to discover the tabs are killing it (I mean seriously?). If you’re aiming not to dumb things down, don’t pretend to support both equally and clearly mark where there are incompatibilities. I don’t see this happening yet but I welcome you to provide a link to said documentation on the topic. I do however expect something as simple as top and bottom values to behave consistently across both platforms, don’t you agree?
2. I think I make this clear in the blog post. Being a cross-platform project you suffer the criticisms of all projects. You can’t just say “well it’s android fault it’s slow” and ignore it. It’s a valid criticism. You’ll also note that it’s under the “Tools” section heading. It doesn’t come as a direct criticism of the platform though the UI quirks and issues with attaching the debugger for the Titanium Developer app are an issue with the platform tools, you will also observe that I note I didn’t have these problems with Titanium Studio. This would also be less of a problem if it wasn’t for the fact that the platform is less cross-platform but instead “cross-platform but don’t do anything complicated”.
3. The wiki links to the same API reference guide and the same page referenced still trails off into nowhere!. I still can’t find any note that using a tab view with a menu on Android doesn’t work either.
4. iOS doesn’t particularly have this issue because it does have a strong MVC architecture from the get go. Again, documentation becomes a pain point again. The layouts look like they’d solve some of the issues but also appeared to have their own quirks. What gets me is that when I ran it on an actual Android device the UI looked completely different again and had it’s own issues.
You seem to pick and choose things here however. You don’t mention anything about the incompatibilities with the logging between iOS 4.2 and 4.3 (has this been fixed?), you don’t address the fact that it isn’t cross-platform in the sense you end up writing platform specific code. I could write my app in C with a different UI layer for Android and iOS then it’d still be cross-platform. I’d still be writing specific functionality for different apps. And that’s what I’m looking for is that you don’t get stuck painting yourself into a corner because you took a particular approach on one platform that doesn’t work on another. It’s great to provide direct access to named specific functionality, but when I ask for a location – behave the same on both platforms. Abstract away the 100 lines of code I have to write to get it to behave the same on iOS and Android. I don’t need to write those lines, I don’t care. If I use a “cross-platform” development library, I’d like for those things to be taken care of for me and not have to write it all myself, you write it and then thousands of developers are writing apps with those lines copied into each of them to get consistency between iOS and Android!
Finally you don’t quantify why paying $50/month to get access to the API’s is better than the alternatives given one would already have access to when they’ve already paid for that functionality (e.g. iOS developer program membership) when you get a substandard level of documentation, hodge podge support and missing compatibility notes to help avoid you wasting your time. There are enough blogs out there shouting the praise for Titanium Appcelerator, I feel one needs to accept valid criticisms and improve upon it.
As an aside instead of insulting the “accuracy” of my experiences, how about opening without out those first two phrases. “I must admit I’ve had a different experience than you on Titanium. I’ve had great successes using Titanium for about a year now…” – less adversarial, less insulting and when you get to the end where you encourage me to look again, I don’t feel annoyed that you started all of this by insulting my experiences. Particularly when you offer nothing to demonstrate how my experiences could be better in future.
I develop mobile apps for both iPhone and Android using Titanium. I was surprised at your reaction to Shannon’s contribution, taking a defensive stance and claiming to be insulted. His (or her) comments are entirely valid. It is my perception that you consider Android development a nuisance, and would rather not have to deal with it at all. I encourage you to abandon it.
Titanium certainly has its faults. Until recently, the developers clearly favored iPhone and ignored Android, which undercut the entire premise of using Titanium. Allegedly they have mitigated that with 1.8, though as it just came out I cannot say yet.
As far as calling out someone for being evangelical, it is clear you are doing the same in the other direction, intentionally or not.
I disliked the accusation the post is fallacious in the first sentence, “people are thinking this post is accurate, I feel the need to set a few things straight”. I suggest at the end of the reply a much better way to do it that doesn’t make a claim that my post reflecting my experience some how lacks accuracy. I don’t feel I’m taking a defensive stance, I’m merely questioning where the improvements for the issues noted in the post have been addressed.
I think you miss the point if you feel that “Android is a nuisance” is my core problem, realistically I feel the problems could be mitigated a lot better. I spent days trying to work out why a menu didn’t work with a tab view on Android. This I don’t fault Android for: I fault Titanium. The entire point of having a “truly native app cross-platform” development tool chain is that where possible things work sanely in both environments, some environments support more and some support less. The thing that perhaps burned me most was the menus and tab groups: I spent a couple of days trying to get code to work properly at one stage starting from scratch with a simple new app to test bits of code before trying to integrate it into my app. Again, this isn’t Android’s fault but the lag in the emulator doesn’t help and the lack of debugging support from Titanium wasn’t much help either. Of course once I knew that tab groups and menu’s didn’t play together nicely that made my life easier but I shouldn’t have to waste two days to work out something is incompatible, there should be a simple note on the menu page saying “when using a TabGroup menus will not work properly”. It is all of these small pitfalls that once you’ve used it for a while you would know many of the issues and design around them or be able to more efficiently identify and resolve them.
I don’t want to abandon Android, I want the tool chain to be better. I’m sure it can work better but it has lots of places where you end up falling over. The unfortunate thing about being a regular developer in any platform is that you often forget many of those bad experiences you spent before you got to the point of being productive in that platform – it is the little things you take for granted. I was perhaps at the point just before then where you still end up getting frustrated because you don’t know where all the pitfalls are and you’re still piecing stuff together. I definitely concur the developers clearly favoured iOS over Android so perhaps I’ll give 1.8 another hit to see if things have improved. Looking through their API docs for 1.8 it appears to have fixed the iPad page by removing the section in question entirely.
To be honest pasamio’s comments are some of the most crazy eyed, foaming at the mouth, internet blogger type reactions I have seen in some time….
Disclaimer: Never used any tools such as Appcelerator for cross platform apps, just doing research to see if I should start doing this.
Cross platform development is an absolute pain no matter what you use (if you wish to produce a native app for each).
In particular in my experience across Android, and iOS native app development iOS provides really nice ways to handle the different screen resolutions in the ecosystem where as the Android approach is pretty manual. I think thats partly because they have no control over what crazy resolutions the manufactures are going to put out today, tomorrow and the next day.
One of my issues with Android here is that you end up having to test on all devices to see how things behave, which I more acknowledge as an Android problem than a Titanium. It sounds like Titanium’s got some better layout solutions that should make things more easier in handling cross platform layouts though the annoying bit is that the KitchenSink demo didn’t use much of it in deference to manually positioning everything (at least at the time I was working on this).
I seriously just want all of this stuff to be better and the point of the post is to acknowledge things that don’t work and things that do work. The observation I make that I feel is missed is that using Titanium isn’t too bad but split out the UI aspect. Almost everything else underneath is reasonably consistent across platforms (e.g. you can read contacts on all platforms but not write) and permits you to be generic however once you start playing in the UI layer and trying to make that play nicely you end up in a world of hurt. Sometimes undocumented hurt that takes you days of testing until you find the little addendum to a forum posting somewhere saying the little piece of information you need. There are some places where I feel Titanium could abstract away the differences, the example being location on Android versus iOS which requires extra code to behave similarly. Why not provide an API that behaves the same way and a more low level API to provide more direct access for those who feel they need it?
These are things that can be addressed and improved with time. Perhaps with the extra focus on Android some of these quirks will end up resolved.
I can personally vouch for what pasamio says. Having dealt with Titanium appcelerator for more than a year(2 full applications), I must say it is certainly not worth the trouble for anyone who is serious in developing mobile application.
For those who are still sceptical, please have a look at a few examples below:
http://developer.appcelerator.com/question/117540/textfield-on-tableview-loses-focus-android
http://developer.appcelerator.com/question/130158/text-field-weirdness-on-ios-simulator-and-differences-to-android-implementation
Basic functionalities often contain minor yet important bugs throughout titanium appcelerator which makes it highly unstable once you probe further than to try to make simple windows and pages in your project.
There is also a seemingly lacklustre effort to patch the bugs as many of them which have been reported more than a year ago remain unresolved.
Let me reiterate the most important point: For those starting out on mobile development: DO NOT MAKE THE MISTAKE OF DOWNLOADING TITANIUM APPCELERATOR OR YOU WILL SPEND MANY HOURS LIKE ME AND THE BLOG AUTHOR FIXING IMPOSSIBLE BUGS WHICH ARE SO TRIVIAL YET UNSOLVABLE ON TITANIUM.THERE ARE A LOT MORE BUGS YOU CAN EASILY FIND BY VISITING THEIR Q&A PAGE AT http://developer.appcelerator.com/questions/newest
Those who say otherwise, please backup your claim with sound examples, or stop spreading misinformation on the internet.
Thanks to everyone for their comments; the somewhat heated debate is expected as I’ve never seen any dev env not have passionate follows of any given discipline (thus, disciple).
Having worked with iPhone then Android on an app I’ve been considering Appelerator for some time; most of the comments were expected knowing how the two platforms differ but there were definitely some surprises (especially in areas I’ve not dealt with cross-platform-wise).
Thanks to pasamio et al for helping us Titanium newbies!
After over a year and 2 apps developed I can state that Titanium does NOT deliver its promisses.
It is just bad for business. Now we have 4 source bases for 2 projects to deal with the huge differences between the platforms.
Titanium hangs, is buggy, supportless, has no helpfull community and has a careless development team.
Doubt anyone that guarantees it works as it was supposed to.
Just to make it clear, I’LL NEVER USE THIS PLATFORM EVER AGAIN.
I’ll vouch for everything said on here. My company has spent far too much time working through the countless bugs in Appcelerator. Far too many functions/methods simply don’t work from one platform to another and far too little, too late support to help out.
The developers missed the point altogether – rather than continually adding new features they should have spent effort fixing the errors in the base functionality and sent more time on support and docs. It still didn’t allow you to do anything other than read xml (no appendChild etc) the last time I checked.
What a shame – it’s such a cool concept. Just really badly executed and supported.
We’ve abandoned it altogether and are planning a ritual burning of the source code we put into it. Totally wasted time and effort.
From now on we’ll just develop on Java on Android and Objective C# (shudder) on iOs.
Why did you pick Objective C# over Objective C or Objective C++?
Hi Pasamio,
thanks for your extensive review of your experiences with Titanium.
May I ask whether you have investigated other cross platform mobile app tools and if so what are your thoughts on them?
Thanks
Hi John,
I haven’t looked at any of the other cross platform toolsets yet so I can’t adequately judge anything beyond what I’ve documented with Titanium.
Cheers,
Sam
Well. I found this to be most informative and it’s pretty obvious there is a problem with Titanium. I had actually just finished setting it up, had some error with part of the Android SDK setup of all things and was searching online when I came up this site.
I have now uninstalled the whole thing and will be sticking with iOS dev only.
I was going to test the Android waters as it were, but will just avoid it for now.
Excellent job, thanks for saving me what I can see would have been countless wasted hours.
😉
I’m scared to death after reading this blog. Titanium seemed like a cool idea. I just spent about 60 hours building an iPad app on Titanium, finally got it all working in the simulator…but it won’t deploy to my device. Then I read this and I’m scared. 🙁
Hopefully I can deploy it to the device and hopefully it will work. Has ANYONE had success with titanium?
Thanks for interesting reading. I’ve just started to look into Appcelerator and have read some negative comments/reviews about it. It makes we wonder if it’s worth the time or if I should walk on by.
I’ve developed a few iOS apps (both iPhone & iPad) and feel comfortable with Objective-C. The problem is that I want to develop for both iOS & Android and I don’t want to write everything twice, in two different languages. I understand that “write once run anywhere” won’t be the best solution for the GUI code, but for instance the models and business logic (thinking MVC here) can be shared. So I would probably write 2 seperate projects for the two platforms and share only the non GUI stuff. That way I could use the most proper design for each of them.
Wouldn’t this solve much of the problems you’re having? I mean, developing in Javascript is a lot faster than both ObjC & Java, which are both very verbose. At least when one can write much of the code once.
What worries me are all the talk about memory leaks and other bugs. THAT to me is critical. Do you (or anyone else reading this) know any specific API’s which are particularly buggy?
Thanks 🙂
I wouldn’t write different projects for the different platforms of course, but something like this:
var ApplicationWindow = null;
if ( Ti.Platform.osname == “iphone” ) {
ApplicationWindow = require( “ui/iphone/ApplicationWindow” );
} else if ( Ti.Platform.osname == “ipad” ) {
ApplicationWindow = require( “ui/ipad/ApplicationWindow” );
} else if ( Ti.Platform.osname == “android” ) {
ApplicationWindow = require( “ui/android/ApplicationWindow” );
}
if ( ApplicationWindow != null ) {
new ApplicationWindow().open();
}
and then have 3 different gui setups.
This is how development for universal (iphone/ipad) app allready works, two different app delegates.
Apart from the areas I noted, I’m not familiar with memory leaks and what not. Some of that appears to be side effects of app design that might be remedied however I’m not entirely sure.
I definitely agree that if you set out to achieve different UI from the beginning then this will make your life easier. In a sense parts of the app I built ended up like that though not quite as well structured. The problem is that Titanium sell themselves as truly cross platform when in reality you very quickly end up with platform specific checks all over the place. However most of the low level stuff is reasonably safe though again you need to be careful – merely getting your location can quickly land you in platform specific code as well as between Android and iOS there are differences in behaviours.
My best advice would be to try something simple enough that you can do it quickly but complex enough that you will run into problems you’re more likely to face than the straight forwards template or “Hello World” apps will take you. You need to explore beyond the well practiced tutorials to really see the gotchas that you’re going to face.
Fundamentally I feel that both Google and Apple independently have the best documentation for their platform which also helps when you’re trying to work something out. Each platform has their quirks and any cross-platform library is going to have issues covering those quirks however when your cross-platform library introduces it’s own quirks on top of that it sometimes becomes a wack-a-mole to track down individual behaviours.
I can confirm that Titanium still does not work. After having finished implementing an app natively on iOS and then on Android I was curious about about Titanium. With my recent experience with the quirks of both platforms I set out to remake the app with Titanium. I didn’t get very far before it broke.
The part I actually liked with Titanium was building the gui with code. It seemed easier than both native platform approaches.
For my next app I will stick to dual code bases. But if you have a lot of business code
there are two approaches that might work:
1. Put the business layer code on a web server. Use web service calls. Could be slow.
2. Use a Java C/C++/Objective-C cross-compiler. I haven’t researched this but it would seem possible to make such a tool. Since the could would be free from platform specific api calls it should work.
Anyway, I too blogged about Titanium: http://arneevertsson.blogspot.se/2012/03/titanium-breaks.html
Yes, there are some quirks with Titanium. Yes, it may not be the most user friendly when it comes to knowledge base. Yes, write once, run anywhere may not be 100% true. BUT….
If used for small, simple apps… Titanium is best. If you are a gamer, don’t even bother. But if all you are interested in is a few animations, few screens, tables, views, Titanium does provide the lowest common denominator to cross platform without issues.
With Titanium you also need to understand the boundaries, as iOS and Android do not have the same API’s.. if you use one of such API’s in Titanium, you can’t expect it to work cross platform. If you pick things that are common, you are in the money.
I have developed over 4 apps on Titanium, and still believe it is the BEST cross-platform tool that churns out native applications.
Oh forgot to mention, the amount of time it takes to develop using Obj-C… and again using Java for Android…just doubles everything.. resources (different heads), costing, timelines, etc.
Titanium on the other hand is more RAD, once you have a environment ready, quick to develop, test, sign, package & publish.