Visual Studio for Mac


Hooray, VS for macOS!

Wait… what?.. no C++ support (yet)




As was said in the ycombinator comments, it’s just a rebranded Xamarin Studio… :frowning:

I had the same positive reaction too, but immediately became skeptical when I noticed the UI looks nothing like VS on Windows (because in reality it’s not even close.

The big competitor sneaking up is actually the C++ plugin for Visual Studio Code, which is shaping up to be a nice cross-platform IDE.


Yeah, Visual Studio Code is quite interesting for cross platform C++ development. Just a note for people not familiar with VS Code: The C++ plugin is in active development. To be able to get the latest version, use “Visual Studio Code Insiders” from

About Visual Studio for Mac: It’s based on MonoDevelop / Xamarin Studio, but they added code from the regular Visual Studio for .NET, ASP etc. as components to it. The regular VS is probably not portable to another OS at all.


Anybody actually using VS Code on OSX with JUCE projects? Xcode’s C++ indexer makes me want to bang my head on the wall right about now.


I write my source code with NeoVim/iTerm2 and VS Code (with the Vim and the C/C++ plugins). For compiling, debugging & profiling I still use Xcode 9. Gave CLion a try last week, but with my current project there is a linker issue with CLion I couldn’t get rid of.


I have been using VS Code for about 6 months for my day job (front end web dev), and am trying it out for Juce/C++ projects. Until now I have been using Xcode, but I am so used to VS Code that it is a pain switching back and forth.

I have been using the C/C++ plugin for vscode mentioned above. Seems good to me, but I’m not very experienced with C++ so I’m afraid I can’t give a detailed comparison with Xcode.

The C/C++ plugin required some minor configuration to let it find Juce’s modules, so that Intellisense works, as described here:

I have also configured a build task as described here: It uses xcodebuild on the command line, which is equivalent to compiling from the Xcode application. This lets you compile without leaving VS Code :slight_smile:

Unfortunately xcodebuild’s build times are much slower than Xcode’s, and I don’t know why. For example, if I make a minor code change then the project will recompile in Xcode in a second or two, but xcodebuild seems to do a full recompile, which takes 20-30 seconds. For now I will keep using Xcode for compiling :frowning:

UPDATE: xcodebuild was only slow because I was compiling the Release configuration. Compiling the Debug configuration is fast.

Here is an example VS Code build task:

    "version": "2.0.0",
    "tasks": [
            "label": "build Debug",
            "type": "shell",
            "command": "xcodebuild",
            // note that I set a SYMROOT that matches xcode's default derived data path,
            // otherwise it will put its temporary build files in the project directory.
            // I want xcodebuild to use the same path as xcode. This is optional.
            "args": [
                "-project", "/path/to/your/project.xcodeproj", "-alltargets", "-configuration", "Debug", "SYMROOT=~/Library/Developer/Xcode/DerivedData"
            "group": {
                "kind": "build",
                "isDefault": true


Update #2: I have gotten debugging working too.

Sorry for turning this into a VS Code thread. I know the original post was about Visual Studio not Visual Studio Code, but this seemed to be the most active forum thread about VS Code so I’m doing my brain dump here!

The basic instructions for configuring C++ debugging are here:

And here is an example launch.json that will launch Reaper as the host for debugging your C++ plugin:

    "version": "0.2.0",
    "configurations": [
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/Applications/",
            "args": [],
            "stopAtEntry": false,
            "cwd": "/Applications/",
            "environment": [],
            "externalConsole": true,
            "MIMode": "lldb",
            "preLaunchTask": "build Debug"

Everything in there was auto-generated except the “program” and “cwd” paths. It took me a while to get this working because the “program” path doesn’t actually point at the, it needs to point at an executable file inside the .app package.

I also added a “preLaunchTask”, which matches the name of the build task I made earlier. This tells VS Code to compile the plugin before launching the debugger.

With that done you can debug as you would in Xcode, using VS Code breakpoints etc.

One gotcha: The debugger will launch an external Terminal window, which is where your debugging output will be displayed. For instance any std::cout calls in your plugin will print to that window. However, in my case the window launched behind VS Code, and went completely unnoticed! (That’s an hour of my life I’m never getting back).

Some of this stuff probably seems basic to anyone familiar with VS Code or Xcode debugging, but hopefully it helps greenhorns like me!


What happens if you set "externalConsole": false ?


I filed an issue about this some time back. As far as I am aware there is no way to have an integrated debugger console in VS code. Setting ‘externalConsole: false’ doesn’t seem to do the trick. It’s a real pain and probably one of the main reasons I don’t use this editor for my JUCE work.


It completely borks Reaper! Reaper throws a bunch of errors when the debugger launches, and then crashes. In the Applications directory a bunch of Reaper settings files get created, and next time you launch Reaper it thinks it is a fresh install and all your custom settings are lost. Thankfully deleting the rogue files from the Applications directory gets things back to normal.

The lack of an integrated console is really odd, isn’t it? VS Code has a console window, which debuggers for other languages hook into AFAIK. Hopefully it’s on the roadmap.


Hi, thank you for this thread and the nice working configuration examples.

for using the internal debug console, I added the following line to the debug configuration (launch.json):

"internalConsoleOptions": "openOnSessionStart",

additionally, I did suppressed the externalConsole as discussed above (no problem with my JUCE GUI application):

"externalConsole": false,

and I stopped logging all the module loads by adding

"logging": {
     "moduleLoad": false

now the debugging fun starts! :wink: