First time I tried it, I realised there is no way to have a terminal emulator panel. A bloody terminal. Like the most basic feature you could integrate into an IDE. No thank you.

I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE. There's a perfectly good terminal emulator called Terminal.app, it's usually the first thing I put on my dock after a fresh install of MacOS. I like the terminal, but ... in an IDE ? I always wondered why Eclipse had one as well - it just seems like a wasted pane ?

Perhaps it's just the setup you (the generic "you") are used to or something. I've got 3 4k screens connected to a Mac Studio here, and plenty of space for a terminal or four to be running on-screen at the same time and in windows that don't obscure the things I want to look at. I guess if you code on an MBP and space is limited, it might be easier to switch to ? But I generally want that space for my debugger and console-app i/o. I think it'd just get in the way...

I use the built-in terminal "panel" inside VS Code/Cursor all the time. It's next to some other useful tab panels. Great for when you need to run commands for the current project but still want to chat in the sidebar or edit something else while it runs.

Sometimes I'll use Ghostty at the same time and switch between the two. Just depends on what I'm trying to do at the moment.

Nothing wrong with maintaining all the context you need in a single window instead of alt+tabbing to different apps, especially for those not engulfed by three 4K displays.

Because I like to get project-aware completions, or run pre-configured tools from the IDE in an actual shell, for example.

Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at.

Can you give specific examples ? About the only thing I use the terminal for in Xcode is "git" - and even then these days I tend to use Fork.app for that.

Debugging is integrated, profiling is integrated, script-running as part of the build is integrated. Application output is integrated. What do you actually use it for ? Genuine question.

I guess the AI tools might be something - I don't know about that, I don't use them.

I work a lot with frameworks or languages that bring their own script runner or CLI companion to execute various tasks during development; quality checks or formatters, auxiliary tools like the Stripe webhook proxy, or interactive ones like a psql session into the database or a docker compose log stream; some of them longer-running, others single-shot executables.

Depending on what I'm doing, I need these processes either run alongside the project while I'm working on it (like watching source files), execute them automatically when something happens (like setting up a Stripe webhook proxy when I start the debug build), start them with environment configuration from the IDE (for example a database console), or really just have them close to the code (like a linter).

IntelliJ has a task runner built-in that can do all of this very easily, in a way that I can share it with the rest of my team, and don't have to bother with remembering specific commands.

Good answer. I guess we work in slightly different realms :)

I've set up tasks to run at build-time in Xcode - the 'Build Phases' tab can add tasks to be run automatically, which are just shell-scripts and Xcode sets up just about every variable under the sun for you in the environment, so you can navigate to the right directory, add the current-target as part of a name etc. They're saved as part of the project so everyone gets them.

But that doesn't cope with the interactive side of what you're talking about. In truth, I've always just done that from the command line 'pqsl -d <database>' (or 'sqlite3 database') has always been sufficient - though if your interactive session shares the database context that the application is also using (so you're not waiting for a flush to get updates) that would be interesting.

Quality checking I tend to integrate with git rather than the IDE, setting up a hook on pre-commit to run unit tests and so on. In a previous life different teams used different IDEs, but we always wanted the tests to run :)

> I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE

I assumed it came from Windows users who have a habit of running everything in full-screen.

