Introducing the VS Code Extension

It’s been a little over a year since we released the Titanium Package for Atom, and we are delighted by such great response shown by both the usage stats and external contributions we’ve received.

However, Atom isn’t the only editor around today. Visual Studio Code has grown tremendously in usage over the last year, nearly doubling in usage in the State of JS survey.

Continuing on from the Atom package, we’re excited to announce an initial preview for Titanium support in Visual Studio Code via the vscode-titanium extension.

You can download the extension from the Visual Studio Marketplace here.

What’s next?

We’ll be releasing a 1.0.0 of the extension as soon as we feel that it’s ready and are aiming to share as much functionality between both the Atom package and VS Code extension to have both projects progress at the same rate.

Once released, we have a loose roadmap of features we’d like to build into the two, including:

  • Allow usage of Titanium/Alloy CLIs in place of Appcelerator CLI
  • Improve management of SDK/CLIs. Alerting when new versions are released
  • Improve support for classic applications, as well as apps using the Vue or Angular plugins
  • Continue to improve autocomplete/intellisense capabilities

We hope that you enjoy the extension! If you have any questions, please join us over in #titanium_editors in TiSlack.

For any bugs or feature requests, please file an issue in the GitHub repository.

Code strong! ?

Previous articleMoving towards digital modernization with Axway
Next articlePing Identity and Axway webinar wrap-up: API security challenges and solutions


  1. Very impressive for 0.1.1 version.
    To build the distribution for iOS, it doesn’t ask for certificate or provision file like Atom, it just uses the default?

  2. It would be great if they supported debugging outside of Appcelerator Studio. Studio hangs a lot, has a lot of bugs (sometimes, the emulator device list does not even appear), and even when debugging works, it allows only a limited number of breakpoints per debugging session. We have an app that runs a series of one time commands at startup, they are conditioned to run inside try/catch blocks so they can run once even if they fail in future sessions. However, the debugger stops at each one, and thus, reaches the breakpoint limit before we can actually get to where the actual breakpoint is. This makes debugging with Studio very difficult, if not impossible.


Please enter your comment!
Please enter your name here