In the Summer '13 release webinar, Ryan Upton and Samantha Ready mention that the Force.com IDE is no longer being supported. During the Q&A time, they both chime in on a question related to the IDE. The question starts at 53:30 and runs to 54:30.

During the answer, Ryan mentions it is deprecated and that the goal is to move everyone onto the Developer Console. As a long term user of Eclipse (coming from a Java background), I just don't see how this is even remotely possible. A true IDE is needed for the platform and discontinuing support for this IDE doesn't seem logical. You lose the ability to do mass refactoring, you lose the ability to store offline files (such as deploy packages, data load scripts, etc), you lose the ability of local file history, you lose the ability to quickly search entire projects, and you lose the ability to easily interact with version control systems. That is all just the tip of the iceberg of all the functionality involved with an IDE.

So, my question is, is there any other documentation stating this is going to be deprecated? Is there any explanation on possible workarounds for these other issues if this is true? Is there anything that states what the long term goals of the Force.com IDE/Developer Console truly are?

  • 12
    I've seen calls to open source the Eclipse integration - Open Source the Force.com IDE. There is a comment in there from Josh Kaplan about the Tooling API providing a means to do this. Aug 19 '13 at 20:46
  • 9
    Totally agree that we still need a full-fledged IDE. I have been using MavensMate with good success on almost all of my projects, although it still has growing pains/remaining issues. Aug 19 '13 at 22:00
  • 8
    News to me. In terms of workarounds, I have been building an IDE (aside.io) that while still web based, has some of the features you are seeking (e.g. search entire org at once, local file history).
    – Phil Rymek
    Aug 19 '13 at 22:03
  • 6
    I asked a similar but more direct question a little while ago: When is the Force.com IDE going to be rewritten Aug 19 '13 at 22:13

As the original author of the IDE, I can understand why you would be unclear on the future of the IDE. Rather than say it has been deprecated I would say that it has been put in maintenance only mode, but IS supported. That is to say, that with each release of the platform, the next being Winter '14, the IDE will be updated so that the API endpoint of the SOAP API used by the IDE is current.

The IDE uses a combination of SOAP and Metadata APIs and to gain access to the most recently exposed metadata, this endpoint update, and re-compiling needs to occur. But, that is the extent of support that we are committing to with the current IDE code base.

The long term strategy is as described above. We have moved resource from adding new features to the IDE to developing an API who sole purpose is to support tooling. You can see the progress of the tooling API in the Developer Console, which is the first place that this API is being put to work. Once the tooling API has reached a level of functionality, we will revisit an Eclipse plugin.

tl;dr The IDE was built by salesforce Developer Evangelism for the reasons that you excellently point out above. It was built before we released a Metadata API even, mostly to gain the usefulness of an IDE, but the main reason was so that the developer had access to the built in source code control, something that is terribly important for real development and governance.

Due to the popularity and adoption by the developer community, the project was "forced" upon the R&D side of the house so that it could be properly supported and maintained. The code behind the IDE has evolved organically and over a lengthy enough period of time that the entire underlying implementation has rightly been called into question. Newer APIs exist that can/will be used in conjunction with the tooling API to deliver a better performing, less chatty IDE. Included in this is something akin to a grammer for proper code assist and refactoring, replacing the current polling mechanism with a streaming API mechanism and a better Visualforce editor.

The Force.com service is unique, so while we can borrow a lot of techniques and approaches, some aspects of this just have needed to be invented. Hopefully this demonstrates our commitment to the IDE and other tools like Mavens Mate and BrainEngine

EDIT: On September 17, 2013 the DeveloperForce blogs came out with the following article. Cliff notes:

  • We will be updating the plugin to work with the latest versions of Eclipse and Java shortly after the Winter ’14 release.
  • We have been finishing up the Tooling API to prepare for the more complete refactoring which is now in flight.

