The Future of Titanium Desktop

futuristic concept server technologies and the technological background

Titanium Desktop is a remarkable open source project.  The ability to deploy a Webkit-based desktop application across all three major desktop operating systems, with privileged access to native APIs, has empowered web developers to escape the browser and deliver rich, “always on” desktop apps.  Today, we’re announcing the next phase of the Desktop project, as we call for leaders and contributors in the Desktop development community to take the reins and decide Titanium Desktop’s future.
With the increasing divergence in architecture between Titanium Desktop and Titanium Mobile, we feel the time is now right to spin off the Desktop project into a separate, community-driven project.  If you are interested in helping chart the course of the Desktop project in the future, please join us on this mailing list as we take the first steps toward establishing an independent governance and technical leadership structure for the Desktop project.
Our decision to split Desktop off into its own project is not a reflection on the technology its self, but rather on our goals and focus as a company.  Appcelerator is committed to delivering the best mobile application development platform in the world, and we feel that we need to focus in 100% on that goal.
The new Desktop project, which will undergo a name change from Titanium Desktop, will be governed and developed by the Desktop community, with material, administrative and logistical support from Appcelerator, but limited development resources. From the Appcelerator side, I will be acting as the liaison for this community to Appcelerator, and facilitate any action or assistance that needs to be rendered from our end. To participate actively in the transition, please join the Google Group here:
Below is a rough roadmap of what changes we intend to make, and when we would like to make them.

  • January 2012:
  • Call for participation in the Desktop community
  • Interested parties will sign up for an ad hoc group of potential developers and contributors (titanium-desktop-transition Google group)
  • Open call for alternative names for Titanium Desktop, as the Titanium brand will remain only for what is today the titanium_mobile codebase
  • Governance structures will be put in place for this project, modeled loosely after other major community-driven software projects, such as jQuery.
  • Nominations for a project board of directors will take place.  Board of directors will form the primary governance structure for the reformed Titanium Desktop project
  • Board will govern the project by parliamentary procedure (Motions: – majority rules on project decisions.
  • Project wiki and web site created
  • February 2012
  • Board will appoint a technical lead for the desktop project.  Appcelerator will work to provide GitHub repository administration and any administrative support needed
  • Development support will be provided as best we can to help facilitate the transition to a new technical lead, and to get the project off to a rolling start
  • Technical lead will provide a roadmap for the next release version of the Desktop SDK.  Can use Appcelerator JIRA or a bug reporting suite of their choosing
  • Technical lead will submit a list of JIRA or work items for approval as the backlog for the 1.0 release of the re-branded Desktop
  • March 2012
  • Backlog will be worked through by interested peers in the Desktop community
  • When the backlog has been depleted, the technical lead will create a release of the desktop software.
  • Technical lead and board of directors will begin work on the next phase of the roadmap.
  • NOTE: Desktop project support dropped from Titanium Studio by end of month
  • NOTE: Appcelerator-managed desktop packaging servers may be taken down at this time – we may leave them up slightly longer, but reserve the right to shut down the service at this time
  • API and reference documentation for Titanium Desktop 1.1 moved to new project web properties
  • September-December 2012
  • Assuming the completion of a release or releases by the newly formed Desktop team, Appcelerator will initiate an application for contributing the Desktop codebase to both the Apache Software Foundation and the Free Software Conservancy, with whom we’ve already been in contact.
  • If accepted to either, financial sponsorship and the transition of authority will pass from Appcelerator to the new sponsor.

Once again, we encourage all members of the Titanium Desktop community to be a part of this project.  We think there is a bright future for the Desktop project, and look forward to supporting its community in the next phase of the project’s development.

Previous articleUpgrading Android Modules to
Next articleInternationalization of App Names


  1. hey kevin,
    thanks for letting us know whats up with ti desktop.
    q: will the code driving the Appcelerator-managed desktop packaging servers be opened up as well?

  2. I find this a little bit worrying as a new user and wanted to ask for a little clarification. I apologise if my question below seems a little simplistic, but I am coming at this as a C++ developer who was looking for productivity by having a shared code base for all platforms.
    Does this mean that we will no longer be able to have a shared architecture for desktop and mobile platforms?
    Obviously there are already differences, but my draw to Titanium was having everything in one place and writing code once as often as possible.
    Thanks for reading.
    P.S. Your captcha is really hard to read – on try 11 😉

  3. @kevin mccaughey: As it stands at this moment, the Titanium desktop and mobile APIs are separate and always have been. You are still able to share all of your business logic and non-UI code among your mobile and desktop projects, though, as they are all still currently written with Javascript. This is unlikely to change going forward.
    @Tobias: Appcelerator is willing, as stated in the plan above, to put in a lot of work to make sure the desktop project continues on. The only uncertainty is who will take up the task of ownership and how many will vie for that spot.
    Also, Titanium Desktop has always been free and open source. We will work to make sure an appropriate structure is put in place to manage the proect, but anybody can still be an “owner” per se, as is the nature of open source software.

  4. The short abstract of the long news:
    Appcelerator will discontinue to work on Titanium Desktop and will make it OpenSource. If nobody will work on it, it’ll die.
    The next good platform for writing desktop applications with web technology is to be dying, first Adobe Air with their dropped support for Linux and now Titanium Desktop.
    But this downfall has been visible for month: Titanium Mobile had many new versions and Titanium Desktop has had less new version.
    RIP Titanium Desktop

  5. What is now considered the latest stable version of the Desktop SDK? The last build posted to the master branch of the Continuous Builds site is dated June 17, 2011. The last build posted to the v1.2-Windows branch is dated Nov 23, 2011. If we need to maintain existing Desktop projects, what SDK code should we be using?

  6. @Mark The latest continuous builds for 1.2 would be the best to use in the sense that several critical issues have been addressed since the 1.1 GA.
    My hope for Desktop is to get to a stable first release under the new independent project banner, which would essentially be the 1.2 release of Desktop.

  7. @meech I’m not sure on the packaging server code – I’ll inquire and we’ll take it up on the transition mailing list.

  8. I understand Appcelerators need to shed this weight to be able to focus. Still, it makes me a sad panda. And I think it will take a couple of open source heroes to be able to give Titanium Desktop the necessary boost to jump this hurdle.

  9. I am having one on going Desktop application. So I would like to ask whether I will be able to package my application on my local laptop. I am using 1.2 RC 6 for MAC and 1.1 for windows.

    So, here’s the long and short.
    1) Adobe AIR sucks.
    2) Titanium Desktop is a much better product than Adobe AIR.
    3) With Titanium Desktop support removed, the better product is getting shelved.
    It’s just frustrating that Titanium Desktop is getting hosed when it never was given a full chance to flourish. If it was matched head-to-head with AIR in marketing and updates, it would easily win.
    Plus, I JUST TODAY started changing my AIR app to Titanium, then found this after a few hours work. FUUUUUUUUUUUU

  11. Hello Kevin.
    Thanks a lot for your reply. That guide is only for 1.1 but I am using 1.2 RC 6 on MAC. What about that ? How should package that ? I am using that because of some php script issue I was facing in 1.1 in MAC.

    • @Zero – The build process should not have changed significantly in 1.2 – if I am wrong on this and the existing instructions don’t work, post to the desktop mailing list asking for help.
      @Matthew – I agree, Desktop is in many ways superior to AIR. I would encourage you to join up on the mailing list and keep tabs on Desktop. I think we will find that there’s a lot of interest around the desktop project.

  12. Link to mailing list? Instead of a mailing list, why not a dedicated blog / site just for Desktop? I really think you guys have underestimated not only the product’s appeal, but the developer support, probably because the tools for developers connecting with you have been so poor. Case in point, I’m subscribed to zero mailing lists; I’d rather interact on a website.
    I was all convinced and set to move my project to Titanium, because the performance is about 1000x better than AIR, but now I’m not sure what to do. I don’t want to get on board a sinking ship.
    If there’s a way to contribute to keep this product strong (or actually motivate it to actually reaching a point of solidity for the first time), I’m willing to do what I can, just because there are literally only two products of this nature, and one of them is AIR.

  13. I’m really happy that finally something has moved with Titanium Desktop, even though it’s a bit dissapointing that Appcelerator decided to focus 100% on Mobile version.
    However, I believe that Titanium Desktop as an open-source, community driven project has a bright future. It has become my main development platform and I’m really looking forward to participate in Titanium Desktop development.

  14. Titanium Desktop was already diverging from the mobile stuff. I prefer using standard HTML to the native JavaScript UI, so I hope this means that Titanium Desktop will continue to be based on HTML. In addition, as an open source project, it will be more valuable to me, and I hope to be able to contribute to the codebase when it’s on GitHub!

  15. This is disappointing. There are handful alternatives to mobile development but Titanium Desktop was the dream we were sold to. TiDesktop was the only reason why we invested in buying a Titanium Studio license, and it seems to be going down the drain.
    Certainly not living to your promise of “Titanium makes cross-platform native application development easy.”

  16. Its a shame to see titanium desktop leave the shores of appcelerator. I hope someone in the open source community will take up the banner.

  17. This is really disappointing; the major draw for my development team to Titanium Mobile was that Titanium Desktop was so similarly styled, and both are developed with the same toolsets (the Titanium technologies, Titanium Studio, etc.). The fact that our team would only have to learn one toolset & framework made Titanium Mobile and Desktop so interesting, this move actually lessens the appeal to both.
    Best of luck going forward.

  18. I believe that Appcelerator is making a mistake here. Who in the world get a unique appeling product and dump it as a bag of crap that doens’t deserve to be there, leting a bunch of developers alone.
    Here, where I work, we started with Appcelerator using Ti Desktop and now we have our flagship desktop app made with this. Yesterday I discovered that I can’t build Linux versions anymore and now that.
    How we will be able to issue new versions of our desktop app?
    I trully believe that this is the wrong way to marketing around the Appcelerator/Titanium branch. The only thing I see here is a company that doesn’t care unplug some costumers if they don’t give enough.
    And yes, I’m sad.

  19. We’ll be making the packaging tools available until the end of March, at which point we will open source the tools we use to make packaging available.
    Please hop on the mailing list to stay abreast of the latest discussion and developments.

  20. Developers adopt solutions like TiDesktop, because they promise to do the job quickly without having to learn another language. Now that they stopped development on that product you are pretty much on your own with removing bugs or integrating new versions of WebKit, which practically means that you have to learn C++ and Python!
    But there is an alternative (no, not AIR): You can do your DesktopApp as a Google Chrome Extension. Beside an “Extension UI”, which really extends Chrome itself, you can do a “Packaged app UI”, which is a web-app hosted by Chrome. You can have it as link on your desktop (with your own icon) and it opens in its own window. I use WebSockets to communicate with a WebSocket-Server written in .NET. Such a WebSocketServer is part of .NET 4.5. For lower versions I recommend over Alchemy. Thanks to Mono these solutions should work on all platforms, although I’ve tested Windows only. You can install your web-app as “external extension” together with the .NET-part of your app using an msi. Of course this solution has some disadvantages (user needs to install Chrome first, a firewall may ask for permission,…) but you also get rid of a lot of troubles like outdated WebKit-versions, having no WebSockets at all or bugs that are never fixed…
    By the way: Keep an eye on “Boot to Gecko”. If this approach succeedes Appcelerator is facing big problems.

  21. How would Boot to Gecko _negatively_ effect Titanium studio? From what I can tell it’s just a web browser wrapper. Titanium studio mobile web apps should be easily ran on the platform, albeit they need to implement some of the APIs first.

  22. Titanium Desktop was the only thing that really distinguished this product from PhoneGap, AppMobi, and other similar cross-platform development frameworks… at least for me.
    Desktop was a source of frustration, because this move has been obviously coming for a long time. Mobile got updated regularly and Desktop slowly turned brown and brittle like a neglected houseplant.
    I’m glad you’ve decided to hand it off instead of bury it, but I think you waited too long.

  23. @Thomas: They have started to define an API covering all things a smartphone or tablet may offer. Plans are to do a reference-implementation, but the hope is that Apple and other vendors will adopt it. You already have something similar with Flash, where Adobe has written a runtime that allows to run Flash-apps on mobiles. So Boot-to-Gecko is a platform sitting on top of iOS and Android allowing apps written im HTML5/JavaScript to do all the things normally reserved for native apps. Of course the runtime will be more or less a browser, but with tight integration of the mobile device (phone, camera, GPS, …). I think this is very similar to what Appcelerator offers, but apps are based on a standardized API and are not dependent on an single company. Boot-to-Decko is in a very early state and you can’t tell now if they will achieve their goals.


Please enter your comment!
Please enter your name here