Why you should stay away from Appcelerator’s Titanium

Let’s face it – programming on mobile devices is hard: everything’s much more complicated to accomplish than it is on the web or the desktop and, since the platform is fairly new, tools and frameworks are scarce and poorly refined. Plus, if you need your application to run on more than one target OS (iOS, Android, Blackberry) you’re pretty much forced to write a different application for each one of them.

So, enter Appcelerator’s Titanium – what Titanium aims to accomplish is to solve most of these problems, by hiding all the gory implementation details behind a simple and well-defined javascript API. On top of that, it will (more or less) compile your javascript to a different language (objective-c for iOS, Java for Android and soon Blackberry) so you can deploy your application to multiple targets with (supposedly) no changes to your code. And it’s free! Support and other goodies come for a price but the library itself is free for commercial use.

What’s the catch then? On the surface, it’s all good – you pop up Titanium Studio (a modified version of Aptana), write some trivial javascript and you’ve got a working, native app. Great, it took me a day or two to do this in native objective-c – with Titanium, it’s a couple of hours! So you dive head first and build more and more complex apps – animations, database connection, networking, geolocation, it’s got it all!

The more complex your applications become, the more often you encounter some weird glitches – why the navbar’s title not centered? And why sometimes the navigation controller doesn’t pop the last view? Or why the focus event gets called so often, for no reason, only on the device? But you know, Titanium’s so much better than going back to native development, so you deal with all its quirks and carry on. Until bad stuff starts to happen.

Your app starts to crash, seemingly at random. The reason : memory starvation. You see, although Titanium is supposed to take care of memory management for you, it doesn’t always work correctly. Most of the times, especially if your application is simple and doesn’t use many images and animations, the memory leaks Titanium generates over time will be small enough that you won’t even realise that your application is actually leaking. Problem is, when your application reaches a certain level of complexity, those leaks will become evident – in the form of sudden, unavoidable crashes.

There are some hacks, proposed by Titanium’s community that somewhat help to free some memory but they don’t always work and, even when they do, they don’t release all the memory they’re supposed to. Titanium doesn’t let you change your object’s reference count directly (probably because that would break some internals of theirs) so you have no way to dispose of objects yourself.

This leaves you stuck with a frail, buggy application that is ready to blow up at every click… and there’s nothing you can do about it except for a complete rewrite in objective-c or java.

Are you planning to develop mobile apps with Appcelerator’s Titanium? Think twice. It’s tempting but you really, really don’t want to find yourself stuck like it happened to me. Unless it’s either for small, simple applications, or they somehow manage to solve all their memory issues, I strongly suggest you to stay away from Titanium.

About these ads