After the refactor:

  • Dynamic Metadata API: No more need to upgrade the plugin every release to get the latest metadata API. Latest and greatest available at all times.
  • oAuth: No more need to reset a security token and update projects with new credentials. oAuth authentication will keep your plugin authenticated to an instance until you tell it you don’t want to be authenticated anymore. Especially useful for those of you with admins requiring monthly password resets.
  • Code Completion: The Tooling API provides symbol tables for an org, which will be used to offer code completion. Developer Console offers this today; rebuilding with the Tooling API will allow the plugin to offer it too.
  • Better Save Process: The Tooling API provides a mechanism for saving code artifacts more directly than the metadata API, providing a much less unwieldy experience.
  • Plugin-only: The current approach of offering a bundled exe to install both Eclipse and the Force.com IDE plugin. We’ll be all plugin, all the time.

EDIT: On July 1st, 2014, the Force.com IDE Core has officially gone open source on GitHub. The community can now help maintain it.

  • 18
    Dave, thanks for chiming in and responding! Personally I find the developer console infuriating for lack of simple features one expects in an IDE, like a deep search across multiple projects, ability to compare files and local history, source control integration, ability to use third party plugins, etc. I really don't get, at this point in adoption, why Salesforce would choose not to fully back the IDE. But failing that, PLEASE open source the Eclipse code ASAP so others can extend it. Holding our breath for a great third party solution (on Windows, at least!) is not a great plan.
    – jkraybill
    Aug 20 '13 at 1:55
  • 9
    Just to follow up on my comment, I decided maybe I was being unfairly harsh on the dev console, since I haven't used it in a while and maybe it's come a long way. So I tried actually using it today for code and unit test development. Nope, it still is incredibly unacceptable and clunky compared to the modern state of the art in development IDE's. I continously got "no response from the server" errors as well. Eclipse is just so much nicer and more responsive an environment. If there is any hope of getting prioritization on any Eclipse-based IDE work, please let us know how!
    – jkraybill
    Aug 21 '13 at 8:01
  • 1
    Note that V28 of the IDE has some known issues - salesforce.stackexchange.com/questions/14020/… forcing some to revert back to V27
    – cropredy
    Aug 22 '13 at 23:10

We actually took a different approach, partially driven by the desire to use a more diverse set of development tools, but primarily to simplify development of multiple managed packages in a single Force.com dev org (per-developer, of course). We create a set of ant targets based on the Force.com Migration Toolkit that do the following:

  • Smart incremental save - "smart" meaning it ensures the package contains all dependencies of modified files as well; also stubs out meta.xml files for locally created source
  • Full save
  • Sync with server - Retrieves metadata, cleans it up (partitions by package removing implicit dependencies, restores unambiguous namespace qualifications that were removed when developing in a single org, etc.), shows a diff against local source in a comparison tool (either Beyond Compare or Araxis Merge), and adds synced files to SCM

We also created ant targets for a VERY simple source code formatter for Apex and a very simple rename refactoring target for Apex classes and custom objects.

These targets can then be easily and pretty seamlessly integrated into other IDEs and editors. For example, I use IntelliJ IDEA pretty much exclusively for Force.com development these days.

I'm also eagerly anticipating the arrival of real IDE plug-ins for Force.com dev, especially for IDEA, but this works great for us until then!

  • 1
    fyi I suggest using mavensmate which will make your development speed faster. It also let you deploy the resource bundle on save so very convenient mavensmate.com Mar 22 '14 at 18:49

Fast forward to 2018 and the IDE landscape has changed a bit with Salesforce DX.

From Summer '17 to Spring '18 there was the Force.com IDE 2 (Beta). This has been discontinued:

The Force.com IDE 2 beta release has been discontinued. We are not providing future releases of this tool, and no downloads are available after May 3, 2018. You cannot access the Force.com IDE 2 Developer Guide as of April 23, 2018. We recommend using Salesforce Extensions for VS Code instead.

The original Force.com IDE is more complex as it is open source on GitHub. I see it was updated to the current (as at the time of writing) Spring '18 WSDLs. Other than that there appears to be no active development over the last year.

Comment from Wade Wegner (VP Product for Salesforce):

We will keep the existing Force.com IDE in OSS (and likely fix any major issues) but we will no longer invest in the Force.com IDE 2. Yes, consider using VS Code with our extensions.

So the current focus is on the Salesforce Extensions for VS Code and support for third party IDEs via the SFDX CLI and existing APIs.

See also:

Not the answer you're looking for? Browse other questions tagged or ask your own question.