I'm sitting here wondering why you'd run anything not full-screened, save for some rare situation where you are comparing multiple windows line by line (and don't have a short term memory).

I don't often run things full-screen. I like windows, they give you virtual screen real-estate at the click of a mouse.

Example: Right now I have a project with a main application, a launch agent, and a framework. I can fit 3 columns of text with the font at a size I can easily read across one window in Xcode. I generally work for a period of time in one of the app/agent/framework areas, so I have 3 Xcode windows open on the same project, each having ~90% of the screen with a little overlap.

Sometimes I'll have another similar window, for out-of-context work. If I'm creating a class, and suddenly realise I want to re-factor some other class to make it work, I'll open another window (again with the 3 columns) for the re-factor work, leaving the state of where I was ready to come back to at the click of a mouse.

I personally find it easier to mouse-click to change context than any other way, so keeping the screen 'mostly' used works better for me.

I used to use terminal windows separate from my editor. Now I use VSCode, I have 6 different but related projects open. In VSCode this means 6 windows, each with multiple tabs etc. In each of those are 1 to 3 terminal editor windows. That means when I switch to that project, shells related to that project come with it. No having to hunt through 6 to 18 terminal windows to find the correct one(s)

Turns out, for me, the terminal emulator embedded in the IDE has been a big plus.

I'm not commenting on other IDEs - I honestly wouldn't say I was really even familiar with VSCode, I've generally only used it from time to time when doing embedded stuff.

The original comment was aimed at Xcode though, and it's in that context that I'm (still) struggling to see why you need a terminal.

I come from Linux land so I'm used to things being lightning fast, so using software on a Mac requires a thousand workarounds. A terminal integrated into the IDE is one of those necessary workarounds.

MacOS has very very slow slow window- and desktop- switching (over one FULL second to switch from one desktop to another - this is not a joke!) so having a terminal integrated into the same application is very useful for maintaining flow for users developing on a single-screen Macbook.

It shouldn't take over a second to switch desktops.

I just checked with a screen recording. Switching desktops takes 15 frames (250 ms). If you turn reduce motion on, it takes 13 frames (216 ms).

It depends which key combination or trackpad gesture is used to trigger the desktop switch, because they use different animation curvdes. It looks like they have different application focus or redraw behaviour too.

- Control-Left/Right takes about 1 second.

- Four-finger swipe left/right takes about 1 second.

- Alt-Tab to an app on another desktop takes about 0.25 seconds.

I'm using Sonoma 14.8.3, but from the comments it sounds like the timing distinction is similar on other versions.

The 1200ms was an estimation, but it's definitely closer to 1200ms than it is for 250ms for me. There's definitely a difference in set up here- I'm on a Macbook Pro with an M1 Pro chip.

From a screen recording, I count 53 screen-recorded frames from the apparent start of the animation (which occurs after it's invoked) to desktop widgets becoming transparent (which appears to be the point input is no longer blocked). IINA says the video is 50.582 fps (very strange frame rate?) so that would be ~1050ms.

Of course, that doesn't include any input latency or the display latency, so I also took a video with my phone. I took two trials and I recorded a full 1.08 seconds from key depression to transparent widgets. I did two more with Reduce Motion on and got the exact same time.

I am very curious what your set up is, because I am invested in getting this as close to 8.3 ms as possible.

edit: For comparison, my Linux desktop with a similar experimental set up, this takes about 24ms from key depression to the next desktop becoming visible. The only experimental difference is that I had to switch to the "slow mo" camera to record the difference, and I have a 240hz monitor. The desktop is also considered one of the slower ones (GNOME).

TLDR: It takes 1.08 seconds, on my Macbook, to complete a desktop transition.

I'm also on a M1 Macbook Pro, running Tahoe 26.2.

Not sure why yours is so much slower than mine. Mine is definitely 250 ms long or 15 frames from the time I hit the shortcut.

I used the onscreen keyboard viewer to get visual feedback when the shortcut was pressed and recorded audio so I could hear it being pressed. I even recorded it a second time using OBS to ensure I was at 60 fps and trimmed the whole segment down to just the animation and sure enough, the video is exactly 250 ms long according to IINA.

Also, I don't have any visible delay between pressing the key and the animation starting. The animation starts on the same frame as when the shortcut is recognized by the onscreen keyboard viewer (which is the same time as I hear it being pressed) in the recording. The keyboard delay must be < 16.6 ms.

You might not be aware of this, but you are in possession of a secret treasure that many MacOS users desperately want!

There is some input display on Macbook Pros, but that'd account for easily <100ms of the difference we're seeing (I'm holding `control` and measuring from depression of the arrow key).

I tried changing screen resolution, quitting apps like Rectangle, etc. No dice.

In digging more deeply than I had before, I did find some things which were rumored to speed it up. Disabling multi-color preview, and disabling "displays have separate spaces". (I am using only one display). This shaves off some time (taking about 950ms)! (!!!)

There is also a four-finger gesture which, if done fast enough, appears to speed things up. But it's difficult to reproduce and often "overshoots" to other spaces.

I have a few questions, if you'd oblige:

- Are you also using ProMotion (120hz)? (The biggest thing I can find to speed this up is switching to 60hz, but this does not quite get to 250ms).

- Are you also switching using ctrl+arrowkey(left/right)? (Ctrl+number is notably faster, but not what I'm looking for.)

- Were you using MacOS before this M1 Pro? (This is my first MacOS machine, I'm wondering if there might be some hidden configuration carried over from a previous install with faster transitions).

I am hitting ⌃1 or ⌃2 to switch between desktops, not ctrl-arrow.

When reduce motion is turned on in the control panel though, the ctrl-arrow and ctrl-# animations take the same time on my machine (216.6 ms)

I'm doing the same thing you are, holding control and measuring from when I tap the next key.

No ProMotion and only using the internal display. I was running other Macs before this, so there is a chance some configuration crossed over.

Agree. I hate the fullscreen animation so I prefer apps that have a non-native and no animation option such as Ghosty.

I guess I’m not seeing what you’re seeing. I don’t often switch desktops - I tend to keep a project on a desktop, and there’s enough real-estate for everything I need for that project right there - and I don’t work on more than one project at a time.

Window switching is instantaneous though, and I do that a lot

As you said, it's the set up. I'm almost exclusively using a single monitor, which works well when there's zero cost to switching desktops.

For your use case, imagine if the Window switcher, instead of being instantaneous, was a ~1200ms animation which blocked all key presses during the animation.

Mm. On the Studio, my desktop switching is pretty quick - 17 frames from tapping the ctrl/arrow. I have an M4 Max which is actually 1 frame faster at 16 frames (though measurement-error probably accounts for that).

In either case that's less than 1/3 of a second. It's nowhere near what you're seeing. I'd be tempted to take the machine to an Apple Store and say "this is broken, please fix it".

What frame rate are you using on those monitors? I ask because this is faster at lower frame rates. This is surprising and I very much want what you have.

Are you using software like Rectangle, Better Touch Tool, etc?

Even with IDEs that have a terminal view, I still much prefer using a separate terminal app.

Same. Standalone terminals will always beat those built into other things in terms of being good at being a terminal. No need to pile more bloat onto an already bloated IDE/editor, and besides it feels kind of like those old combo TV+VCR units where neither the CRT tube nor the VHS player were great.

If I'd do anything to Xcode or Android Studio, it'd be to split more things out of them and make them excellent at their core tasks.

Why? It seems pretty pointless to keep hot memory of the context of every app and tab you have open as to recall what process and tab and window ties to what thing you were doing at what time, when it's effectively all one related workflow inside your Integrated* Development Environment. Do you just keep a separate dedicated tab in your terminal for actions you would only do against a single directory?

My machine has more memory than I generally know what to do with. The mapped-into-memory footprint of Terminal.app right now is ~112MB, for 12 terminal tabs across 4 windows.

In other words, I don't care about the memory use.

I think I commented earlier that there's not that much I use the terminal for during development - mainly git. Keeping a terminal open, mainly hidden, in the bottom-left corner with the tab set to the top-level directory isn't really a burden.

I do the same - largely because I open the IDE with `idea .`/`zed .` (or whatever) from a directory with the correct nix dev shell already loaded in order to ensure the correct toolchains get used.

Typically I have 3-4 different projects open at a time and probably 30-40 terminal windows across them and other places (in Ghostty).

Honestly it had never really crossed my mind that people used the built-in terminal for anything!

Ha ha! You sound like a vi users asking an emacs user why the hell you need a shell window in emacs!

This is a standard feature in every IDE that’s ever been invented. It’s not useful for every workflow, but there’s lots of times that you’re doing something where the console or the debugger is not available or isn’t convenient and being able to have a terminal right there is so useful. If it doesn’t make sense for your workflow, then don’t bring it up, but given how many developers expect us as table stakes it’s a deeply baffling omission.

> This is a standard feature in every IDE that’s ever been invented.

You should be careful making such statements to an audience in which many have been around when IDEs were invented.

It's certainly a useful thing to have, and yes, these days many IDEs do have it. But Xcode itself is from the time long before that feature became the default. And, unfortunately, it is mostly still stuck there.

I’d like to argue for a case against having terminals inside an IDE:

when your IDE crashes (inevitably), you lose the entire console context and all running processes within it. There is also no way to detach the terminal from the IDE, say when the IDE needs to be updated (constantly).

IDE terminals also tend to be buggy.

Bold take. This hasn't been my experience.

> [an integrated terminal] is a standard feature in every IDE that’s ever been invented

I invite you to back up your claim by researching the following (as a starting point).

Visual Studio, Visual Studio Code, VSCodium, IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, CLion, GoLand, Rider, RubyMine, DataGrip, AppCode, RustRover, DataSpell, JetBrains Fleet, JetBrains Air, JetBrains MPS, Eclipse, NetBeans, Xcode, Android Studio, Sublime Text, Emacs, Spacemacs, Vim, Neovim, Theia, Code::Blocks, Dev-C++, Neil deGrasse Tyson’s Seemingly Limitless Trove of Knowledge, Turbo C++, Borland Delphi, RAD Studio, Lazarus, Qt Creator, KDevelop, Anjuta, GNOME Builder, MonoDevelop, SharpDevelop, BlueJ, Greenfoot, DrJava, Son of DrJava, Evil Bizarro Son of DrJava, jGRASP, Barely Beyond Your jGrasp, JDeveloper, JBuilder, JCreator, Aptana Studio, Komodo IDE, Komodo Edit, Geany, Light Table (may it rest in peace), Brackets, Zed, Cursor, Windsurf, Trae, Google Antigravity, Void, VoidedBowels, Kiro, Qoder, Cline, OpenCode, Spyder, IDLE, Thonny, Wing IDE, Eric, PyDev, PyScripter, Pyzo, Jupyter, RStudio, Zasper, MATLAB IDE, Scilab, Octave GUI, LabVIEW, Arduino IDE, PlatformIO, MPLAB X, Keil µVision, IAR Embedded Workbench, Atmel Studio, Other FPGA Tooling That No One Has Heard Of, Microchip Studio, Code Composer Studio, STM32CubeIDE, Segger Embedded Studio, AvalonStudio, ElectronIDE, Replit, Gitpod, GitHub Codespaces, AWS Cloud9, Google Cloud Shell Editor, Firebase Studio, Codenvy, Eclipse Che, CodeSandbox, StackBlitz, Glitch, If you have read this far, I am very impressed, Codeanywhere, CodeTasty, CodeTasty+, CodeTasty++, SourceLair, JSFiddle, CodePen, JDoodle, ShiftEdit, AppJet, PowerShell ISE, Embarcadero C++Builder, some IDE that I began coding 10 years ago but never finished, PureBasic IDE, GameMaker Studio, Unity, Unreal Editor, Godot, Redot Engine, Construct, RPG Maker, Defold, CryEngine, Roblox Studio, Stride, Open 3D Engine, HaxeDevelop, FlashDevelop, Leksah, Pharo, Squeak, DrRacket, LispWorks, Allegro CL, SLIME, some IDE invented inside some company you’ve never heard of, CIDER, Calva, Cursive, Smalltalk/X, Visual Works, IBM Rational Application Developer, IBM Rational Software Architect, SAP ABAP Workbench, Oracle SQL Developer, Toad, DBeaver, HeidiSQL, pgAdmin, SQL Server Management Studio, Xojo, LiveCode, HCL Domino Designer, Clarion, Progress OpenEdge, 4D, FileMaker, OutSystems, Mendix, Salesforce Developer Console, placeholder for some truly hideous Semantic Web monstrosity, Oracle APEX, Oracle Forms Builder, some random side project that Stephen Wolfram commissioned an intern to build, PowerBuilder, WinDev, PrimalScript, SlickEdit, UltraEdit, CodeLite, Source Insight, Pelles C, Open Watcom IDE, LiteIDE, Nova, BBEdit, TextMate (not everything in this list is actually an IDE, apparently), CotEditor, CodeWarrior, Turbo Pascal, Borland C++, Visual Age, Visual Cafe, Forte for Java, Sun ONE Studio, Zeus IDE, SciTE, Programmer’s Notepad, Ultimate++, Cevelop, Zinjai, JCppEdit, WeBuilder, Bluefish, CudaText, Kate, gedit, Notepad++, PSPad, EmEditor, Textadept, Leafpad, Graviton, Lite XL, Lapce, Helix, Micro, Cosmic IDE, Squircle IDE, CppDroid, Pydroid 3, Squiggle, SapphireSteel, Codelobster, CodeWright, The Reverend Thomas Bayes’s Glorious Probabilistic Workspace, CSPro, Adobe ColdFusion Builder, yikes that last one gives me nightmares, Adobe Flash Builder, Basic4ppc, BlackBox Component Builder, Bricx Command Center, CA-Telon, Maestro I, Absoft, ANTLR Studio, Apple Dylan, Stardraw, DbVisualizer, Mule IDE, v0, Coder, Data Display Debugger, Softbench, Visual Basic IDE, Dartmouth BASIC IDE, Athas, Fresh Editor, PlayCode, MyEclipse

(Thanks Claude, once again you have been more helpful than a human, which is more than a little concerning.)

I don’t know if all of these are real or qualify as IDE’s, but I hope I’ve made my point: it turns out using the word “every” is a broad and bold claim.

And please don’t simply backpedal and say that you meant “most” unless you’ve actually done the research.

I'll use both depending. Things which benefit from staying in the window context in the IDE window I use the IDE one, things which don't as much or are only tangentially related in an iTerm2/Terminal/Foot window (depending on the platform I'm on).

I expect others do things differently for different reasons as much as much as I expect an IDE to support more than one type of user.

Alright, how about the customization features to add a terminal? Those are missing too.

> I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE

This is the dumbest response anyone can ever have to being presented with the answer to their own question of "what's wrong".

Ok you don't think this is important but your customer (or whatever) just to told you it's important to them. Surprise surprise this is literally why xcode sucks (because Apple seeks to dictate instead of accommodating).

shrug I don't have customers, or whatevers. I've been using Xcode for over 20 years. In all that time, it's been denigrated and put down as rubbish, meanwhile I've found it to be pretty darn good.

Perhaps I'm doing something wrong, but whatever it is, it works for me. I still don't see any advantage to putting a second-rate (they're never as good as the real thing) terminal into an IDE. Someone mentioned project-specific completions, but I can't say I've ever needed the terminal to do that, and I generally don't run IDE-specific tools (also mentioned) from the terminal either.

Maybe my natural workflow gels better with how Apple envisioned people using the IDE, perhaps I happen to be on the "golden path", but ... again shrug. Works for me.

> A bloody terminal. Like the most basic feature...

Since when terminal is "the most basic feature"?

Reading threads in HN and seeing mild "wars" how Kitty/Alacritty/Ghostty/iTerm/Konsole/you-name-it are worse/better than Kitty/Alacritty/Ghostty/iTerm/Konsole/you-name-it, because they are slower/faster, (in)compatible with some ancient niche protocols/standards, etc.

Does not seem that basic to me?

Also it's personal preference, but I somehow used to have my editors and my terminals separate. I guess something about having a tool that does one thing best and all.

No. It. Doesn't.

The whole conversation came from someone claiming the most basic feature of an IDE is to include a terminal - that's why people are discussing terminals.

Don't get me wrong, I live in the terminal when using the computer, but I don't see a need for one when using Xcode.

Call it a task runner shell, if you like. What makes a development environment integrated, if not the ability to launch and manage external processes?

To me, integrated means it integrates a bunch of tasks that used to be separate. I used to have a text-editor, a Makefile to use with 'make', a command line debugger, a static-analyser, and a profile target in that Makefile that I could use to figure out where my code was slow, using another command line tool.

All of that is in Xcode (and a hell of a lot more besides). That makes it integrated, at least IMHO.

You commented above, and I replied, about some of the tasks you use an integrated terminal for, and I'm not trying to say you shouldn't or that that's not useful to you - you obviously know your own workflows and what works best for you :) I just don't see it as "the most basic feature you could integrate into an IDE" (which was the original claim).

I'd probably put 'text editor' up as the most basic, closely followed by compiler integration and then debugger. Static analysis would probably come next, then unit-testing support, doc-comments, and tools like refactoring, good multi-file search/replace etc.

A terminal app is way, way down the list. For me. I realise everyone is different and YMMV :)

English is not my first language, but do you mean "foundational" instead of "basic"?

By your logic (that many people discuss) web browsers are "basic", IDEs are "basic", programming languages are the most "basic" thing (how many of them! discussions are limitless!!).

EDIT: have the gut to explain yourself instead of downvoting ;) , I am not discussing in bad faith , but you do you.

Oh you're why they add that. I just use a dedicated app. What's the benefit of putting it in the same window as the editor?

Replied on a sibling too, but:

> Because I like to get project-aware completions, or run pre-configured tools from the IDE in an actual shell, for example. > Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at.

Window switching is bad enough on MacOS, especially if you have multiple projects open at the same time.

I like that you can have multiple projects open and keep the terminals contextual. Pretty small feature but it can be nice.

...were built-in Terminal emulators even particularly common before VS Code? I remember that being a major feature of VS Code early on.

I think there was a term you could install in sublime