301 thoughts on “Why you should stay away from Appcelerator’s Titanium

  1. Andrea – it looks like your argument is based primarily on memory management, which has been addressed in 1.7. There are other issues that we are addressing on an ongoing basis, but the showstopper that you addressed in this post should be largely resolved. Please ping us at community@appcelerator.com if you’re still having issues.

    Thanks,

    Scott Schwarzhoff
    VP, Developer Relations

  2. While I’ll gladly send you information about the project I’m working on (so you can maybe give me some pointers on how to salvage the situation) I have to say that 1.7.0 does NOT solve the problem at all. In fact, I’ve waited to publish this post until 1.7.0 was out, since Appcelerator said it would have solved memory management issues on iOS. Sadly, it didn’t.

  3. good post! After using titanium for iPhone and android for a while, I too noticed a lot of memory problems. Every app made with titanium dies after some time due to memory starvation. The titanium environment is far from stable. And stability on android is even worse compared to the iPhone version of titanium.

    Apart from the memory problems, there are other strange bugs which you need to solve with all kinds of workarounds. For instance, if you load images from an url, it sometimes (randomly) does not work. So you need to write timers to check if the image loading has failed and retry, because an error-event is not available.

    And finally, their documentation sucks bigtime. Undocumented arguments, undocumented object properties, undocumented members. I recognise your frustrations: it all looks simple at first, but when you’re halfway your project with titanium, you encounter all kinds of problems which take you hours of googling for answers, sometimes to no avail.

  4. I’ve to fully agree with Miele, and the writer of this blogpost.

    You start your new project with appcelerator, and make enormous progress during the first days.
    But then when your application begins to get more complex, all the glitches show up, and some of them
    are so basic (especially Android), that I’m surprised that titanium is branded “Stable”. I used Titanium for android, now for 8 weeks and are stable (As far as you can be stable with titanium), I knew it would have taken me 10 weeks in java. So how come that appcelerator didn’t save me that much time? Well again because of the bugs, you need to work around, use it differently, you need to understand the API which has bad documentation. You need to work around natural limitations due to the API etc..

    My verdict for Titanium is that is an awesome project, and indeed can save you lots of time, but it is way too early to use it for production releases (except you have an ultra simple app).
    I read somewhere, that they raised a significant amount of money, so I hope development will now accelerate and the quality of the releases will hopefully increase.

  5. If you are an experienced developer you must know that there is no perfect cross-platform solution. Sooner or later your are going to run into problems with the technology that makes your cross-platform development possible, regardless of whether it is Appcelerator Titanium, JVM, PHP module for your web server, your favourite ORM or something else.

    The good thing about Appcelerator Titanium is that it is open source. Developing separately for each platform is too much for your company and Titanium Mobile or PhoneGap or whatever is too buggy or doesn’t work as desired? I think learning some C++ or hiring people who know it and fixing Titanium Mobile is preferable to branching your development for every single mobile platform out there.

    • We weren’t expecting Titanium to be perfect. It’s good that Titanium is open source but if you’ve ever explored the source (I have) you’d know that it’s more or less impossible to make any kind of useful modification to it without knowing the whole project in depth. Hiring people to work on that, for months, just to have a bug fixed or two is absolutely not viable for a customer who just wants to have a working mobile application.

      Developing a different application is the way to go if you want a native app on every platform – if you think about that, it’s even wrong to have the same source for different platforms, since the interface paradigms are different for iOS, android and blackberry.

  6. Pingback: inconsequence » Blog Archive » Adventures in Mobile Development

  7. I like the post and that you waited for any updates to make it a fair and honest test.

    These kinds of experiences show why offbeat languages with compiled translations aren’t a lasting solution for mobile app development. HTML5 as a standard language and WebKit as a rendering engine are not developed and owned by one company like Titanium is. Native app functionality is coming to the browser and that’s where apps are going to be created going forward, not with proprietary tools like Titanium (appcelerator), RFML (red foundry), Corona (Ansca), and even Lua. Some people say web browsers aren’t fast enough, but the trends are all correcting that – CPUs keep getting faster, WebKit keeps getting faster, and some phones will even have GPUs soon (Snapdragon chipset). Any lingering questions about HTML5′s ability to be the unifying technology for mobile will go away in the next 12 months.

    • Its now 2 years later, and this dream is still a dream, Solutions like Gideros and Corona are still the only stable cross platform Game building engines around with any reasonable support and good built in native engines such as physics, 2D and 3D engines, I have wrote and release 1 Game on HTML5 into IOS and Android, and needed to do some tricks to complete animation loops if they didn’t complete on time for Android devices.
      Appcelerator is currently under my testing, worked first time for ios, but can I get an Android one working? I have tried everything, for a package it should be one installation and have all the components ready to run.

  8. While the verbiage here is a little more harsh, this echoes a lot of my worries about developing anything more than simple cross platform apps with Appcelerator. The deep integration it gives you, down to the UI, comes at a price. A price that you are obviously aware does not rear itself until you are already a few cycles into a project. And don’t get me started on the Android inconsistencies…

    All that said, for pure iOS development I’ve had a very solid experience, even with more complex projects.

  9. I gotta be honest – I had the same gripes about appcelerator when I first started out. My start up uses the platform to build mobile games and the first few cuts of our flagship app ran into massive memory issues that caused crashes every 30 or so seconds.

    What I eventually figured out is that appcelerator apps run great if you contain everything inside the same memory context (i.e. javascript interpreter). This is pretty tricky since it means you need to include all your code in app.js… this approach gets unwieldy after a while.

    To solve the problem I wrote my own simple JS framework to allow me to include all the code I need at build time while still being able to split it out into distinct files representing the different screens and framework modules in the app. So… in titanium studio everything is neatly, logically organized and when my app builds all the code is munged into one big chunk of JS source with each required piece of required code in-lined and executed only once.

    I also started letting the javascript VM manage memory for me instead of trying to pre-load resources. It’s pretty efficient when it comes GC if you’re not holding references to orphaned objects or doing something weird like spawning more than one memory context and loading your entire app into it.

    Since following this approach all our memory issues and crashes have been fixed, which was a surprise since the app is fairly large and complex (the total size of the ipa comes in around 17.5Mb).

    • HI Dan,
      Good post. I am using the CommonJS way of doing things in Appcellerator. I don’t seem to have any problems, but I don’t have much experience with any other methods.

      Is this similar to what you are doing?

  10. Love the brutal honesty here. It’s always best to learn from others’ mistakes if possible. Still cogitating myself. Yes, Dan, please clarify how your JS framework pulls the entire distributed app into a single app.js memory context at build time.

  11. Vote up for brad. We’ve struggled with memory issues as well, but moving our app structure into Tweetanium-like single app context have solved it. Absolutely recommends giving the Tweetanium project structure a closer look.

    That said, agree with author.

    By the way, Appcelerator Training vote for single context apps whenever possible – perhaps recognizing the still present memory issues

  12. I don’t mind the iPhone experience (but our relatively simple app is weighing in @ almost 10 MB.. ehh gads), but android is quite possibly one of the most painful “this is easy!” experiences I’ve ever had in my programming life. I upgraded to 1.7 and our already unstable android app isn’t even usable anymore and I’m so close to just scraping all the work I’ve done out of frustration.

    Its good to see I’m not alone in thinking that appcelerator is barely beta-worthy… was beginning to think I was the only one experiencing tons of issues with it.

  13. If anyone reading this post has questions about Tweetanium and the single context approach, feel free to ask me – I wrote that app for Appcelerator (I’m an employee).

    Also, as Scott mentioned we did have some fairly significant memory management fixes go into 1.7.x – I’m sorry to hear that simply upgrading did not solve your problem. Couple points I wanted to make though:

    - It’s very possible to build non-trivial applications with Titanium. NBC’s flagship iPad app and the Late Night with Jimmy Fallon apps are all built on Titanium. Wunderlist, a top todo list app for Android, iOS, and desktop is built with Titanium. The list goes on – feel free to tweet at appcelerator and we’ll rattle off as many as you’d like.

    - Our API is large and dynamically generated, leading to some holes in our API docs. We’ve in the last few weeks creating tooling which analyzes Java annotations and Objective-C, giving us solid numbers on API doc coverage of properties and functions exposed to JavaScript. We think we’ve identified most of the holes and will patch them as soon as possible.

    - It’s true that you can’t manually manage your application objects’ reference count in iOS
    applications. There are, however, things you can do to free up memory – the big ones in the 1.x product are closing windows (which releases all UI resources associated with the window) and setting references to a proxy object (like one returned by Ti.UI.createXXX) to null, which will release the resources associated with that object.

    - We do have some cross-platform parity issues due to the organic process by which our APIs have grown and matured. We’re counteracting this internally by writing specifications for existing and future feature sets, which will be used by our engineers to guide implementation and test writing and our QA team to make sure we’re faithfully implementing the spec. Layout issues are the worst offender right now, which was the spec we wrote first about a month ago. We should start to see improvements in cross-platform uniformity starting in 1.8 (beyond the simple fixes/patches released in 1.7). All current and future feature sets will be spec’ed out in this way.

    Titanium is not idiot proof, not by a long shot. We know we have work to do to make the platform more stable, and we need to provide more and better guidance to put people on the path to creating successful applications. Doing “best practices” sample apps is part of that, and I personally will be creating many more in the coming days and weeks in addition to Tweetanium. The first will be a CRUD app called TiBountyHunter, which you can watch for in the appcelerator github account (should be pushing it late this week or early next).

    That said, many, many developers have successfully used Titanium unmodified to deliver applications. Many more have extended Titanium to fit their needs. Titanium can and does work for many developers, and I hope you will count yourself among them soon.

    • Hi kevin. First of all, thanks a lot for your reply, it’s great to know that you’re actually listening to complaints :-)

      I’m really sorry that I have to stress on this point but let me state that again: memory is *not* consistently freed after setting references to null. Same for putting views inside a window and then closing it. Sometimes it works – oftentimes it doesn’t. We’ve spent at least a week trying to find a consistently working strategy to free the memory, and we weren’t successful. When closing a window, sometimes memory is just not freed. Sometimes memory spikes up after trying to close a window. Some other times it just makes the app blow up. This behavior gets much worse if you try to dispose non-titanium objects – say, objects you’ve created to pass around data coming from a database.

      Except for the complex one, we also have a much simpler application written in titanium. The target was iOS only at first, then the customer asked for an Android version. Long story short, we opted for a full rewrite in Java because just trying to run the unmodified application in the Android emulator was a waste of one working day.
      True cross platform development is very, very far away with Titanium. And, in my opinion, rightly so – iOS and Android have very different interface paradigms and trying to write just one application for both of them is like trying to fit a square peg in a round hole.

      We weren’t expecting Titanium to be “idiot proof”. We just wanted a solid abstraction over the iOS SDK. At the moment, Titanium doesn’t provide that. And writing applications in Objective-C is actually very pleasant… so the only motive to use a tool like Titanium is, in my humble opinion, being able to deploy the same code on more than one platform. As I explained before, I don’t think that it even makes sense and, even if it did, Titanium’s not there yet.

      My humble suggestion to fix things is: 1) Feature freeze. Right now. 2) Fix *every*. *single*. *bug*. in your codebase. 3) Release better and complete documentation. After that, you can start to think about what you want to add next.

      • does objective c have a feature to freeze the webView I need to load another webView in parallel to get some information from another html

        • Does anyone know where i can buy a 10mm spanner to fix my car?…………………….Sht sorry wrong place to ask! i might try google…You should as well Mona ;)

    • Hi Kevin,

      I just posted about an hour ago at the end of the thread and just read your comment. I am looking at your Tweetanium example and trying to figure out if I should move forward with this model. My main question (probably a bit of a newbie one) is how I would use views to navigate into other views and then come back the way you can with windows. My other option is to use the Tweetanium model for the top most level but then create windows as users click to go deeper into the app.

      The other question I have is around whether or not you would recommend just trying to stabilize my window-based solution. I’m not doing anything out of the ordinary but the app does crash from time to time and I do need to spend more time profiling.

      Thanks!
      -Derek

  14. I second Kevin here. I have build a few apps, some fairly complex, and indeed I’ve ran into memory management issues initially. Following the Tweetanium approach, testing and branching my code as I progress, coding following JavaScript memory management model to take advantage of GC, has allowed me to write steadily stable and predictable code. There are definitely issues with cross platform consistency, some methods behave differently. Perhaps, it is just that after 10 months of Titanium development I’ve grown to work with it more intuitively. Nevertheless, I love the plattform, it has practically changed the business model of my company. No way I’ll go back to Objective-C , other than for writing Titanium modules.

  15. I don’t care. I’ll just create simple apps. Although, it is true. i dont know about memory starvation but i have found some unidentified errors.

  16. Pingback: Appcelerator Titanium evaluation | Softaria

  17. The bottom line from the comments seems to be:

    1) Ignore all the “getting started” tutorials and program things in the Tweetanium style. (Not that this app will not actually *run* in Appcelerator any more. Hasn’t been updated since January.)

    2) Stay with version 1.6.2, else table views will crash your app. http://jira.appcelerator.org/browse/TIMOB-4892

  18. Hey Guys, sorry for the slow response – completely forgot about my comments here.

    Yup, using a Tweetanium style approach you keep everything inside the same memory context.

    When you include a file using Ti.include what you’re actually doing is in-lining code at “compile” time. Appcelerator will take all your included files and munge them into a single source file, do some optimization and symbol replacement, base 64 encode it and embed it into your resource bundle.

    The main problem people run into is that they keep instantiating windows using a JS file “url” (known as a heavyweight) – this spawns an entirely new JS interpreter that’s unable to share memory with your other processes. People then tend to leave their windows open instead of destroying them… meaning you end up with a bunch of useless copies of your app hanging around in memory in the background not really doing anything.

    The approach we used was to write a window management system that wraps all the window initialization code up in closures tied to “window” objects. The JS code for these “windows” is broken up into individual files that are then included en mass using Ti.include statements after the the window manager is initialized. A self executing function in each block of code automatically adds the instantiated window objects to the window manager singleton instance.

    So we can spawn a fully configured lightweight window in the same memory context using a call like:

    WindowManager.openWindow(name, args)

    And destroy it when we’re finished with it using a call like:

    WindowManager.closeWindow(name)

    In practical terms all we’re doing is making sure all our code is included in app.js at compile time, and executed in the same interpreter at run time. Seems to work so far.

    • Hi, it looks like you found the solution for the main problematic issue in titanium. can you please give an example to the WindowManager that you had build?

      Thanks alot

    • Is this the sort of window management you recommend? The window parameter being passed is an instance of Titanium.UI.Window.

      	// The window model
      	Application.models.Window =
      	{
      		
      		// The current window
      		window: null,
      		
      		// Open a window
      		open: function (window)
      		{
      			
      			// Close any current window
      			if (null !== this.window)
      			{
      				this.window.close()
      			}
      			
      			// Add the event listener
      			window.addEventListener('close', function (e)
      			{
      				Application.models.Window.window = null
      			}
      			)
      			
      			// Open the window
      			window.open()
      			
      			// Store the window
      			this.window = window
      					
      		},
      		
      	}
  19. I’ve been having lots of memory woes with my app since it has so many features (5 tabs each with a drill down menu). I sloppily changed it to the Tweetanium structure and its working much better. It still crashes here and there but I think that’s more likely all the HTTP requests I’m doing which can lead to race conditions in certain areas.

    All in all I’m grateful to Titanium for allowing me to make such a slick looking app so easily but they still have a long while to go before you can begin to match the stability of a native app. It’s really a pain to spend ages on a project only to find yourself running into Appcelerator’s limitations and then having to hack around them.

    My biggest issue is the lack of clear documentation or development process. I found no clear indications of what “good practice” in Titanium was just starting out so I copied the Kitchen Sink app WHICH IS NOT WHAT YOU SHOULD DO! They even say so in the small print somewhere. After spending a few days getting everything into one namespace (ie not making windows with a URL argument) I then ran into these memory roadblocks. Now I’ve done some quick hacking to make it work again but at this point I’ll definitely need to complete restructure the code to make it clean and coherent before release since I’ve changed design paradigms so many times at this point.

    I hope with time Titanium will release more walk throughs, improve their documentation to include all arguments (did you know you can assign down states for iPhone buttons? It’s not in the API!) and release some clear design patterns for future apps. Great idea, great execution, bad follow up!

  20. PS: Some one other nice bonus of Titanium is that the .IPAs it builds for iTunes for device testing can be directly uploaded to TestFlight for team debugging.

    To balance that though is probably my greatest gripe: debugging. I’m constantly running into problems in debug mode that crash the iPhone simulator with null warnings and are often unrepeatable or don’t happen with breakpoints or prints. Having to find these nuanced errors, typically dealing with race conditions and the like, can be a real impediment. Especially because each solution seems to cause yet another similar problem. My lack of good program design doesn’t help but I blame that on Appcelerator not outliing good design policies.

  21. From my answer to a Stack Overflow question. I’m not trying to bring Appcelerator down. They have an amazing technical product. But their lack of process is killing it:

    The Good:

    Can create iPhone apps using very simple Javascript.

    The Bad:

    Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn’t responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api

    “Native Widgets” are used, but only nominally: there’s a layer of logic and abstraction between them and your code; and this layer changes their behavior and reduces their speed. The difference is visible in the Showcase apps.

    API docs are perpetually out of date. (no process for refreshing).

    A wiki was created, which is becoming out of date. Editing only
    allowed for employees.

    Github projects do not have wiki enabled.

    Appcelerator isn’t true open source: they do not accept contributions from the community: The titanium_mobile project on github has a long list of open pull requests.

    The help forum software has many technical & design weaknesses.

    Email notifications from the help forum often do not work.

    Staff rarely answers questions in the Q&A forum. Haven’t been seen
    in months.

    Showstoppers appear continuously in “all the little gaps”:

    Correctly displaying images on the iPhone 4

    Correctly loading images in a scrolling list

    Although the platform does simultaneously support iOS and android,
    the library/framework does not. A lot of runtime testing (if/then’s) is needed in apps that will work on android and iphone.

    Continually releasing new products but not fixing existing products
    and website problems. The “new” products are announced while in beta and release candidate phases.

    “Chat with Sales” app not attended to.

    Appcelerator does not take down outdated training videos.

    Stretching the truth and bait-and-switch with pricing: a 30% sale
    only applies to yearly memberships, not month-to-month. The blog
    posts & marketing materials do not state this. Only upon checkout is this shown.

    [Seen 8/13/2011] Another way in which Q&A forums are broken: The order of
    results for a search is trashed: each page of results orders its hits from oldest to most recent, at the bottom of the page. Go to the next page of results (i.e. 51-100), and again, the 1-year-old hits are
    first, with 6-weeks-old at the bottom.

    My Unanswered Questions:

    [Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff and receive sub-par treatment.]

    Results:

    Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.

  22. Wunderlist did drop Titanium. I ran a logcat on my device before and after the update. Sad, because before much like the OP I wanted to like Titanium. Anyway…

    Before the update…


    /TiApplication( 4180): (main) [0,0] checkpoint, app created.
    I/TiApplication( 4180): (main) [189,189] Titanium 1.7.1 (2011/06/21 14:28 293a6d)
    D/dalvikvm( 4180): GC_FOR_MALLOC freed 3412 objects / 301696 bytes in 69ms
    I/TiRootActivity( 4180): (main) [0,0] checkpoint, on root activity create, savedInstanceState: null
    I/TiApplication( 4180): (main) [1,1] Analytics have been disabled
    E/TiApplication( 4180): (main) [125,126] APP PROXY: [Ti.App]
    D/TiCommonContactsApi( 4180): (main) [22,148] Using newer contacts api. Android SDK level: 8
    D/dalvikvm( 4180): GC_FOR_MALLOC freed 4936 objects / 400416 bytes in 44ms
    D/KrollContext( 4180): (kroll$1: app://app.js) [161,309] Running pre-compiled script: app.js
    D/TiScriptRunner( 4180): (kroll$1: app://app.js) [18,327] Executing script: com.wunderkinder.wunderlistandroid.js.app
    D/KrollContext( 4180): (kroll$1: app://app.js) [5,332] Running pre-compiled script: js/backend/wunderlist.globals.js
    D/TiScriptRunner( 4180): (kroll$1: app://app.js) [18,350] Executing script: com.wunderkinder.wunderlistandroid.js.js_backend_wunderlist_globals
    D/KrollContext( 4180): (kroll$1: app://app.js) [26,376] Running pre-compiled script: js/backend/wunderlist.js
    D/TiScriptRunner( 4180): (kroll$1: app://app.js) [12,388] Executing script: com.wunderkinder.wunderlistandroid.js.js_backend_wunderlist
    D/KrollContext( 4180): (kroll$1: app://app.js) [3,391] Running pre-compiled script: js/backend/wunderlist.language.js

    and afterward:


    D/PackageManager( 1089): Services: com.wunderkinder.wunderlistandroid.api.SyncService
    D/PackageManager( 1089): Receivers: com.wunderkinder.wunderlistandroid.widget.WunderlistWidget com.wunderkinder.wunderlistandroid.receiver.ReminderNotificationReceiver
    I/ActivityManager( 1089): Force stopping package com.wunderkinder.wunderlistandroid uid=10061
    W/PackageManager( 1089): Code path for pkg : com.wunderkinder.wunderlistandroid changing from /data/app/com.wunderkinder.wunderlistandroid-2.apk to /data/app/com.wunderkinder.wunderlistandroid-1.apk
    W/PackageManager( 1089): Resource path for pkg : com.wunderkinder.wunderlistandroid changing from /data/app/com.wunderkinder.wunderlistandroid-2.apk to /data/app/com.wunderkinder.wunderlistandroid-1.apk
    D/PackageManager( 1089): Activities: com.wunderkinder.wunderlistandroid.activity.StartupActivity com.wunderkinder.wunderlistandroid.activity.TabHostActivity com.wunderkinder.wunderlistandroid.activity.LoginActivity com.wunderkinder.wunderlistandroid.activity.ListsActivity com.wunderkinder.wunderlistandroid.activity.TodayActivity com.wunderkinder.wunderlistandroid.activity.OverdueActivity

  23. Hello all,

    Very interesting comments.

    I want to add that after app crashing, now it is Titanium Studio itself which is crashing on my macbook pro without knowing why. And unfortunatly, when I google the issue, no answers !!!

    Unfortunatly, I believe that all the comments on those posts about Titanium issues are reality.

  24. Thank you for writing this blogpost. I’ve been thinking about wenting my frustrations myself but haven’t been able to bring myself to it. I’d just like to add that most of the discussions here are regarding the iPhone side of things. The android side is even worse.

    I’ve seen (and made) a lot of suggestions that they should have comments enabled on their API-documentation so that at least users can help eachother when it’s plain wrong or just dodgy but I’m guessing they don’t want to show incoming users all the complaints and nasty workarounds.

  25. I’ve been using Appcelerator for 9 months now and although there are some problems, overall I think it’s a great system. The app I built using Appcelerator has 13 features, is currently at 57,981 lines of code, and any crashes that have been reported I’ve been able to figure out fixes for.

    The trick I found was to try re-using code/windows as much as possible, for example any webviews I show all use a special global webview function, so you can reuse the function without using up more memory.

    My biggest problem with app development is getting the app known, my app is limited to Canada as it provides information specially tailored for the Canadian market, so the market is small to begin with. Thus getting downloads/income has been slow.

    • The trick I found was to try re-using code/windows as much as possible, for example any webviews I show all use a special global webview function, so you can reuse the function without using up more memory.

      That’s a bad thing. While memory issues are one thing, the main reason I’ve moved away from Titanium, another big problem I’ve had relates to the fact that you basically cannot design your application in a reasonable, object-oriented way, unless you want to get into a lot of problems – memory starvation is just one of them.

      The number of lines of code, per se, doesn’t tell much about the complexity of your application, neither does the “number of features”, given that I don’t even know what you mean exactly with that. My application’s lines of code count is probably around a fifth of that value, still I’ve hit the ceiling pretty hard by now – I guess it depends a lot on your coding style. I’ve found out that the cleaner you try to be, the angrier at you Titanium gets – for example, it seems there’s no way to get rid of plain JS objects manually… we’ve tried everything and nothing works, so the solution is to not use them… which leads to a lot of clutter in the code due to the fact that encapsulating logic in a “model” or such becomes impossible.

      Again, if I were appcelerator I’d work towards making their abstraction a little more solid instead of trying to add new features at every release. I understand that marketing is probably putting some pressure on that but if they don’t fix their abstraction they *will* lose lots of customer… Objective-C’s not so hard after all – actually, it’s been very pleasant to work with it after my titanium adventure and I have no reason whatsoever to switch back.

      • At the moment there are some good MVC frameworks around solving a lot of memory issues. I believe that a lot of issues mentioned here have also to do with setting up a good project structure with a good OO-design. Following proven JavaScript OO patterns is also a good pratice. Extanium which is an implementation of ExtJS is the way to go. At the moment a guy is working on Extanium 2, supporting ExtJS 4, including support for MVC.

  26. Ar beginning you will save a lot of time but as more complex the project grows ull lose the saved time in fixing and workarounds for those buggy SKK builds. On every update i have closed my eyes in hope the app will run with it. Community is good but rates for advanced Titanium membership are an imposition.

    • We’re stuck at 1.6.2 because subsequent versions broke something about the event listeners mechanism – basically, some parameters are not present in the event object that the callback receives when hooking to an event.

      When 1.7.1 came out, we patched all the code so it would work anyway with the “new”, broken eventing system just to see if the memory issues were fixed… and we were quite pissed off to know that they weren’t fixed at all, even if they advertised that, after a couple of days of patching.

  27. Great blog post. I’ve just begun working on a simple application using Titanium. Similar to what’s mentioned above, as my application grew in complexity, I began running into some strange memory-related crashes. Instead of going into my issues with Titanium, I thought I might ask if the post writer, or anyone else involved in this thread, has chosen to seek out alternative cross-platform development solutions such as the latest PhoneGap 1.0 release, or perhaps another solution I’m unaware of.

    Currently, I’m contemplating two options: 1) switching to an alternative solution, or 2) following the recommended advice above pertaining to structuring the code using the same design pattern as Tweetanium.

    Your thoughts are much appreciated.

  28. I am happy for this blog post. Very happy.

    I have for a few months being learning native Android programming and although I have found it hard at times, it is going quite well now.

    Ever since I started, I have constantly being wondering whether I made the right choice by going native instead of going the Titanium way out of a cross platform perspective (and also because I am very experienced with JS and knew nothing of Java when I started).

    Now I don’t have to bend my mind anymore. I know I did the right thing going native.

    Thank you, Andrea.

    PS. I actually started out by trying Titanium. Even a very simple demo app I wrote failed in mysterious ways (some images missing for no reason) and I gave up finding out why. I thought it was me. Now I know it was Titanium :-)

  29. Pingback: Frustration: Appcelerator Titanium Studio | Andrew G. Wallace

  30. I hope that this blog-article – and simliar ones – bring enough pressure on Titanium to fix their bugs asap.
    (It is very interesting to see how often this blogpost appears in the Google SERPs if you google for ANY appcelerator issue).

    I really can’t understand how long many of the bugs are ignored.
    I understand that a complex software such as appcelerator will always have serious bugs. But when I compare it with early versions of Macromedia Flash or Director (which are Cross-Plattform-Tools too), then I see that these tools had a much higher quality. And that let’s me assume that there is a big lack of understanding the needs of their customers at Titanium.

    I would really like to pay for appcelerator if it just does what they promise it does!

    Arno

  31. arghh.. newbie to this…and now I don’t know where to focus my efforts… obj c, or a cross platform aside from titanium (this thread has all but scared the bejesus out of me from learning).

  32. I am almost full way to my project in Titanium mainly on iOs and Android versions later. The app is pretty heavy with 50 odd js files with complex webservice calls and local database updates. It used huge repository of images saved locally on the device. As most of them said, i too feel the heat of memory management and the app crashes pretty often. I dont use Xcode, but few memory test shows that the it takes close to 100MB memory on an iPod retina display device, i believe it is too high. The memory used up are not released immediately on window close. As the app is bigger, how we load a new window is by using the url method and keeping the old window open. On back button of new window the same is closed and the new window is shown automatically.

    Need a quick fix immediately to save my head.

    • Getting in use with Titanium I found too many issues that are hard to cope with. So far I didn’t even need to go memory issue as a simple application is causing problem: when your application is placed by the OS in the back (Home button on Android for instance), after a while if you try to reopen it, then the screen is white and you have no other choice than killing the application. Looking around I have found this is a common issue even on iOS and it does not seem anyboby has ccome with a working solution (all those I found so far are not working). Definitly difficult considering switching to Titanium when such things are happening.

    • Try using views instead of windows, memory problems disappear, look at the sample tweetanium app, i was EXTREMELY worried abt mem issues until i used the tweetanium structure and never again have my apps crashed…

  33. I’ve only just started with Titanium and found a lot of issues that stopped it working out of the box, that I had my concerns. Now I’ve spent a day writing an app at home and loaded it at work and it doesn’t work run on the simulator. “no supported deployment targets were detected”. After doing a search I came across this page and have now come to the conclusion Titanium is too buggy to work with, forget about memory issues, right now it’s more of the case that it’s taking more time to deal with Titanium working rather than actual coding issues!

  34. We were considering using Titanium for iOS and Android development. But I confess that after reading this post/comments it was clear that its not mature enough.

    Even in a simple application, we found problems whose solutions we didn’t like. I expected more of the platform.

    Thank you all for exposing the problems and difficulties of dealing with this environment.

  35. Pingback: Is Appcelerator there yet? | CodeDefied Is Appcelerator there yet? | Code musings 'n' stuff

  36. Wawo … excellent post. thanks

    As per Titanium team the leaks are from bad coding (see this http://vimeo.com/29804284), is that story of “Titanium power many best selling App true ?”.
    Question guys: what are the alternatives for Titanium ?
    I looked at corona, I didn’t find that much complains and it’s easy and good and you can simulate as you build with their integrated simulator but I think it’s good for games but not for Apps: Their libraries are limited…

    Any suggestions please?

  37. Hi, I´m actually making two apps on Titanium, One is for users use, showing google maps for traffic working fine. But I´m actually having a lot of memory problems on my second app to report traffic, having web services to return the points I´m passing through is a pain in the ass, the points are very large packages of data, and my app is crashing, I´ve managed to fixed those memory leaks but still having a lot of problems supposed to be fixed in 1.7.2. For small, simple apps is a good choice but If you´re looking forward to use it on robust apps choose Objective-C or other native language.
    I´m in constant communication with a friend the works on appcelerator and from what I´ve heard they are seriously taking care of all these troubles, hope that in some near future they fix everything.

    David

  38. Have to agree with the author.

    The problem with Appcelerator is the lack of care. They slap a load of features in and are quick to announce them. When it comes to using them, everything goes to pot.

    We’re stuck with 1.6.2 as 1.7 just constantly gave us huge issues in so many ways. Because of that we’ve got memory problems left right and center.

    The documentation is truly NONEXISTANT. In that some lazy git decided to run a ‘phpdoc’ style generator on the classes and provide that as documentation, with the sparse example here and there. Overall I’d say they couldn’t give a damn Docs wise – they have had plenty of time to get them sorted out.

    My advice: Avoid it like the plague….it’ll come back to haunt you.

  39. I’m looking for using Appcelerator to develop games. My first prototype started 5 hours ago and i got into the first issue. Animating a backgroud color of a view works fine in the iOS Simulator but not on the Android Emulator.
    After spending some time with google search, there are a lot of bugs using animation API for Android and i HATE it when thinks don’t work because of a buggy framework and knowing its my fault.
    I prefer spending time into native coding rather than waste time in google search or hack around and defraud my coding style.
    That’s not fun.

  40. Same issues here, tried Titanium, ITS A MESS! AVOID at all costs, native is the only option, or Monotouch / Mono for android.

  41. Been looking into titanium as a dev platform and not to keen on it after reading this code… I’m keen to go native… thanks for making up my mind guys…

  42. I’m from .net and retrained to objective c. It was well worth it to use a proper, well supported language. Been doing software dev professionally for 18 years. It’s just not worth the quick and cheap solutions unless (and think about this) you want a quick and cheap product. Then it’s great, but that means probably no sustainable revenue. Get a proper product, a proper business model, get proper funding (10k, 20k, depending) and get some proper, trained developers to build it on all 3-4 platforms. Or just mess about with toys, in which case, stick to the platform you prefer, as it won’t matter whether it’s cross platform or not.

    • c-d-g-42, I am in slight disagreement here …

      If one spends the right amount of time studying the titanium required architecture ie. factory pattern javascript. Also one ensures to double check availability of all required features by the application on Titanium before beginning the project. Then titanium can prove to be mighty useful.

      In just the last 6 months, my team has built over 5 apps (mid size) involving animated ui, network web service calls, audio recorders, camera, gps, video embeds, forms, etc… all are stable and rock solid with no memory issues (based on DDMS and Xcode analyzer)

      So yes theoretically best to use recommended languages but people do study those before beginning. Similarly, if one spends even half the time studying titanium, can result in great output on android, ios!!

      • Dear Rahul,

        I agree with you as far as I would also recommend to getting used to a new tool before writing something bad about it.
        And I believe you, when you say that you were able to build stable applications with appcelerator. I am still working on my first app and it is getting better.
        BUT: The point for most people here is, that appcelerator is promising something that is not fulfilled.
        The memory-issues are a good example. The tool promises that you do not have to care about it (in opposite to objective-C where have to write a lot of code to manage the memory). But when you work with a lot of graphics and sounds in appcelerator this promise is not held because you app will crash due to memory issues. That means that you have to start thinking about a memory efficient javascript pattern and that you have to arrange your views etc. in a memory friendly way. At the end it means that you have to do some kind of “memory management” again – just on an other level. And that is even worse because you do not have very much control in appcelerator about the memory and you have no clear and good official documentation about these issues.
        After all I have won a lot of time with appcelerator because the start is quite simple and nice. But at the end I lost a lot of time with appcelerator because I had to learn things that I didn’t want to care about when using this tool. And they promised me that I do not have to care. But I have to.
        That’s the point in my oppinion.

        Best regeard
        Arno

        • The problems we’ve had with development have nothing to do with the fact we don’t know javascript well enough – because we *do* know javascript well enough. Actually, it’s when you try to do something “strange” with javascript (prototyping, or even simply attaching properties and methods to existing instances) that titanium shows its worst. And, when we’re talking about deploying to both iOS and Android, it’s literally not even worth the time to try and deploy to Android an app thought for iOS – it’s much faster to rewrite from scratch, in Java.

          Appcelerator is promising something that it doesn’t fulfill… but we would be totally okay with that. As long as they at least provide some way to work around their issues. Do I have to take care of memory? Fine, at least provide me a way to do that. Since I have no chance to release and retain there’s no way I can work around their memory issues.

          They’ve decided to provide a completely opaque astraction – that means, it *has* to work 100% of the times. I would have been okay with a non completely opaque abstraction that I could actually interact with, even if that meant I would have had to take care of the memory by myself.

          I’ve restrained myself from writing this article until 1.7.0 came out, since that promised to solve a lot of memory issues we’ve experienced. It didn’t. At that point, I decided I had evaluated Titanium for long enough to write a recension about it. I’ve been working with Titanium for almost a year now.

          • andreadallera: In my experience with appcelerator, if you use views instead of heavy weight windows and remove, null them post use, I rarely see memory issues and Ive written apps with more than 10 – 12 dfferent tabs, functionalities … just fyi you may want to try it??

            • Getting rid of view-related memory (or, in general, objects created by titanium directly) is not a problem in most of the situations. What troubles us the most is how to get rid of custom objects, generated via new() in javascript. It seems there is no way to get rid of those objects – we’ve opened a post on titanium’s forums and it wasn’t helpful, as well we tried to contact Appcelerator directly – no results.

              FYI, windows are UIViews behind the curtains – so, theoretically, it should be no problem to create windows from an Objective-C standpoint.

              • Shouldnt nullifying the objects created with new() destroy them whether titanium or native? Have you confirmed this issue by using any profiler and confirming if this objects are released or not. Just a note the GC doesnt show removal of objects immediately but over a slight delay (native to iOS and Android) just in case you are depending on the total memory consumption as an indicator.

                I will also double check this point….

                Agreed on Windows being UIViews but mem allocation is higher on heavy weight windows (ie. windows with their own js file) compared to views which are lighter and can server an almost identical purpose. So I really seperate windows only when absolutely neccesary..

            • Hi Rahul. I am new with Titanium and really scared by what I read. Could you please post the name of your apps done with Titanium? Thanks

              • Hi Romain,

                Sorry, my company only does enterprise distribution apps over adhoc method atm since our clients are primarily B2B and not B2C so no apps on the stores….

                I understand your worry on beginning to use Titanium post using this thread. My primary point on titanium:

                1. Make sure all Titanium APIS are available for your app requirements by validating you requirements against the Titanium documentation. It is easy to get upset with Titanium mid way in the app to realize there are some missing features. Ex. No direct api for SMS on iPhone and Android. This does however get solved by using modules (written in native code by community / yourself). Read up on modules too….

                2. Do note that there is a steep learning curve to get a titanium app structure right. Your fist app with hello world, some ui, some cool camera or similary complex features is easy to build in a few hours. But building a store ready app requires mastering a project structure, memory management, etc and can have an equally steep learning curve on Titanium. This can be voided by studying the Tweetanium app structure (do not use kitchen sink structure coding al though snippets need to be picked from there).

                At the end of the day, Titanium can take equally long to learn and master similar to native code but the long term benefits have worked for me.

                1. My team has successfully create ports on iphone and android simultaneously and works very well!!
                2. Once the difficulties are overcome, my team now creates apps in days compared to weeks.
                3. Easy to train new staff now that prcess and structures is documented
                4. For us 85% app requirements are handled in titanium, 15% by doing native code and combining it using modules in titanium

                We have built projects such as:
                1. Real estate applications with image gallery, videos, maps, integration with an ERP on ipad and android tablets, works very well .. no issues
                2. Hotel menus agn on iPad and android, works very well….
                3. Sound recorder app with file management – 10 screens+ – works well on iphone Android does not have pause on sound recorder so building a module for it this week. (This is an example of not studying the titanium api before comitting to the project) but the module method is easy to work with and o wont blame titanium here…..
                4. GPS based restaurant search app …..

                All work well, no issues…!!!

                • I don’t agree with you all the points. It’s not possible to know what API’s are available and what are not just by looking at the document. First of all they don’t have a proper document for the API. ON top of that, there the issue of API’s working correctly. We tried to write an cross platform app for iPhone and Android. 85% it worked on iPhone and there were some things which didn’t work on iOS. Out of that 85% of the app, only 20% worked on Android. We have been doing native app development since Android version 1.1 and for iPhone since 3.0. What is not available in the framework can be accomplished by writing a module, is a weak argument. Which means that I still need to know Java and Objective-C. I’m not confined to just JavaScript then. Having a single framework will not work for both the platforms because each platform works differently. We did cross platform libraries for unix, Windows and Mac and we were able to accomplish the feat of having a single API for making some Calls cross platform, but we were still writing some part of the app in native language.

                  One thing to note is that in Android, the more indirection you have in your classes, the performance is going to suffer. Look at the code that gets generated for Android,compare the performance with the native code. I will bet you will see very different results…

      • Totally agree with you.
        JavaScript used in a bad script kiddie way, ignoring proven JavaScript OO patterns, not investing to study the Titanium architecture and just believe everything is done automatically for you… is bringing you into problems. Nothing new in developers world ;-) Microsoft access could also be used by everybody knowing how to build a app using Macro’s… hehe

  43. Scary stuff for someone just giving his first steps with Titanium… My question is, has anyone here *following the pattern of Tweetanium* had any memory issues or unexpected behavior?

    • I have used Titanium for several apps using similar patterns to the Tweetanium (and others not doing so) and I haven’t had any problems so far. I started off by using the code examples in Kitchen Sink to develop a core of functionality from and the code logic used in the examples has not let me down so far.

      The main complaint of memory issues I suspect is down to not closing processes down properly (such as old windows or views) but as I have always used the same methods I haven’t encountered these issues. The only time I have encountered any issues on Titanium is either when the Android emulator has crashed (fixed by restarting it) or when something happens when trying to install the app in the emulator (fixed by restarting Titanium).

      I am happy to carry on using it for developing apps across both platforms as it is a real selling point to clients that they don’t have to pay twice for the app. If I did encounter any real issues with it like described on this page then I would bite the bullet and learn Objective C.

  44. It was great for me to read through all of these comments and digest this information. I just downloaded Titanium on my Macbook and feel I’ve made the right decision to delete it before installation.

    Learning Xcode and objective-C, from a web developer experienced in Java, JavaScript, Flex and other web tools, is an INCREDIBLE pain in the arse. I can’t relate to Xcode in any way, shape or form. Comparing it to Eclipse is like comparing apples to chicken fried steak. Initially, I thought perhaps I could relate it to the Flexbuilder IDE(I’m forever looking for relations to make learning easier for me). But after deleting one or two projects accidentally and spending several hours just to get a particular view to appear more than once, I had the sneaking suspicion I was in over my head.

    Reluctantly, I’m going back to busting my head open with Xcode.
    To get through this, my mantra is, nothing in life that is worthwhile, is easy.
    Rome wasn’t built in a day and neither was my career.

    Any one who is familiar with the fact that mobile and iPhone programmers are getting paid two to three times more than other programmers can probably guess the reason why. Because it is difficult and few people can do it and even less can do it well.
    That won’t always be the case, but I see it being that way for at least the next few years.

    Titanium will be a useful and good tool someday, but for now, it seems like a shortcut that has little guarantee it will get you where you want to go. For those who don’t mind traveling with no real destination, in the hopes they’ll find what there looking for, it sounds like a good solution.

    • Don’t worry. You will get used to it. I had the same experience. For me, compared to Eclipse or IntelliJ, XCode is absolute crap. Unfortunately, it seems to be the best IDE for Objective-C.

      However, as everything else, the longer you work with it the better you get at it and it will become second nature for you. Once you find your way around it, then you can start to be more productive by knowing its features, shortcuts etc.

      Today I can say I’m no expert in XCode, but I don’t hate it anymore.

    • Pluralsight has some very nice iOS video tutorials. Specifically because they’re a .NET shop and they focused primarily on comparing Obj-C to C# (@synthesize is like get; set; etc). Since Java isn’t too far from C#, maybe they’ll help you. John Somnez was the instructor’s name I think.

  45. nice post, I would also recommend Titanium to make the avaible features more stable instead of adding new features on each release. However I still believe in Titanium and hope they will get a geat product soon. I never had memory issues but also used single-context from the beginning. The Android support isn’t that fun… actually its just a toy. For now you can only use it like a wrapper for xcode/obj-c to avoid learning/writing obj-c.

    • Agreed, or they get a bigger team now that they are funded on several rounds and add popular demanded features and a seperate team works on making things stable….

      The CI releases are good to work with too…..

  46. Ram, my thougts on your comments:

    1. I use the api documentation as well before submitting a proposal to a client. I also do a Proof of concept code on all the tougher part of the requirements. A POC sometimes takes me as little as 0.5 – 3 days on Titanium and therefore I already know the apis to use, work arounds if needed from the forums before I get into the project and commit to the client.

    2. Ive done some cross platform work now, my experience has been that 85% matches with 15% requiring re-writes

    3. You are right about my point on modules. One does need java / objective C knowledge. But look how well that works for companies like mine with several team members. I only need 1 native code developer for every 2 – 3 javascript developers in a team ie. the larger part of an app is written by a js developer and if needed the native coder writes a module to assist. The speed achieved works well for my client and my company.

    4. Agreed with android performance, 1.8 build is to bring about a core change on the android engine. The announcements are out, you should try a CI build…

    Again, I am not here to propagate Titanium, but it is unfair to have a blog with a 1 sided story and hate on Appcelerator where as my experience has helped me do several thousand dollar projects with it so easily…

  47. We have a mobile web app since 3 years and we want to make a native app for IPad and new Android Tablet, we spent 2 weeks working with Titanium.

    Our apps has just a login Form and a list of Invoices, on emulator everything run well and on IPad 1 sometimes it crash but on IPad 2, it crash 1/3.

    On Android it’s ok but it’s slow on Gallaxy Tab 10.1

    Results : we have lost 2 weeks for nothing , we will go to native APP !

  48. Hi!

    I agree with the topic of this thread and wanted to share some thoughts. I am new to mobile app development and Appcelerator sounded really to good to be true – cross-platform mobile + desktop, Gartner magic quadrant – wow! But Gartner are not programmers like us, they don’t look under the hood, they just see the surface – and that’s IMHO just good marketing. The Appcelerator advertisement video lists a lot of top apps developed with Titanium but they are not cross-platform – they are iOS only. The forums reveal that Android support is not as good as iOS support. How many serious Android apps are there actually using Titanium?

    Titanium Studio: Unfortunately the problems started right after the installation. I installed everything to the default directories but I could not even start the “Hello World” app without digging deep into the Q&A forums (full of unanswered questions): I had to modify a python script to get things to run on Win XP because the command line arguments were passed without quotes – IMHO that’s pre-beta stuff. Another problem is that the Android simulator decides each time if it will start or not – I constantly have to delete simulator profiles. I don’t know if this has something to do with Titanium or not but it makes developers crazy.

    Appcelerator Mobile: The API docs are really bad and there are no simple examples demonstrating the API in use to get started. You don’t know what’s going on under the hood. Does this API call run correctly? What parameters does it actually expect? What does it return, in what range? Does it work with iOS or Android? Is my SDK version supported? Has the bug mentioned in the forums been solved in the latest version? How exactly does JavaScript influence performance? I suddenly found out that there is a “hidden” option to turn on Java bytecode compilation which is only used for deployment. Does that mean that my apps are not run in full speed without that option enabled? How do the Titanium API calls actually compare to native code? There is no info on such things and you would have to rewrite you app in native code some of the things, which makes the whole concept useless.

    Appcelerator Desktop: Today I tried it just to find out that the docs and examples are even worse that with Mobile (actually non-existing). Additionally it uses some techniques that make my Norton Internet Security detect any built .exe as malware. This means that even my Hello World application gets auto-deleted on run. Well, that’s nothing I would give to my customers.

    All in all I am very disappointed and don’t see a good reason to invest time in learning Titanium. The concept is brilliant, but unfortunately the real experience is pre-beta. Now I have to decide between learning iOS or Android native programming :(

    Regards,
    Anguel

  49. Hi all,

    I have now developed several apps (but not published them on App Store or Android Market) using Appcelerator and not once have I encountered any issues with them on either the iOS or Android platforms. I have used both the window and view methods for different screens and both seem to perform well in terms of memory and some of them are quite large, although only a few calls to other JS files are used (and some are similar to the Tweetcelerator example).

    One of them was a relatively complex, large instructional video playing app (over 15Mb) which did use over 32 seperate screens, however, even this performed well on the iOS and Android platforms. As people have mentioned, I think most problems come from not closing windows/views and other processes, which would explain why the memory gets eaten up.

    Maybe I have just been lucky but after reading this thread I am concerned as to how far I could push Appcelerator before it breaks, but until it does I will carry on using it.

  50. Wow, I am glad I came across this blog post and all of these comments. Thank-you to the author and all the people who commented. I wrote a native (Java) app in Android, but I wanted to go cross-platform with future apps. I thought I would try out Titanium since AppceIerator/IDC’s developer survey is quoted often, and the Titanium SDK seems to be used by many major companies. Unfortunately, I have struggled with just getting Titanium Studio to just launch Android apps, and even once I get to development, the documentation is rather spotty. Before pressing on, I think I’ll look into other options now. Titanium seems to be a great concept, but the comments above are rather convincing of its critical flaws.

  51. I think the readers of this blog might well want to take a look at Application Craft. This is fully cloud based, has a proper UI builder, javascript and phonegap integrated, so builds Web Apps and Native (hybrid Apps). It also works very well for desktop apps. The UI builder has Responsive Design features so you can build a single App that works on dektop, tablet and mobile.

    Here is the case study Phonegap did on them : http://phonegap.com/case_study/phonegap-application-craft-pain-free-mobile-app-development/

    • The “Native” Apps of PhoneGap has to be taken with a grain of salt. Even though it adjusts the look and feel to each device it’s essentially javascript running on a webview. It doesn’t use the native controls of each OS as Titanium does, so it’s not quite the same.

      • Dario – this is very true. However, for the majority of business type Apps (as opposed to glossy apps) you can still get a great UI look and feel with web controls using jquerymobile widgets or other js widgets.

        There a millions of developers out there who want to build great apps that look great, even if they are not necessarily 101% native in appearance. But crucially they want to be able to build them incredibly quickly and treat them almost like ‘disposable’ apps.

        Do you remember Visual Basic (70% of all business apps were written in VB at one point)? That showed really that a huge number of people wanted to just get apps built and were not concerned about pixel perfection. This need is even more acute today than it was back then.

        The platform I mentioned (Application Craft) is essentially VB for today.

  52. These guys made the impossible possible for a lot of web developers. I am sure they will improve the platform and will rull the apps market. I agree that titanium is far away from being perfect, but it’s a huge step forward for making native apps development easy, intoative and fast.

  53. So glad i stumbled across this post. At first I thought it was just me.

    I wanted to fly down for some hands on training – perhaps I was doing something wrong, a slow learner, need hand holding etc – but after emailing a sales person (who reached out to me in the first place) and calling in (who promised a sales person would call me right back), no response.

    Given up but I’m pretty deep into a project. Stuck.

    Started to work with Objective-C and it’s not as bad as I initially thought. A complete rewrite may be worth it.

    m2c.

  54. Hi All,

    I am relatively new to Titanium. Recently I have written native Iphone and Android apps. I find it hard to believe that Titanium can covert a single application into Iphone and Android native app. I think that the design philosophies of Android and Iphone are really different. In Android we mention attributes like wrap_content, fill_parent and relative layouts to maintain scalability etc, but there is no such requirement on Iphone.

    How can Titanium handle this ?? Can someone please explain ?

    • Rahul,

      Would recommend writing the code in multiple layers and then changing the UI layer on iphone and Android individually….

      Simple UIs can be done as a single app though..

  55. Have you ever tried to base64 encode an image captured through Titanium, to send to a web service (through an API, WITHOUT the ability to change the service implementation on the server) ? Ridiculous! Every day I come up with a new reason to not use Titanium. And using the Studio editor is like trying to use Eclipse with your hands tied behind your back.

  56. Erica,

    Where are you stuck? I am not sure why you would be stuck if you read the image as a byte array and then run the base 64 encode function?

    - Rahul

  57. I’ve just downloaded Titanium to give it a try! At first I doubt a little about this article but seeing 98% of the comments hate Titanium, it’s a fact it’s not as robust as they say!
    You people have completely DESTROYED Titanium =/
    I see all your complains are about the mobile apps (iPads, Android, etc)
    I’m mainly a webdeveloper! I’ve used Aptana Studio in the past, version 3, to develop mainly in PHP, HTML5, CSS3, etc.

    I downloaded Titanium because I read Aptana was bought by Appcelerator and Titanium it’s an “enhancement” of Aptana…
    SO…
    Do you people think Titanium it’s as bad as you say for web development???
    I’m relatively new to Aptana too and I find it interesting I believe, so please tell me what you think.

    Greetings from Mexico ;)

  58. For those of you having difficulties finding the pro Titanium comments on this thread I recommend reading the replies from: Leo, Brad, Darren, Rahul, David Zorrilla, Nick, primus202,dan, Richard Daniel Lustemberg. A lot of valuable information there.

    I’m using the Tweetanium structure myself and haven’t encountered any issues on a simple app I’m developing for iOS and Android. Documentation is definitely lacking but so far I believe Titanium is quite suitable for small and simple apps.

  59. Titanium has a specific purpose that is to build simple to advanced apps and not more. You should exactly following the red thread if you want a halfway stable App.

    Let’s me be honest i am use titanium only because its can be run on ios and android as well.
    Thats reason nothing else. If you are a professionall objective c developer you are a little bit slower than a titanium developer, because you must handle youre memory by yourself -> but that is a advantage, in my opinion!

    I am developing in objective c apps (since 3 year) and titanium apps (since 1,5 year).
    Both has advantages and disadvantages, the fact is xcode grows and is intellegent from release to release while titanium try integrate more features and solve bugs.

    Titanium can be a good alternative but in some years, not now.

    Ps.: who dont believe that the gc it terrible in titanium, just check you memory profiler to see the fireworks … ;)

  60. I’m new to mobile development and I’ve spent a fair amount of time writing an app with multiple contexts (heavy weight windows) using Titanium and now that it’s almost done I’m running into the typical stability issues that people have mentioned. I’ve taken a look at the Tweetanium example and am trying to decide if I should adapt my app to this model or try to resolve the problems I have using tabs/windows.

    The nice thing about multiple contexts is that I ideally would like to be able to keep nesting into several windows (obviously it can’t go on forever) but it’s nice from a user navigation perspective. It’s not clear to me how I would achieve something similar in a single context architecture.

    Any thoughts on whether I should try to move forward with a single context model and how I should adapt the fact that I am relying on many sub-windows would be very much appreciated.

    Thanks,
    -Derek

  61. Pingback: Linkflood 20111215 – Mobile keylogger, cabinati con giochi indie e Kindle touch jailbreak | Rainbowbreeze

  62. Hello there:

    I just read the whole comments since im interested in developing at Titanium. Came here looking for docs, just wanted to know how to deploy the very first “hello world”. Now im very brainstormed, really dont know what to do. Someone said Titanium hides some apis, or that you have to have some premium member$hip to improve better. How open is Tit? Do you have to pay at some point? and for what?. I would like if you enumerate the pros and cons in a short way so noobs can decide better.

    Thanks.

    • I dont think they hide any APIs or atleast I have not required any API which I have found unavailable over the last 5 – 7 apps I have been building. You can get all the info of api availability here: http://developer.appcelerator.com/apidoc/mobile/latest

      But to see sample code, you must download the latest version of kitchensink here: https://github.com/appcelerator/KitchenSink

      You can start with a free subscription, over time though, I have chosen to move to a paid subscription (Indie plan) since I can read the help desk which is similar to a QnA but only that appcelerator has to close all open issues in that forum so the solutions are more solid than the QnA.

      Ive built a very complex app recently and its our first B2C app, once on the store, will leave a link here…

    • You never have to pay for Titanium. The SDKs are FOSS, and Titanium Studio is free. You can create, develop, test, debug, and distribute at no cost.

      The only time you pay is when you need pro services (see subscriptions) or you want to use premium native modules that are not included in the core API. Thst said, Appcelerator has made a number of those FOSS as well.

  63. I’ve been an off and on Appcelerator user over the last year, but really dug in about 2 months ago. While there is much in these comments that I understand or recognize, I’d have to say that I’m actually quite happy with how development has gone.

    For anyone recently getting involved, pay close attention to the Forging Titanium Vimeo channel, http://vimeo.com/appcelerator and the Best Practices guide, https://wiki.appcelerator.org/display/guides/Mobile+Best+Practices and recent and upcoming application demonstrations that illustrate theme in use. Kitchen Sink is useful, but should also be reviewed against newer techniques that have evolved.

    Finally, with the recent capital infusion and the independent module market, I’m pretty jazzed about what’s going on there. I’m now working on my 4th Ti app and having started down the Obj C path before (after 20 years of programming experience), I’m quite happy to NOT be writing Obj C code.

  64. Thank you all for a very critical analysis. I wanted to start with titanium but – I am thinking again.
    Any suggestions for alternatives to titanium like Adobe AIR / phoneGAP?
    I read some reviews I am more confused.
    Thanks in advance

    • My company has chosen the following:

      - Appcelerator for native iPhone and android apps (since they are truly native, code is translated to xcode and java)
      - Phonegap for native blackberry and symbian (uses web embedding) but the only good option for bb and symbian and we are treating these phones as second tier due to their interfaces
      - We may choose phonegap for Windows phone as well!!

      • Thank you. This certainly helps !
        Looks like you are using both Appcelerator & phoneGAP this is really nice.
        Can you please enumerate some benefits ( ..or point me to an article.. ) that motivated your choice of platform for each device – as a developer. I come-across some comparisons which are more like feature list – but any further insight is much appreciated.

    • Thomas – Application Craft is adding in Offline Support for data storage in the New Year. This will allow you to collect data offline and then sync it when it sees the central server.

      Freddy May (from Application Craft)

  65. Pingback: Mobility is a Mess | The Red Circuit

  66. Anyone who works in the technology field knows it evolves quickly.

    Making business decisions on six month old blog posts with minimal supporting facts and lack of updates is unwise. Everyone has there own personal experiences with technology and there are an assortment of issues that can lead to success or failure.

    IMHO don’t be fooled by noise, do your own due diligence and make a business decision not a technical decision, on what is right for you. As I have said many times before, there are enterprise clients that have chosen Appcelerator and been extremely successful; I think that is sufficient evidence for me.

    http://vimeo.com/29994896

    http://www.slideshare.net/aaronksaunders/why-appcelerator

  67. @Andrea If you believe (which is quite reasonable, btw) that the differences between IOS and Android cannot and should not be bridged and furthermore you have no issues with working with Obj-C and iOS, that begs the question of why you even thought of using Titanium, doesn’t it? Just confused…

    • When we started, we didn’t really plan about porting our application to Android – it was going to be iOS only. At first, honestly, Obj-C looked intimidating: I never had to work with a non-garbage collected language in a production environment. I tried to build an app with native and I found it challenging (also, because the time that I was given to build such app was absolutely insufficient – even now, I would have some problems with building that same app in the 3 days I was given).

      So I found out about Titanium and found it much easier to work with, and started using it. Only later I found out that its abstraction is heavily leaking and Objective-C is not bad at all to work with.

  68. Nice post, interesting to see that you gave up on Titanium, me too. A client decided that they wanted to use it around Summer 2011 for an enterprise app for their staff which have iOS and BlackBerry devices. Titanium for BlackBerry was in Beta (only accessible to users on a paid subscription) and due for official release ‘in fall 2011′. That our client would get an Android app too promised to be a bonus since some staff use their own devices. Titanium looked like a winner.

    We set about developing for iOS and Android and aside from the simplest of UI’s were surprised with the amount of if / else forking required to get acceptable UIs. I personally wasn’t involved in the Titanium BlackBerry side but we did pay for a Titanium subscription to access the beta and BlackBerry support turned out to be very poor according to my colleague. The fact that BlackBerry support is still in Beta (has it just been swept under the carpet?) speaks volumes to me. Being a Java developer I wrote a native BlackBerry prototype in 2 days having not previously written a BlackBerry app.

    With poor support, unanswered questions and silence in terms of BlackBerry support we concluded that despite all the glitz, glamour and hype, Titanium and Appcellerator over promises and sells a dream that isn’t as it seems, perhaps in the hope that users will play along with the workarounds and continue with it rather than throwing time and money invested away, kind of like a gambler chasing their losses.

    Given that it only offers two platforms (Android, iOS) I personally do not think it is worth the effort in learning the API’s, nuances and workarounds and instead focus on learning the native API’s and language for each platform of interest which tend to be very well documented with extensive examples abound on the web. Developers who are experts in each platform can focus on the app for that platform to provide a better user experience and can produce bug fix and product enhancement releases more quickly without worrying about breaking the app on the ‘other platform’. What may be theoretically lost in development time is not as much as you may think in terms of the overall design / code / test / release cycle since with Titanium you still need to have a degree of separate UI code forking for each platform and any change has to be tested so extensively across all devices.

    Whilst it may seem harder at first, learning native will pay dividends in the future.. better apps, more job availability, better coding.

    Codestrong, go native.

  69. @Fleep
    completely agree with you! See Automatic Reference Counting (ARC), it was never easier to develop a app in obj-c/cocoa + Xcode!

    If you want to learn how to develop iOS Apps go to at Stanford University Lectures from Paul Hegarty (CP193), also available on iTunes! He teach better then some Books or V2B Videos!

    • Indeed, those lectures are pretty sweet. Even the ‘first app’ demo showed some neat xcode features I didn’t know and his presentation style is easy too.

  70. read all the above with great interest… thanks everybody.

    I’m a windows developer (with a vertical app) venturing into the post-pc world and at first glance titanium seemed like the solution i’m looking for (then i saw the title of this blog in google).

    from what i read here it seems if i keep to single context i should be ok so my thinking at the moment is…..

    i have 2 possible ways to go

    1. titanium (as the best of the HTML5/Javascript options)
    2. obj C

    best case scenario with titanium is i get an adequate working ‘native’ program for iOS, Android, OSX and even Linux from one code base in less time than it would take for just the obj C version. And i get to brush up my javascript skills. I can possibly reuse some of the html5/javascript code with the new WinRT for metro look and feel in windows8 (and possibly WinPho). Worst case scenario is i spend a month or so creating an unusable pile of cr@p and i get to brush up my javascript skills.

    best case scenario with objC is i get a working iOS native app and get to add objC to my skillset. Worst case scenario is the objC learning curve is too steep (given other projects and deadlines) and after 3 months i don;t have a finished product but i do get to add objC to my CV (if no one looks too closely).

    so on balance i still think titanium is the way to go.

    (although those stanford lectures do look good. )

    • IMO Titanium is a good cross-platform environment if you choose the right JavaScript design patterns and be consequent. Titanium supports RequireJS (or Underscore, Mootools, jQuery) so you could choose the module design pattern. Or use a MVC implementation like Appcelerator MVC or make your own implementation of a proven JavaScript framework (eg ExtJS 4) and strip out the DOM implemetation. The use of javaScript and HTML5 in an Titanium app is another world comparing to the use of javaScript and HTML5 in web development which is mainly focused on the manipulation of the DOM. So you have to think ‘different’ ;-) If you know Java, things become more easier because you can read the Titanium architecture. Further, the release of the 1.8 MDK is a big step forward.
      Maybe another discussion, but if you really want to go for a rapid cross platform development tool, take a look too at: LiveCode 5 (http://www.runrev.com). A total different way in writing programs for Windows, Mac OS X, Unix, Android and iOS.
      Just my 2 cents, Cheers Erik

  71. Pingback: phone web based application framework links « wildstuff

    • Agreed, there are work arounds to issues sometimes. Also it is important to build with the right version of tianium to get things right.

      But learning a new language for each mobile system – not a smart way forward either.

      Btw if you do build good JS Code, most issues disappear.

      Titanium is also evolving with each updated release. For. ex IOS just got pinch and expand gestures, multi touch modules so quite near to catching up with official IOS SDK.

      Android just got a new engine, speed up is visible!!

      I have an app launching soon, will share links to prove others wrong here!!

      • > Btw if you do build good JS Code, most issues disappear.

        That is just plain false. It’s more like “if you build things the Titanium way most issues disappear”. Problem is, the Titanium way is not exactly the best way to structure your code (take a look at Tweetanium).

        If you start to access .prototype heavily and istancing objects not correlated with Titanium good luck with managing their memory.

    • I am developing with the Common JS framework suggested in the Forging Titanium videos.

      I don’t have any problems whatsoever with crashes and memory leaks. The apps that I am doing are very very extensive and complicated.

      When I first stared and was using a multi context framework, it was very troublesome.

      • Hello Leo,

        we are interested in using titanium ..but reading all this reduces confidence on it …can you tell us name of some of your built apps on android and ios so that we can test it and get some idea and confidence …

        waiting for reply…

  72. I have read all of the comments here and have not had any of the problems people are talking about here, with a good file structure and clean code I have had no major problems that were easy to fix(Mostly having to call for individual platforms for a consistent UI). Use OO fundamentals with some custom libs and has made fast easy development. Much faster than coding and maintaining two code bases for each mobile platform let alone the testing. I have a very heavily data driven interface to a server side that has had over 1.5 years of development and testing. So far 5000+ daily users and two months in with 2000+ (a mixture of iOS & Android) mobile clients accessing the main server and thats almost 50,000 XHR calls a day just from the mobile clients. You just can’t over promise what a platform will not do. If you don’t like the tools don’t use them and quit bitching like a baby. If you thought objective c was intimidating maybe you are in the WRONG industry as a programer. GO BE A SCRIPT KIDDIE. If you use Titanium yep you might have to dive into some objective c or java to fix small things but overall its the best for the price FREE! I have found no need to get any of the subscriptions. Titanium 1.8 has also finally reached a good point in stability and a stable code base. I love what it has done for me, saved me weeks of time producing a cross platform app that has been easy to add functionally to a app. oh and far as supporting BB its a fast dying platform that my current customers have been moving to iOS or android.

    • Well put Mike!!

      Just a FYI for you, the paid subscription and therefore access to the Helpdesk is a nice addition in my opinion. I used it for quicker answers since most questions are answered in there as compared to several answered on the more public QnA.

      Look forward to connecting on the forums!!

      - Rahul

    • >If you don’t like the tools don’t use them and quit bitching like a baby.

      I did. I just wanted to warn others of the dangers so they don’t have to waste any of their time.

      > If you thought objective c was intimidating maybe you are in the WRONG industry as a programer. GO BE A SCRIPT KIDDIE.

      I’ve never met a good programmer with this attitude in my life. Do you have a github account? Let’s see if your code backs up your words.

  73. Oh i to tell people that don’t like the IDE either, you are just plain stupid because it is all based on Eclipse THE BEST open source IDE there is. Aptana is just a plug-in as is the Titanium portions. I have installed them into my Zend Studio(Based on eclipse), it still works with ALL of the emulators. You can even do download the NATIVE Android dev environment. Besides Xcode and Visual Studio in my minds eye Eclipse rounds out the top three development Environments out there. There are still the hard core coders out there that love VIM. Even if you talk to them they will tell you that the three that I just listed are the BEST three out there. So once again if you want to be a baby and ruin GREAT communities keep whining like a baby. And sub out the INTIMIDATING parts to REAL programmers. All I can think of when I read blogs like this is WOW why would I hire someone with such a shitty attitude. Blogs for programming should be about sharing workarounds and sharing KNOWLEDGE. Programming is not perfect if one solution does not work there are many ways on making it work. I can tell you from working on other people code is that you have to make workarounds because of the lots of crappy coders out there. So when you said you really have to know the code to find out what wrong welcome to the REAL world. That is why GOOD programmers have lots of comments in the code telling you how it works. If not well it just makes it a little more fun. If you had maybe done some prototyping before hand you would then give the right price and timelines to your customers and not been caught in a JAM. Don’t blame other for your incompetence. I have told lots of my friends about this blog now and they are laughing at you for your plain ignorance. If you want a drag and drop interface builder it costs lots of money as well as good programmers. You sound like I did Javascript for the web for years and made it work. YES, you made it work but it people like you that make the rest of us look like shit. HTML5 and other tech is coming of age that will help people like you build very slow interfaces that are processor heavy. I started in 1988 programming and i feel that the first 10 years was all learning because it was. Now I teach lots of people how to program the right way which just is not taught at schools IT IS learning from YEARS of experience. I am getting of my soap box now, but the next time learn that workarounds are the life of a programmer. IF YOU don’t like it find a NEW career or just stick to what you are good at being a SCRIPT KIDDE.

    • Agreed, The titanium studio based on Aptana is quite nice. It even lets one build and submit apps into the store in case of apple.

      Also, not sure who thinks there arent work arounds in core java / cocoa (I use them for modules partially).

      Just like your own code gets stable over multiple builds so is Appcelerators code getting stable by each release. Some times when we make changes, older code breaks (regression issues), similar for appcelerator.

      At the end of the day, I have been able to create some complex apps using a mix of tianium, core modules, web services and web backends. It all works if you understnd it well.

      Creative people need to deal with ideas and not complex code, appcelerator helps encapsulate complex code … so that works gr8. I built a QR code reading application in a few hours and made lots of entertaining ideas around it in a week. In core Java or Cocoa, I wouldve struggled weeks on getting QR code reading right…..

      Agreed, work arounds can get a bit annoying sometimes but do remember, finding and applying these work arounds is still easier than learning multiple languages. Also we document workarounds for our developers who refer to the same while building new apps, so same issue is not hit again.

      If a major issue was reached, several people would be stuck on it, appcelerator would fix it immediately seeing the entire community stuck. Its individual issues people get stuck on and there is always the option of writing a module in that case.

      Anyways its a matter of choice…..!!

    • > All I can think of when I read blogs like this is WOW why would I hire someone with such a shitty attitude.

      Too bad.

      > So when you said you really have to know the code to find out what wrong welcome to the REAL world. That is why GOOD programmers have lots of comments in the code telling you how it works.

      https://github.com/appcelerator/titanium_mobile/blob/master/iphone/Classes/TiMapView.m

      > I have told lots of my friends about this blog now and they are laughing at you for your plain ignorance.

      Let’s see your friends’ github account as well then. I’m really curious now.

      > IF YOU don’t like it find a NEW career or just stick to what you are good at being a SCRIPT KIDDE.

      Here’s my github account: http://github.com/bolthar . Where’s yours?

      • 98% at least of the code I have worked on in my life is closed source proprietary code, I have signed NDA’s. That code makes appcelerator’s code look like a DREAM. I been hired too many times to clean up shitty shitty code. When I go back in to fix the code I comment the hell out of it, because I had just spent a week trying to figure it out. Because the next time they hire me it takes no time at all to find where I need to drop everything into. Github is wonderful for open source, but when is comes to closed code, I have no github, I do have a private SVN and a Git servers. Github is not the KINGDOM of all code, it’s a great place to share. I share with my friends because I have worked with them on larger projects and they signed the same NDA as I have. Github it not a way to measure our dicks here. I can admit I suck at making beautiful UI that why I SUB it out. I stick to what I am GREAT at not just good. I guess that has been the whole point of my rants, if you can’t figure it out ask for help don’t bash on the tools that helped you create them. Most of the time it will take 2-3 years before MOST wrapper type tools to reach a point that they have become StABLE. That flower for Titanium has just started to blossom with 1.8. I got exposure to your blog from a guy who is now a client. He had all of the memory problems you spoke of. It was SIMPLE changes to how the was organized and structured along with adding some of the community workarounds to make it useable. He told me that they were going to scrap the whole project and do two separate builds one for iOS and one for Android. He had three quotes for each platform ranging from about $7500 to $10,000 for each. He was lamenting that the man hours already spent was about $5000 to $7500. For $5000 I went and fixed his problems. I started use Titanium for my mobile apps, I already had been using Xcode for iOS but for two birds one stone. I LOVE titanium, once you have a base that you start out with that has good structure and addresses the leaky memory it is a no brainer cost wise to use. Yep I could make two separate apps one in java and one in obj c, but why spend twice the time doing so. I guess i should be thankful to you YOUR blog because the gentleman that I spoke of read this blog and wanted to go native, I fixed that problem, I went to the Hot Springs with my son from that profit on a job that I spent less than 3 days on. I get every big problem that they need fixed in a hurry now. I love the Insurance//HealthCare/Construction industry.

        • That settles it for me. If you want to post something else here please do, but use a different tone – otherwise, your comments will be deleted.

          • Mike writes “I have told lots of my friends about this blog now and they are laughing at you for your plain ignorance.”
            andreadallera – congratulations on a blog that has clearly attracted a large number of expert opinions. I found it very useful and informative. Maybe Mike would be able to afford even more holidays in Hot Springs if he improved his attitude.

    • I hate to say it, but I think Mike is right. I understand his frustration with coders who are attracted to a development tool like this. It’s how I started out a decade ago…not knowing anything. It not only takes years of experience, but Mike should not put down the theory that is taught in schools. I think it requires lots of both. The theory is just as vital though to keep quality high.

      But at the end of the day, when a tool gives users too much freedom, it really does open the door to people complaining about the bugginess of their own code. Script kiddies (and I’m not accusing the original poster or anyone else in here of being one) ruin it for everyone else, Mike it totally right on that :(

  74. The nastiness of some of the recent comments has to be seen to be believed. Plus, it’s something of a red flag when someone claims that Eclipse is “THE” best IDE (in all caps, no less) and that anyone who doesn’t like it is “stupid”. Personally this is one of the reasons why I avoid Eclipse: I can’t stand the whole “duuuude just use Eclipse! (otherwise you’re stupid)” attitude.

    • Olivier,

      I stated that it was the best OPEN SOURCE. I did not state that they were stupid if they did not use it. There are right tools for different jobs. I also stated that I know many that just use VIM I did not call them stupid. The stupid comment is that Titanium is just a plugin to Eclipse, so there are many OTHER uses for it as well.

  75. Wow this is really going in another direction here….

    I think people should try things out and see what works for them.

    Obviously for some supporters of the appcelerator tech, we have made good apps, are comfortable with the technology and therefore either made good profit or a good free app.

    For people who went for xcode or core java, glad that it worked out for them.

    I personally believe in the “output” and not the “means”. If people like us are able to achieve a great output via appcelerator, good for us!! If people need “Core code” good for them. In the end its the app that counts!

    What sways me towards appcelerator is a quick build and the fact that we did manage to port apps to android easily!!

    • If you work with Objective-C you have complete control of what happens in memory – that’s the point. I think nobody expects Titanium to help you combat your bad programming habits but just to be a solid abstraction, which in my opinion it’s not.

      Titanium might work totally fine for you and for everybody – it all depends what you’re doing with it. If you’re not building something overly complex it might be a huge timesaver if you don’t know or don’t want to learn how to develop a native app.

  76. Pingback: Some thoughts of the future of Flash | Flash Monkey

  77. Checking in, since the, um, lively discussion on this thread has kept it high in the Google searches.

    Current release of Titanium Mobile is 1.8.0.1. Release notes:

    http://developer.appcelerator.com/apidoc/mobile/1.8.0.1/changelog.html

    As with most releases, along with our community we pushed hundreds of updates and fixes on both platforms. Some were memory related, some not. As was mentioned before, we take any platform-level resource leaks extremely seriously. The original poster was unable to cite specific instances, but if you can, let us know at community@appcelerator.com and we will escalate immediately.

    For those looking for general resource management tips and best practices, check out our wiki:

    https://wiki.appcelerator.org/display/guides

    and specifically:

    https://wiki.appcelerator.org/display/guides/Mobile+Best+Practices

    There are many reasons why an application could leak memory. Titanium does a lot to clean up for you, but there are instances where you will have to take the reins and do some cleanup yourself. The conditions in which you would need to do this are largely the same as they would be for native development (like when dealing with multiple large images and their associated, costly bitmaps, dealing with blob objects from the Filesystem in-memory, etc).

    As for the parity issues (an API works one way on Android and another way on iOS, for example), we recognize the need to improve in that area. We improved greatly in this area in 1.8, and our next release (scheduled for late March, 2012) is laser-focused on eliminating those issues, as they can be incredibly frustrating.

    If anyone stumbling across this thread has any general comments or concerns, or has specific questions on memory management in Titanium, please feel free to contact us at community@appcelerator.com, and we’ll be happy to help.

      • I’m sorry that Q&A posted didn’t get an answer, but all that demonstrates is that Titanium is bound by the same memory management constraints of JavaScript engines. The example was contrived, so I can’t be sure what the intent of the original poster was, but by changing his remove function to simply replace the reference of the memView object to a new view, the leak is resolved.

        https://gist.github.com/1847823

        The parent object which contained the “junk” containers is garbage collected when the reference is changed and the event handler passes out of scope, and the available memory goes back up to the level it was previously.

        When I said you failed to cite specific examples, I was referring to the platform level – I’m not saying there are no leaks in Titanium’s core platform (if we know about them they get prioritized right away) – but you didn’t mention anything at that level.

        There are many ways to leak memory in JavaScript applications. Titanium tries as much as possible to clean up, but we can’t anticipate every case, nor can we eliminate the memory pitfalls of JavaScript programming in general.

        I’m sorry you and some of the others on this thread ran into problems. Our software certainly has shortcomings. But as others on this thread have borne witness to, at the end of the day it is the craftsman and not the tool. Titanium can be and will be better and more tolerant, but many, many developers ship great apps on Titanium all the time. I am sorry you were ultimately not one of them.

        As I have said numerous times, though, we want everyone to get to a successful app. Please hit up community at appcelerator dot com with a Q&A link if you find yourself completely stuck, or can find a showstopper bug, and we will be happy to help.

  78. Titanium has also worked for us, for the most part. Started about 18 mos. ago, and it was painful fixing some bugs and waiting for the early SDK versions to be updated. More stable now. We have three apps in the store, all looking up data from our server in real time (very snappy). All accepted on first submission to App Store. We have never done any Obj-C coding.

    I agree that Android support is not at all what we had hoped for or expected (perhaps unrealistically). Got the first app to run but it does not run well or look nearly as good as the iOS version. The second one we are just starting to test in Android and one of the three tabs shows nothing at all, with no errors thrown.

    No memory problems we are aware of in any of them, and the first two were built based on kitchen-sink heavy JS pages, before we/they discovered the Tweetanium encapsulation approach mentioned above.

  79. Warning!

    In the beging of this post it says: “And it’s free! Support and other goodies come for a price but the library itself is free for commercial use.”

    This is no longer correct. They now require all organization to buy a license. So if you are a company you have to buy a license.

    Quote from mail with them “The price for the enterprise license based on 1 developer, building 1 app (across platform) for a company is €15,000.00 annual subscription for the license. ”

    That is for ONE app and ONE developer, annually! What would the cost be for 2 apps and 2 developers?

    In my opion very expensive and not worthwhile!

    We ended up using jquerymobile and it has worked fine for our needs.

  80. @Jens there has been some recent confusion in our sales organization. The core SDK is free and open source, and usable for commercial applications without any obligation to Appcelerator – I’m sorry you were told this, and we are making sure to clarify licensing for our sales team.

  81. Also, one of my comments on this thread is still stuck awaiting moderation, but we’ve recently updated our wiki with better documentation on best practices and manual memory management.

    Titanium does a lot to clean up for you, but there are things developers can do also, like nulling out references to proxy objects after removing them from the view hierarchy. There are also platform-specific considerations, like the VM memory budget imposed on Android apps (native-only and Titanium). We want everyone to be successful, so if you’re running into problems shoot us a mail at community at appcelerator dot com.

  82. Appcelerator is still a worthless piece of crap.

    I’m sick of it. Last year in February I told myself: “Really nice, there are some bugs, give them 1 year”… Now 1 year is over, and with every release you got to
    face other problems. They release stable branches, which honestly is beta at best.
    They break things without telling people. They introduce new problems, and let others unresolved. The build chain itself has other issues with nearly every release.

    I am really tired of it. We spent a lot of money developing our app with appcelerator, but it doesn’t lead us anywhere. Appcelerator is ruining companies in telling them the lie that it will be rapidly developed with their framework, and after all you just spent the same amount of time as if you would have gone native (because of those numerous issues), your code base is worthless, it by no means reaches native development quality. I also stopped posting ticket in jira, they are not handled, and or they try to close the ticket with stupid reasoning, but bugs still exist.

    They seem to have no quality control, and happily hack around on their releases without even bothering if the people after it, might work with a broken framework.

    I’m really disapointed and it cost our company money (and worse, TIME) since we are now in native development. Everything else was just for the dustbin.

    Do not dare giving this framework a try, the quality didn’t improve in any way during the last 16month.

  83. We have been using Titanium for almost 2 years, and have produced over 40 apps. Increasingly, a great deal of our business is mobile-based, and we fulfil the majority of the work using Titanium, with some native work when functionality is not included in the core (which, in fairness, is rare).

    While we had some challenges with earlier versions, particularly for Android, the product has improved considerably since 1.8. I am by no means saying that there is no room for improvement – I wish Appcelerator would concentrate on making the existing features work as expected and, to reduce the pain/code of producing cross-platform apps, they really should concentrate on making the APIs behave consistently across platforms.

    In my experience, though. a lot of the complaints about memory leaks are from people with limited experience of Javascript. I’ve been a JS programmer for almost 12 years, and the same “problem” has existed whatever technology I’ve been working with. It’s just a characteristic of the language and how it interacts with its environment. There is masses of information about this issue available, if people look.

    https://www.google.com/search?q=javascript+browser+memory+leaks

    A lot of “evidence” here is anecdotal. I think it’s fine to criticise (and there is a lot of it in this thread!), but it’s annoying when people don’t give a balanced view.

    I’m more than happy for people to disregard it, though. Mobile is becoming such a hot topic, that it simply further increases the demand for my skills! ;)

  84. In case my point wasn’t clear, the google search link above gives the main cause of memory leaks in Javascript, and how to overcome them. It’s very straight forward to resolve, as long as attention is taken when creating and destroying objects.

    • The problem is that here we have a layered cake with each layer: the Javascipt and the native layer, prone to developing memory and sundry issues. It gets pretty complicated pretty quickly and although I have not used Titanium myself I can’t help but sympathize with those who argue that it negates much of the benefit of such a tool.

      • Oliver, in my opinion, the issues you describe with the layer is no different to those when developing a native app. In Titanium’s case, the layer *is* the app.

        But, if you are right, we’d all better stop using Javascript in the browser, then! ;)

        • Which layer? My point is that when using Titanium there are multiple layers to contend with, so that this is not a net simplification. As for browsers, frankly that’s neither here nor there and I don’t know why you are dragging this into the discussion. We’re talking about native apps, not web apps.

          • Personally, I don’t worry about the layers – that’s Appcelerator’s job! ;)

            I was not comparing mobile native apps with mobile web apps. I was simply using the browser as an example of another environment where Javascript is used. To put it another way, what is the difference?

            Javascript Code -> (Interpreter + BrowserAPI/DOM + Browser) -> OS

            Javascript Code -> (Interpreter + TitaniumAPI + Titanium Native) -> OS

            It seems that more than 50% of the posts here discuss memory management but, as I have said, the symptoms are expected when using Javascript in the wrong way.

            Although many of the links I provided refer to browser memory leaks, they are also applicable to Titanium. Thus, the techniques they describe will resolve the majority of Titanium memory leaks. For example, the first result in the google search is the following, which explains the issue well.

            http://www.javascriptkit.com/javatutors/closuresleak/index.shtml,

            This obviously cannot resolve bugs that exist in the core API, and so it would be helpful if everyone could put pressure on Appcelerator to fix them if and when they are discovered.

            • Titanium and a browser work very, very differently when it comes to dealing with JavaScript. A JavaScript engine, like V8, is what is hosted by a browser, and is basically an interpreter. What Titanium does is something half a way between compiling JavaScript to Objective-C (or Java) and interpreting JavaScript inside the (painfully slow) JavaScript engine offered by the mobile platform of choice.

              The leaks Titanium generates have nothing to do with scoping. Here’s an issue with memory we’ve had and (at least in 1.6.2 and 1.7.0) that exemplifies what I’m talking about -> http://developer.appcelerator.com/question/120844/is-it-possible-to-release-javascript-objects-created-with-new .

              But memory issues are just the tip of the iceberg. Their APIs are (inevitably) constantly out of sync with what the native SDK offer… they’re trying to add feature over feature as fast as they can and they completely ignore hard-to-fix bugs in the process. Curiously this blog post has reached a very high position on google… I’m sorry about it, since it’s probably damaging them, but I hoped that at least it would have been a wake up call for them. Reading their recent comments here makes me think they haven’t shifted their perspective one bit.

              Once again: if you’re building a toy, a very small application that will not have to be expanded in the future, titanium might be okay. If you’re building something serious, think twice. Choosing a technology like theirs could cost you a lot of money.

                • My point is, Titanium *is not V8*. Titanium is not a JavaScript engine, Titanium *uses* a JavaScript engine.

                  On iOS, it uses the interpreted provided by the UIWebView – which is way slower than the interpreter in the mobile Safari, which in turn is slower than the interpreter in the MacOSX verion of Safari. Good to know that it uses V8 on Android though.

                  • I have never understood the argument about performance, provided an app performs within the limits of the end users’ expectations. If the app does not then it is, of course, not fit for purpose. So far, this hasn’t become an issue for me when using Titanium.

            • “This obviously cannot resolve bugs that exist in the core API”. Precisely. In order for these translator contraptions to deliver the promised benefits, which hinge on you not needing to know and understand the layer underneath (that is, the target of the translation), execution needs to be near perfect. If the layer(s) underneath poke through ever so little, pretty soon you have to understand them and the expected productivity/learning gains go out the window.

            • PS: I appreciate that you claim the memory problems are not a case of the native layer poking through but of improper use of the JS layer. However, as Andrea points out, even if this is 100% true of memory problems these are not the only ones exhibited by the framework.

              • Well, there will always be bugs in any software, but this does not necessarily negate the benefits. Actually, I have seen native bugs where workarounds have been provided by the Titanium SDK, meaning that we didn’t need to worry about them. There are pros and cons to everything, really.

                I find it is usually pretty simple to isolate true Titanium SDK bugs by stripping down the code, and using the native tools such as instruments and ddms.

  85. Titanium is not perfect, and it has its niggles. But it can make some pretty amazing things if you put in the effort. I’ve found that creating your own framework within Titanium is essential if you want to do any serious work.

    I have no experience with Objective-C, and all of my apps are coded in Titanium’s JavaScript language. Last year I made in excess of £50k on the App Store. I want to double that this year, and branch out to Android.

    • Currently I am also developing Apps with Titanium, and have already 3 in the App Store. These apps are quite simple, but doing some more complex stuff too, with big databases, lots of windows etc.

      So far, no memory issues. It just depends on your way of coding, and not on Titanium. You can also have a lot of memory issues with Objective-C or Java if you code bad. Same with Titanium. Do it the proper way (Not the kitchensink way) and you should be fine!

      • You could say the same of, for example, assembly – you can do whatever you want with it, and you will be successful if you code “the assembly way” – which is very different from the way you would write a web application, or a mobile application, or anything even closely resembling a modern business application.

        Trivia: do you know that Roller Coaster Tycoon is written almost entirely in assembly? Impressive, right? Having known that, would you write your next application in assembly? After all, an application as complex and successful as Roller Coaster Tycoon is written in assembly, it’s certainly the best tool for the job then… right?

        I don’t want to write code “the Titanium way”. What I want from a tool is that it lets me do my work while getting on the way as little as possible. Have you ever worked with Microsoft Access? It’s an *amazing* tool (I’m being serious. It really is) – as long as you do things the way it likes. As soon as you go out of the path, you’re screwed. Problem is, no matter how complete and well-built the tool is (and MS Access is waay ahead of Titanium in terms of completeness over its abstraction) you *will* find some cases that the tool doesn’t handle – that’s the reason why we all have jobs, after all. In those cases, you really don’t want to work with a tool that likes you only until you do things its way.

    • I definitely advise you to not invest in Titanium, that’s for sure – it will almost certainly cost you in the long run. Anyway, I think Titanium can still have some value: you can use it for small prototypes, or for applications that you know for sure will have limited scope, or as a learning tool.

      It all depends on what you’re trying to accomplish. If you’re doing something that you know will need maintenance one or two years from now though, steer clear from Titanium and go native :-)

  86. I developed a complex iPad application with several windows and states. Have had no memory issues whatsoever, regardless of how long the app is running for.

    I’m sure there is truth in this issue, but from my personal experience, I have had NO memory issues, regardless of app complexity.

  87. I’d also like to chime in that I think this post is right on the money, and I found many of the comments echoed my exact feelings. I only used Titanium for about 3 weeks, but it felt like 3 months. One of the most egregious things that is missing is pinch gesture support on Android. Come on, there has been a pinch gesture object similar to Apple’s since Android 2.2 came out. I wrote my own module to take care of it in just a few hours. However, the docs state that the pinch gesture is available on Android when in reality it isn’t. The forums seem overwhelmingly pro-iOS. Why someone would use Titanium for iOS only puzzles me to no end. Maybe I’m weird but I would never choose Javascript if I could possibly avoid it. Objective-C is a piece of cake, and even Java is better than Javascript.

    There are so many quirks between iOS and Android and they appear in Titanium as well. If I were developing natively, then I would be almost certain that if something wasn’t working correctly that it would be me who was at fault. With Titanium I never know if it is me, or some quirk in Titanium’s implementation that I didn’t know about. Here’s a fun one: If you pinch on iOS and remove one finger, Titanium reports that the touch has ended, and a new pinch has started (despite only one finger being in contact). If you remove the remaining finger, the touch end event never comes. Well, thankfully I was able to complete the project and submitted it to both stores today. Next time I will be going native on both though (I could have written this project natively on iOS in half the time it took….but I figured I’d give this a shot and try to save some time since I’m less adept with Android). The iOS version is pretty stable, but the Android is very iffy….sometimes if I just leave it alone, it will crash after a period of time despite not doing anything much besides playing an animation.

    I’m not trying to put down Titanium though, despite that rant. The idea is great, but the implementation is still dodgy. I can’t really blame the developers too much though, in fact I’m surprised and impressed that they’ve been able to even come this far. If you asked me to write something like Titanium I would laugh all day and tell you it was impossible. The moral of the story is that it takes A LOT to be able to develop for two very different platforms with one language (Take a look at how many people are involved with revising the C++ specs), so be wary of these kinds of solutions.

    • Yeap I am Fixes a few issues but still has one or two annoyances. More and more I see Titanium as a blanket that is not big enough to cover both shoulders and feet. It always seems there is something lacking either in Android or iOS (usually Android).

  88. Pingback: Quora

  89. Pingback: Articles titanium | blog nagy

  90. Nice post. I was watching continuously this website and I’m impressed! Extremely useful info specifically the last part I care for such info much. I was looking for this specific info for a long time. Thankyou and best of luck.

    • You promised this link last year though – “quote” – Ive built a very complex app recently and its our first B2C app, once on the store, will leave a link here… – dated 18th December. So did you really create it in under a fortnight? The only other app your company released was on March 15th so doubt you created it in under 2 weeks if you started back in December :)

    • Hey Rahul,

      Just pulling your leg in my previous reply :)

      Good to see you guys got a few apps out there. Are they on Android too?

      • Hehe, Ill let that one slide ;-)

        Unfortunately there are larger business process related delays with clients than the dev of apps when you work with large brands.

        The movie app was a genuine under a fortnight app though!!

        We have android ports of some of our apps but most are B2B so not pushed in B2C apps in Android store yet.

        But ill promise yet again ill have one posted here soon since we have a few releases expected next month.

  91. Our company is just starting in the field of mobile app development for our clients, and we started developing natively for iOS and Android using the Apple and Google SDK’s, even though we have a web development background.

    At first glance it may seem convenient for a front end web developer with existent JavaScript knowledge to use a framework that uses this language, but in my opinion the language is just a small part of the learning curve. A competent programmer should not have problems with learning a new language. The real challenge is to understand what design patterns you need to use in different scenarios, how you are supposed to talk to the API, and most importantly: what the design guidelines of the platform are.

    I personally think the two platforms are too different in their design ideas to be covered by a common API. You also have to remember that iOS app users are quite demanding in how apps should look and behave and they will burn you down in the store reviews if something is not right, and a perfect iOS app interface is not perfect from the Android point of view, and vice versa.

    Also, seeing that following this Tweetanium thing apparently gives better results than trusting on official guidelines (and quality documentation is the most important thing in any such project) does not give much confidence in the platform. Apple and Google provide good documentation, with a platform API reference that is actually complete with relevant examples.

    Based on these things we decided to just put different developers on the Android and iOS sides based on their preference and knowledge, with an interaction design team laying out the optimal UI for both platforms based on their human interface guidelines. Maybe this will take us more time to complete the work in the short term, but it gives us more confidence that we will be able to maintain good app stability in the long term.

  92. If everyone would follow guidelines to the letter, we wouldn’t see custom interfaces, right? So, there’s nothing stopping you from creating your style — isn’t it what should separate good app from an average one?

    So I see no problem with diversion from the guidelines when designing app.

  93. I have just given up Phonegap. I am a seasoned server side Java developer who was fascinated that even native Android dev can be quite fun and familiar. Anyway, being bored of some UI stuff and wanted to also port my app to iPhone, I tried Phonegap.
    I was developing with it for some 5 days. UI was quite OK in the beginning, I just needed to learn some JavaScript (Interesting exp… :-) ) . Today came frustration from all those javascript/phonegap callbacks when working with files, DB, networking. I have a logically sequential flow, but I need to implement it event-driven. The code is pretty hard to maintain, reuse gets lower…

    Well, ok, so I wanted to give a chance to Titanium, but after reading this post and all the comments (incl. “averything is fixed” from Appcelerator and then “no, it isn’t” from devs), I think I’m going back to native Android/Java and am going to play with ObjC. Anyway, I love Smalltalk :-)

    So thanks for your post and for all the comments!

    • Just FYI … having worked on both Phonegap and Titanium, the experiences are totally different. As any new programming platform both have a learning curve. Titanium offers a longer term approach with a SDK, regular updates, new features, easily found workarounds on small issues. All in all cross platform is a breeze with Titanium so I’d recommend to check it out!

      - Rahul

  94. For me…not related to memory management ..when i am trying to access online camera ..its very difficult to work with Titanium..we can use complex less application through Accelerator .The salute the their idea of joining all the three stuff(android,iphone,blackberry). I hope that team will over come the these issue…by Justin Mathew (Justinonday)

  95. I’ve been researching and hunting online for over a month now as it relates to the best app development tool. At one time I seriously considered Phonegap, then Titanium, then Mosync, then I was looking at Rhomobile and was about to settle with it. Now I am in the confused stage. I know that none will be perfect so I’m not looking for a perfect program.

    This will be new territory for me so testing them out fully may not be the best choice for me right now as I am not familiar with most of the programming languages. This is why settling on a definite one is so important as I wouldn’t want to invest my time in learning a new language in vain.

    I am confused about the cost. One person quoted US $15,000 per month earlier for one developer and one app… then someone from Titanium came and said no, its free. So whats the real deal? Free or not?

    Also, what is Rhomobile’s cost? I think it is free to use? What’s the cost if I want to produce my app for sale?

    And how will you fairly compare Titanium and Rhomobile? Or do you have another alternative?

  96. We’re now really getting tired of Appcelerator Titanium!! Performance issues, Crashes, Memory challenges & unstoppable customer complaints. As long as you have a basic informative app, Titanium will do OK but as soon as you start introducing complexity and start expecting it to do things like a Native App would do, problems start. Customers don’t really understand Titanium vs Native; they demand similar results regardless of which technology we use. PhoneGap is not a good solution either but at least it clearly conveys one thing that it is a purely HTML5 based technology so don’t expect any heavy duty from it. It runs in browser so expect what you expect from a browser. Dont expect it to do what a Native App can do. But Titanium markets itself as a tool which can potentially replace Native iOS, Android programming. This results in unwarranted customer expectations.

    On top of this now it seems they have changed their pricing. You can not develop App for 3rd parties i.e. your customers for free or using their old licenses. You’ve to use App Standard package at the minimum which costs $10,000 per year per app (YES PER APP!). Why will a customer pay $10,000 per year per app for the app that he isnt selling to make revenue but only to support his other existing business functions?

    Titanium is going on a wrong path…we’re now strongly thinking of saying NO to any Titanium business. There is no fun in it.

    • Hmmmn…. Well, I am just starting out and I definitely cannot afford US $10,000 per year per app! So without even looking further at Titanium, I’ll have to scratch it completely off of my list. Goodbye Titanium.

      How about Rhomobile? How does this compare with both performance and pricing?

      • Donna,

        After having spent considerable time with cross platform technologies, I’d strongly recommend using Native SDK. NOTHING CAN BEAT NATIVE and none of the best of the best cross platform technologies can come 100% closer to Native SDK, not even RhoMobile. BTW Rhomobile is very complex too with MVC and Rhconnect and RhoHub etc components.

        GO NATIVE!

        • I feel you Rich. I get you loud and clear. I guess like everyone else or most person’s, I was looking at a way not to code 2, 3, 4 or 7 times for various platforms if it can be done once with some tweaks in between. I’ve been hunting and researching this for almost 2 months now and I haven’t seen any great solutions as yet. Perhaps indeed, doing it one at a time with the original SDK’s for each platform might be the best way until the next 2 or 3 years when things will begin to change and go in a different direction again. Thanks.

      • Is this correct that it is not free any more and that it cost US $10.000??? Can someone from Appcelerator clarify, please?

        • I’m not from Appcelerator, but I just went to a Titanium meetup that 2 people from Appcelerator also attended. I asked them the same question and the answer was that this is the price of their Enterprise Support package. Titanium itself is free without paid support, and getting support is completely optional.

          • APPCELERATOR IS NOT FREE.

            Appcelerator has a big communication gap inside their teams and even within the sales team, one salesman says something and other says something else.

            Let me give you the details:

            This is their plan & pricing page http://www.appcelerator.com/plans-pricing.

            First note it says on bold at the top very clearly: ALL pricing is on a per application basis.

            Now, you scroll down and see the App Explore package which says it is free but Appcelerator salesman told me that you can not develop the application for 3rd party i.e. customers using App explore otherwise you violate their licensing terms

            This is the link to their legal licensing agreement of App Exlore http://www.appcelerator.com/legal/appexplore-agreement

            App standard and other packages are paid packages. App standard is $10,000 per year per app.

            When you show your reluctance to buy, they then pitch you the partnership program and tell you that if you become a partner for $10,000 per year, then you can develop as many apps as you want.

          • Okay… Did the cost to produce a single app came up as well. Because what I am understanding is that yes, it is free to download and install and use the software. but how about when I am done and ready to publish, what are the charges from Titanium itself?

            • I’m pretty sure there are no charges from Titanium for publishing your app. I did not ask that explicitly, but I did hear them say that support is their only source of revenue.

              • I just published an app using Titanium. There is NO charge from Appcelerator. The only pricing plans you’ll fine is for enterprise support.

                As a matter of fact since Ti 1.8 & 2.0 released it’s a nice platform to build cross platform mobile apps. You only need to be careful with you architecture or you are going to get in troubles with memory.

  97. Has anyone tried Titanium 2.0? Are there any significant improvements that mitigate the issues discussed in this thread?

    • Titanium has been very stable since its 1.8 release, 2.0 is more of a feature release adding cloud services support ie. push notifications, data storage on cloud, etc…

  98. After toiling with Appcelerator and Titanium Studio we finally released our first iPad app (http://itunes.apple.com/ca/app/visit-vancouver/id530049673?mt=8).

    I also made an extremely stripped down skeleton version of an iOS app with the Struct and memory pool concept already integrated (https://github.com/beebs93/titanium-ios-skeleton-app). It doesn’t *do* anything; it’s more to show how I incorporated Struct and memory management.

    I’m sure Native is better than any other 3rd party solution out there (and there are definitely technical and documentation struggles I reluctantly endured to finish the project), but for the right projects it can be a viable solution.

    Take the knee-jerk reactions you read here with a grain of salt. Do your own research to get the best idea if Appcelerator is really the tool you need for your project.

  99. And to clear up any confusion:

    Appcelerator
    Is
    Free.

    There is ZERO cost to publish an app to the App store (be it a free app or a $350 app).

    The sales team’s pitch is misleading, so that is most likely the cause of the confusion. When you first get started, just tell them thank you for the call, but you currently have no interest in their paid SUPPORT services. For me, I told them until their release cycle gets a little more reasonable and their product matures as a whole I have no desire to dish out $10K for support.

    If they even HINT that you need to pay first before you can publish an app, either just hang up or ask them bluntly if it is really true. If they lie, get their name and report them (I sure hope it doesn’t come to that).

    In my opinion, Appcelerator has probably lost a ton of potential customers because its communication with their sales department is absolute crap (hopefully, they remedy this – if not already).

  100. I agree with with you Andrea using Appcelerator is a waste of time if you do mobile develpment for a living. The more complex the app gets the faster appcelerator becomes part of the problem instead of the solution.

  101. I have to agree on the statement ‘The more complex the app gets the faster appcelerator becomes part of the problem instead of the solution’.

    I am freelance, and mobile dev is part of my revenues. I use Titanium to develop, and while it is a perfect fit for small to medium size apps, large apps have performance problem.

    I tried to create a POS app but deeper I was going in dev, slower the app was getting. In the end I just stopped the project because it felt that big apps need a huge work on performance, and I don’t have time to benchmark and optimise every process, especially when it is about correcting the bad memory managment of Titanium in large apps.

    Still, I want to be very clear that I succefully published several medium size apps with Titanium, and the dev experience was great !

    In my point of view Titanium has a strong dev team and I am sure they work on those memory issues continuously. So far I would suggest to fellow devs to evaluate how big there app should be and if it seems quite complex they may choose another dev plateform or be prepared to manage memory problems.

    Keep in mind that Titanium is in motion and things evolve fast !

    • Ain’t that the truth. I built a cross platform VoIP core in C/C++ and had it working on all the underlying platforms (Mac/PC/Android/iOS) and then had it working connect to all the Titanium UIs.

      Then they dropped the Desktop support so that screwed us.

      And their mobile platform was just a horror the further you went in with more complex apps or trying to duplicate some existing native look/feel..

      I spent more time solving problems in the Ti low level SDK code than pushing the application forward, it ended up being less than a zero sum game and was, unfortunately, not quite what it was made out to be.

      Performance sucked and weird glitches and memory issues (and yes, I followed single context and all the ‘rules’ with memory) and … the list goes on.

      Avoid unless you’re only planning on writing very basic apps…. TBH I don’t even see it has value for mocking stuff up as it lacks a UI layout editor, better to just learn Obj-C and use interface builder…. you’ll be learning it anyway fixing up Ti probs.

  102. I took the time to read through all the comments in here and would like to make my attempt at assessing Ti Studio based on my experience so far. I have been looking at Appcelerator for nearly two years now and a few months ago finally forced myself to learn it for a client project which the company which I work for accepted. I am about a third of the way through the project which is not small at all and these are my observations so far. I have also looked into Phone gap and read about Rho mobile.

    First of all I’d like to say that having used Ti Studio for a little bit I think that most of the stuff in here comes across as flaming and complaints rather than an objective assessment. Clearly Titanium is not perfect, but a lot of the comments here are just biased towards the cons of the technology and overlook its good sides.

    Now I’d like to cover who I think Ti Studio is for and who it’s not for. Programmers who already code full on JavaScript/ECMAScript applications in the browser or in any other environment will likely feel a lot more comfortable with Titanium than anyone else. This is because such people are already used to the good and bad parts of JS. Programmers with a “classical” programming background or anyone who finds things like prototypes, multiple ways of implementing inheritance, lexical scoping, loose typing, and memory leaks which the language exposes you to strange/terrible (and something they can’t get past) will likely have a hard time with both writing a complex application in JS in any context and Titanium Studio. In addition, people who are more comfortble with HTML and CSS than JS will have a hard time, because almost everything that you write in Titanium is pure JS.

    Now background differences aside, what’s good and what’s bad about Titanium. The good:
    - a reasonable, Eclipse-based IDE which also works for other programming languages (in case you are not happy with whatever you are typing your code in now)
    - a lot of the methods for doing things in Ti Studio are quite straight forward (you use their API to make things and maintain them)
    - you don’t have to learn another language if you already know JS well
    - they recently (April 2012) released a very powerful and easy to use cloud service, this should be a really big deal who people who would prefer not to maintain their own back-end infrastructure
    - with the release of 2.x they completely redid their online documentation and put the docs, the wiki, and their video channel in the same place (which makes finding whether they have something clearly documented or not a lot faster), their old online documentation was terrible

    The bad:
    - the documentation lacks examples, you will likely get frustrated that certain things are just not documented/shown anywhere
    - there is very little consistent discussion around how to structure your apps and the pros and cons of high level patterns, this problem is further complicated by the fact that practically every application published by Appcelerator themselves and/or anyone else on Github is structured differently. It’s totally unclear whether this is because the technology evolves rapidly, because these are just sample apps, or because you could really argue that different ways of doing the same thing will certainly suit different apps better.
    - you may experience issues getting Ti Studio to run initially and in some cases between updates, nothing unresolvable but your frustrations may begin earlier than you expect
    - there is no explicit memory management, you can do certain things to improve this but as far as I know you have no way of seeing how your memory is used at any point really and which areas need improvement
    - due to the factors mentioned above the learning curve for Titanium will likely be at least somewhat steep for everyone except developers who shred JS all day long and have very good understanding of what happens behind the scenes when JS code is executed (in general and within Titanium)

    Appcelerator recently released a set of cloud services which I consider totally awesome regardless of whether your wrote your client with Titanium or something else (the services are exposed through a REST API to everyone who’s not using Titanium). They include predefined, extendable objects for common mobile app elements like places, photos, check-ins, etc as well as completely custom objects. The services are free below a certain usage threshold and pricing is based on volume/usage beyond that point. The integration between Ti Studio and their cloud services is currently not perfect but pretty sweet nonetheless.

    Now the conclusion (based on what I know about Titanium thus far, I promise to come back and write more when we have a couple apps in the app store / android market):
    - if you are type 1: you like JS, are perhaps very comfortable with it already, have some patience, and you are not writing wildly complex apps (trying to write things like a graphics-heavy games in anything but native code is silly regardless of what tool you are using), you can write some fun apps with Titanium and will likely enjoy it’s ease of use. 
    - If you are type 2: are used to strict typing, classical inheritance, strictly defined high-level patterns, and not much room for error you should consider using the native SDKs over Titanium.
    - If you are type 3: not *that* comfortable with writing entire applications in JS and you are looking for a tool which will allow you to “leverage your mad HTML/CSS skills” you should probably look into PhoneGap or something even simpler.

    Please note that I have not written a ton in Titanium and I mIght be overlooking some of aspects of it which others use as an excuse to flame/complain. I’d be happy to share more of observations when I have more experience with Titanium.

    Stoyan

  103. Pingback: Weird rocketry » Blog Archive » Phonegap vs. Titanium

  104. Actually I believe Titanium sucks.. I can’t even run the sample applications, it is a hell of errors and warnings.. hundreds of errors, nearly 5gb installation and nothing works!

    • Tell us what’s wrong instead of just whining in vague terms. You come off as a either a newbie or worse. There’s been a ton of apps built with Titanium, there’s alot of best practice documentation/projects out there.

      As for the other people who come read this article because of the flashy title – being able to write code in JavaScript does not mean you are instantly a rockstar Mobile developer. You have to learn the underlying platform, learn Titanium, learn the best practices of both, then begin the journey. Titanium lets you put something together quickly – but you still need to learn the nuances of the platform you are running in on, and engineer an app accordingly.

  105. I used Titanium for a bit but it didn’t fit my needs. Mostly the same problems mentioned in the post and through the comments.

    I’ve been using GeneXus and would highly recommend checking it out. It costs $, but is a more mature platform and seems to have these sort of bugs ironed out.
    -It generates native code
    -All my apps work, the first time, fit UI guidelines, don’t crash…etc.
    -Connected to our existing database to extend our webapp
    -AND created a new database for me for our completely new app.

    Anyway, obviously choosing a platform depends on the project and developer, just thought it was worth a mention.

  106. Pingback: The problem with crowdfunding: Is Pixate astroturfing Kickstarter? | t1u

  107. Pingback: The problem with crowdfunding: Is Pixate astroturfing Kickstarter? | DragonTortises.com

  108. Hi
    I am starting to develop a social network in a specific domain .
    The social network will include uploading photos, videos, adding texts, and events
    I would like it to fit both ios and android.
    I am considering using Titanium and i am pretty scared as a results of whats written here.

    please, i would like to get an advice on this topic

  109. Pingback: App Development: Appcelerator vs (Phonegap + (JQuery Mobile vs Sencha)) | A Techsolutionist's Blog

  110. I’m so glad I read this.

    I had just finished reading the debacle of how they demand $7500 once your app makes it into the wild and they see it (even though it is supposed to be open source), and was considering going with them after half an assurance from the staff, but after reading this I am just going to bite the bullet and learn to code it direct.

    • I was in the same spot as you about a year and a half ago. I wanted to like Titanium so much, I even spent three months tearing my hair out writing a cross-platform prototype of a project I was working on. Too many bugs, leaks, faulty tools, and even JavaScript itself is prone to leaks. Then I discovered Objective-C/Cocoa and the amazing tools like Instruments and LLDB, fuck going back to that nightmare.

      I recommend you check out Stanford’s iOS development lecture classes they put on iTunes U if you haven’t already. Just go to the iTunes Store and look up “CS193P”, its good stuff.

  111. Hi guys, first please forgive me my bad english.

    The cross platform development task is an issue far from being born yesterday ! And Few approaches can be (and had been) thought :

    - first, simply don’t have any heterogeneous platforms ! This of course is not a realistic one today (where many environments live on the same scene : native character/ascii – mainly from midrange and mainframe, revamped ones, native desktop and mobile environments, classical web environments, AJAX web environments, etc.) !

    - second, arrange to hire several experts, each knowing perfectly one targeted platform and have them do the trick of generating specific different sources (sometimes in different specific language) and compiled binaries, each working in his place with specific T-Shirts labeled with the name of the targeted platform.

    - third, arrange to hire several experts, each knowing perfectly one targeted platform. Start from a common source tree in C and have expert generate conditional statements in macroprocessor to fall with modified makefiles, along with several patches. Then Cross-compile for each targeted platform.

    That’s the way followed for the NetBSD operating system, and it gives pretty well results (just look at the supported platform list, all binaries generated from a common source tree).
    But that’s more complex with user applications than with OS : one of the great problems is the HMI ! Which windowing environment ? Which toolkit ? Which license ? A real nightmare in this area … This is the way chosen by Titanium, and the resulting product is not so bad if we think of the real complex task to realise ! Yes, there are glitches, and there would always be some. This product has the merit to exist and that’s a really pleasant perspective.

    - fourth, utilize a thin client/server approach, with an application server and some intelligent terminals bundled with a common protocol terminal client software. The app is written for the server platform (and it is likely that this one his homogeneous amongs all servers in the same scene).
    The most universal type of this thin client/server approach is the web client/web server one, with AJAX based rich GUI nowadays.
    There is no issue about cross-compiling here, and different GUI environments (yes there are some graphic resolution and screen orientation issues).
    The problem here is that the network is mandatory and that only connected sessions can be ran. The terminals aren’t autonomous at all (there are/were some technologies for terminals to continue working disconnected, as the Google “Gears” one), and this can’t be a viable solution for embedded native apps.

    - fifth, use a common platform independant language and a well suited runtime for each targeted platform.

    That’s the way followed by John OUSTERHOUT (Berkeley University, then later funding sunscript when hired by Sun Microsystems) with the pretty good, light and GUI rich/light and object oriented (if needed) “TCL/Tk”, along with its TCLKit runtime. This one lead to really fabulous and easy deployment on any supported platform (only two files to deploy : the TCL/Tk runtime “TCLKit”, and the application archive STARKit ; it can also be done with only one compiled file : the STARPack which embeds the TCLKit and the STARKit all together).

    That’s also the way followed by James GOSLING (Sun Microsystems) with the pretty good “Java” and the AWT and today Swing GUI/Toolkits. Yes these GUI toolkits are the heavy dog of Java, but they permits (with more or less luckyness) to “write once and run many”. There is nevertheless some deployment complexity.

    It’s also the way Microsoft done his .Net framework, but it really lacks a common GUI environment (WinForms are only suited for Windows platform ; Mono/GTk# solve this issue, alongside with deployment complexity).

    The promising next technology of this way is Common JS, all in Javascript, client and server side, or on autonomous platform likely as a native application (aiming cross-environment : native desktop/mobile, web, etc.). It’s up to Apple, Google, Microsoft, Nokia and the affiliates to release a Common JS runtime suited for their platforms (including the most forgotten but important part ; the GUI).

    In conclusion, just appreciate the Titanium efforts, choose the strategy to suit your needs (it’s up to you and only you to decide. Titanium don’t force you to use it !), and follow/be informed of the last, cutting edge technology improvement …

    Mickaël SUZENNE
    sysadmin/architect/dev

    • Totally agree. Using CommonJS in conjunction with eg. PureMVC or another framework is definitely the way to go using Appcelerator Titanium. I also use LiveCode (RunRev Ltd) and it is also not so bad, only the syntax is not common.

      Erik Beugelaar
      Cross-platform Developer

      solidit.eu
      nl.linkedin.com/in/beugelaar

  112. Just to be clear, any memory leak related problems are caused by the developer’s lack of understanding of how JavaScript memory management works. It is a pass-by-reference/garbage collected language. If you don’t understand what that means, you should read up on it, or stop programming in JavaScript. But one way or the other, your memory related woes have nothing to do with Titanium and everything to do with your lack of understanding as to how JavaScript manages memory.

    I am proud to say that I am busy developing my first app in Titanium. When I first started I had 12MB worth of memory leaks … but after reading up on JS memory management I have successfully eliminated all leaks.

    There are other areas where Titanium is a compromise and will never be as good as true native development, but harping on about something you don’t understand only demonstrates your ignorance. So next time, try doing the research before bashing something you don’t understand.

    • Here comes Captain JS to save the day! Thank you, Captain JS! Now I know that JS is a “pass-by-reference/garbage collected language”! I should have done my research before bashing on something I didn’t understand!

      You’re developing your first app in Titanium, you say… let’s talk again in a couple of months then :)

      • “Captain JS” … LOL. I never used to think of myself as a super-hero … but now that you mention it …

        I think many web developers will look at Titanium and say “Oh, so you do everything in JS. I know JS, I can do that …”. The reality is that programming JS for a browser and programming an entire mobile app in JS are two very different things. We tend to play it fast and loose with browser-based JS because we don’t encounter the same resource limits found on mobile devices.

        For those developers who are used to programming in languages like PHP, memory management is hardly ever an issue because PHP does most of work for you.

        However, JS leaves it all up to you. Every object needs to managed as if it has a life cycle. When you are done with an object you have to mark it for garbage collection by nullifying the object. This doesn’t guarantee that the memory will be immediately freed, but when the app (or the OS) does need more memory it can run the garbage collector and free up what it needs.

        The other issue is that it works with heaps. Say, at peak memory usage, the app uses 20MB of memory. Android will allocate a heap of 20MB to the app. When some stuff gets garbage collected and some memory freed, it only marks part of the heap as being available for use … it does not necessarily reduce the heap size. So it may appear as if the garbage collector is not working, but in reality it just hasn’t reduced the heap size allocated to the app. If you have many apps running at the same time and the OS needs to allocate some memory to another app then it may reduce the heap size, but otherwise it is going to look like the memory isn’t being freed.

        I would recommend you follow the instructions on this wiki page to get ddms up and running:

        https://wiki.appcelerator.org/display/guides/Managing+Memory+and+Finding+Leaks

        That will allow you to monitor different aspects of your app while it’s running in the emulator.

        Currently my app has anywhere from 100,000 to 1,000,000 objects in memory at any one time (depending on the dataset selected by the user) and the app is running smoothly on my Samsung Galaxy Gio (which is the bottom of the range of the Galaxy range of phones and runs Android 2.3.3). It features tables of data, images (both local and remote), audio (both local and remote), sqlite database, downloads/uploads data to a remote server, gps functionality, maps with observation points, distribution maps and plenty of other awesome features. I have also tested the app on iPhone 4 and Samsung Galaxy SIII (Android 4.1.2) and Galaxy Note II with similar results on all of them.

        Admittedly, iOS does a much better job of managing memory than Android does but if you know what you doing, you can get it running smoothly everywhere.

        Good luck for the future and don’t give up so easily … the knowledge and experience gained is worth the effort and when you return to good old browser-based JS you will find your JS skills vastly improved!

        • If your app has anywhere from 100,000 to 1,000,000 objects in memory, you’re either doing something very special or you’re doing it wrong. Since you talk about tables, it’s most likely the latter.

          It’s cute the way you patronize me. Good luck, you’ll need some.

          • Remember that I’m not only talking about objects created with Titanium’s create functions. In JS, if you say:

            var a = 1;

            JS will now create two objects in memory. One object for the variable “a” and another object for the value “1″.

            When you are finished using “a” you need to set:

            a = null;

            This de-references the variable object from the value object and allows both to be garbage collected.

            So an object in JS is not only something created with the Ti.UI.create functions. Everything in JS is an object, so 100,000 – 1,000,000 objects is far from inconceivable. In fact, it’s quite possible – as evidenced by my app.

            Try getting ddms working with the Kitchen Sink app and you’ll see what I mean.

            I’m sorry if you think I’m being patronizing. I’m only trying to help and share what I’ve learned.

            Good luck …

          • Here is an excellent article on the Mozilla Developer Network about JS Memory Management:

            https://developer.mozilla.org/en-US/docs/JavaScript/Memory_Management

            There is something very interesting under the “References” section on that page:

            “In this context, the notion of ‘object’ is extended to something broader than regular JavaScript objects and also contains function scopes (or the global lexical scope)”

            It means that, in the context of memory management, even functions are objects. Indeed, when you are finished using a function in JS, you should nullify it like so:

            function someFunction() { … }

            Now do this when you are finished using “someFunction”:

            someFunction = null;

            Now, just to be clear about what happens when you compile an app in Titanium. Titanium does not convert to native code when compiling your app. What actually happens is that your JS files (along with the JS Engine) are packaged with the app, installed on the device and executed every time you launch the app.

            This is why JS memory management is so important in the context of an Appcelerator Titanium app. On desktops we tend not to worry about memory too much, but mobile devices have resource limits that would make any desktop shy.

            Interestingly enough, it turns out that Objective-C (native iOS) and Java (native Android) are both garbage collected languages too, so the native object, the proxy object and your JS objects won’t be freed until all JS references are removed.

            • Objective-C on iOS is not garbage collected. It uses Auto Reference Counting, which automatically inserts the retain and release statements in your code. Prior to iOS 5 you had to control the retain count yourself, with it finally deallocating when the count reached 0. ARC may seem similar to GC, but fundamentally it is a different animal.

              • Wow! Thats interesting … If it “automatically inserts the retain and release statements in your code” I think that may explain why iOS seems to be “better” at memory management than Android in the context of an Appcelerator Titanium app. Because the system does not rely wholly on the developer (like JS and Java do) to manage memory properly.

                Thanks for sharing :)

          • When you mentioned tables here, it got me thinking … why bother with tables when you can achieve the same effect using simple views. The click event on the scrollview that contains the “row” views returns the source of the click anyway and it allowed me to save about 25% memory usage on that module by eliminating the table object and it’s row objects.

            I also found that the table object itself seems to have a memory leak when trying to clear the table rows using the setData function, so the restructuring of my code also allowed me to completely eliminate a rather large leak there …

            My app is now performing better than ever, so thanks for that :)

  113. Since the discussion is still going on I’d like to have your insights :

    I am a titanium developer and those days I am getting frustrated passing an app to Android…
    More I think about it more I believe the only efficient cross plateform solution is HTML5. Titanium like other solutions can push javascript inside a webview which make it possible to use native functionnalities and display results inside the html5 website.

    The idea would be to create some kind of hybrid native app :
    + A webapp in HTML5 to be optimized for most of smartphones with the main functionnalities
    + An app container in Titanium/Phonegap/etc. which would be limited to perform plateform specific actions and push results in the website using javacript (Ex: Register for push notifications and once done send the result to the webpage).

    The root of the app would be an online HTML5 webpage and the native app javascript code would be limited to the minimum to ensure an easier cross development.

    What do you think ?

  114. If you stick to the guide lines, than its ok to work with. I find no problems whatsoever, im using it for 6 months now and have 2 apps in the stores. Now Im making a tablet, android and ios app in one, how awesome is that. If you stick to common js and know the limitations (different scopes and using globals for example) than there should be no problem. It has some flaws like some functions dont work (like changing the tabbar color on iphone or adding events to the tabbar), but for me that is acceptable.

  115. Appcelerator sucks for MANY reasons not just memory management. I have developed several apps using appcelerator because I thought it would help me develop cool apps faster (that wasn’t the case.)… Appcelerator serves it’s purpose for SIMPLE apps… When I say simple, don’t do anything crazy! Text-based apps primarily…

    1) God forbid you need support, there are questions in their forum that are years old with no reply.

    2) The simplest tasks require ridiculous workarounds… The apps start of at 6MB… while objective-c I can build the same app in 2MB…

    3) The apps DRAG… they are slow, they open slow, the JS engine they are running sucks!

    4) Most of their shit is broken and you have to find workarounds.

    5) DO NOT use their modules… I used the “Bump” module once and it didn’t work. AT ALL, I had to start the app over in native objective-c…

    There are many more reasons… but honestly, appcelerator is terrible all the way around. It’s not worth the effort. They say you can build something in appcelerator 10X’s faster than in objective-c… I disagree. Objective-c is not really that crazy complicated and I urge programmers to stop being so fucking lazy and learn a new language! You are selling your clients shit work!

  116. Pingback: Appcelerator Titanium Mobile – Pros and Cons | 303 Velocity

  117. I also used Titanium for a year, and what a “wonderful experience’ – random errors, bugs and most importantly when an error occurs, you will start to doubt whether it is your mistake or unresolved bugs with Titanium.

    For those who claim that your app has made it into the store and this means Titanium is not “crap”, that is certainly untrue. My app also made it to the app store, after rounds of frustration. You could have of course made your app using Titanium, but not without bugs or cutting down features because of unresolved Titanium bugs. Speed is also a definite issue, and I personally can’t resolve it no matter what., trying different solutions. If some pros claim that ” they can resolve the speed issues, using memory management tricks etc.. good for them but i am sure the effort spent you might as well code in native.

    And one thing is for sure, native speed 100% beats Titanium. Native stability 100% beats Titanium. Finally one thing is for sure too, Titanium is super buggy piece of crap if you want to do any decent stuff – by that i dont mean placing a few simple textbox, texttield etc.. I mean using gps, implementing a long list with hundreds of rows with images and text without lagging. (Native has no problem doing this. you can view many other apps example in store.)

  118. This article is sad but true. I have my application working perfectly, and from time to time objects will lose property values and random “bugs” will be introduced. If I alert the objects or make a comment in the code file that the bug originates from… save… and reload the project… taadaaa the bug is fixed. Magic eh? This isn’t the kind of magic you want with your apps. I’m thinking about exploring Xamarin for my next application. Titanium was a huge disappointment! Talk about days (not hours) of my time wasted on bugs that didn’t exist… oh, and if you think the memory leaks are fixed…. try running the profiler in xcode… you’ll see differently.

  119. Pingback: Minimal Monkey - Stephen Burgess

  120. thanks Andrea for writing this article, saved me a lot of time and headache. Was considering using AppCelerator several months ago but then came across this article and decided to go with MonoDroid/MonoTouch by Xamarin and could never be happier – C# rocks!

  121. Hey, Andrea, thanks for this post! I feel you. I’ve been from native mobile development and I’m having problems explaining to our company to stop relying on titanium. I’ve created two complex projects using titanium for them and I can say that it’s performing poorly. I even had tons of bugs I’ve encountered that I’ve listed especially on complicated and nested interfaces. Complex UI with data management is really having performance issues. I can’t even optimise the approach since it’s not even a real object oriented platform and lacks the power provided by OOP. At the end of the day, you start to doubt your ability to do a good application because of these bugs and start to think that your bosses think you’re just to lame that you can’t do anything about it. Anyway, great article! =)

    • I had that same feeling of wondering “Do I just suck?”. After you’re plagued by ghost issues that haunt you at the most irrelevant and unexpected times for so long… you start to doubt yourself. I’m extremely happy about switching to Xamarin! I think the best option will always be native, but… performance has been great… and I love C# great language.

        • I don’t think you should have to rig what you’re doing, or make sure that you develop in a specific way to avoid problems. The amount of problems that I’ve personally encountered (not to mention the other users on here) was horrible. You can of course look up as many ways to avoid Titanium’s inherent problems as you want, however I don’t really think this should be a necessity of development. If Titanium works for you, rock on and I’m happy that you’re enjoying it. But, I would never be able to recommend this to anyone.

          • I am not a person to rig for whatever. I just didn’t had any problems with memory leaking or whatever. By the way, I also prefer programming in Objective-C, Java or LiveCode (give it a try!).
            It depends on the size of a projects and cross-platform speed to make something fast.

            Cheers,
            Erik

            • I’ll probably give obj-c a try. I prefer C# over Java. It really doesn’t depend on the size of a project to make something fast, although that can be a factor in the initial and ongoing design of the software. Not 100% sure what you mean by cross-platform speed (speed of development?). I’m somewhat looking forward to Obj-C even though I won’t have time for it for awhile.

              • Yes, in the initial fase a tool like Titanium can be an advantage, even for a follow pro app. Customers often want to see results in an early stadium and then you need to show something quick (and often dirty…). By speed of cross-platform I mean the ability to develop a fast working version for eg iOS or Android. If you develop native iOS you need double time to produce the same app in Java. If you focus pure on an iOS version of your app I would advise you to use Obj-C or look at LiveCode (www.runrev.com). They just have make it FOSS and it’s the follow up of HyperCard, Super Card and Meta Card, very known in the Mac World of developers. But it’s a different approach to develop software but it’s POWERFULL.

                Cheers,
                Erik

    • I stopped using Titanium a couple months ago after investing over 200 hours in a project. I would recommend using Objective-C, or Xamarin. Titanium has been a horrible experience.

  122. I was pretty much finished with Titanium when I wanted to enter my first three lines of code using their “Studio”, and it froze completely four times during that attempt, for 20 seconds each. How am I supposed to even write code like this?

    • Whilst I do hate Titanium, I really dont have the motivation to learn ObjC as from what I can tell, I first need to learn C/C++. I’ve come from a PHP/HTML/JS background, so Titanium was the logical option for me.

      I’ve found it to be a pain in the ass, one such example. In the documentation for ‘TabGroup’ they show an option to set ‘backgroundColor’ and ‘backgroundImage’.

      They dont work. They never have, they never will (due to an iOS limitation). The Appcelerator doc writers know they dont exist, and have known for 2 years. Yet it’s still documented as existing.

      The platform pisses me off massively as it could have been fantastic, but is poorly maintained.

      I learnt Java at University and havent used it in a couple of years, but think I’m going to end up doing a native Android app (as titanium performs HORRIBLY bad on Android) and then stick with Titanium for the iOS app. Then one day learn everything for iOS. Any pointers for this part would be very helpful!

        • I like the look of Xamarin (especially as I’m a .Net dev) but didn’t bother due to the free version being so limiting, and the “Indie” version being too expensive for a hobbyist. I’m currently looking at Titanium, but the alarm bells started ringing after spending 3 days trying to get it to a point where I can actually run an app on the emulator (despite following their install docs to the letter). Now that I can, I’m finding it slow being comprehension. At this rate I might just fork out the $299 for Xamarin.

  123. Proof that this is true is the NBC app that is often prominently listed on their website and that titanium boasts about all the time….
    3.5 star rating on IOS
    1.5 star rating on Android

    I think these ratings are a good representation of the (lack of) quality of this platform especially on android.

    This app was made with what we can only assume is the highest level of paid “enterprise” level assistance and features as well so good luck on your own!

  124. Andrea, you get a lot of comment spam. I sometimes wonder if it is appcelerator’s way of defeating your blog ;-)

    Anyway, why don’t you add a captcha module or something to limit this annoying spam? You could also moderate the comments before publishing them.

    • Hei Martin :) thanks for the pointer, I don’t think I can add a captcha but I’ve enabled moderation at least, let’s see if it’s manageable to do it this way. I have neglected my blog for quite some time now, I should really get back to it :)

  125. Great post, I’d appreciate more technical insight and maybe some performance/testing comparision to make the points stand out.

    Now whilst I agree that Titanium/Appcelerator development might be somewhat faster/easier, it doesn’t necessarily mean that it is better. A common problem that I’ve run into with Appcelerator projects was incapability to effectively do a background work, or multithreading in other words. Say we’ve had the iOS app download and process some data, including resizing images and creating and storing the thumbnails in devices cache. This was nothing but a pain with Appcelerator, which was effectively blocking the UI and thus greatly reducing user’s experience with the app. If we needed performance or some special native stuff, we had to create module in objective-c, which then added the total time needed for development, effectively ruining our great idea of RAD development with Titanium…

    But to be fair, if you want to create a simple multiplatform app quickly (i.e. app that shows splashscreen and two lines of text), Titanium is a great way to start.

  126. Titanium is a joke.

    Here is our story: our dev. team had already created several apps w/ Objective-C. Then my company got a new VP (with a marketing background). He attended some conference and was “sold” on Titianium so he made us switch, thinking it would boost our app output greatly. Nobody on the engineering team agreed but he’s the boss so we did our best. Nothing but problems w/ Titanium. Basically, it locks the developer in this “crawl space” with little elbow room. We weren’t getting anywhere after a month and the VP screamed at us saying we were “incompetent.” Remember, this bozo is a “marketing genius” (as he calls himself). Well, believe it or not, the client educated him in a New York minute about letting us (the developers) make engineering decisions. So he finally admitted defeat and let us return to Objective-C.

    Bottom line? If you’re going to do ANYTHING serious, go native. End of story.

    • It sounds like your VP is an asshole. But I agree, business people should not ever make technical decisions.

      I would recommend checking out Xamarin. I’ve had pretty happy results recently with it (as background, I developed native Obj-C/Android apps for 3 years prior)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s