Ghostty versus iTerm2 is easy to turn into a feature-list argument. That is not how most developers experience the choice. A terminal is a place where you read build output, keep shells open during interruptions, connect to machines you did not build, and occasionally discover that a tiny preference has become a workflow dependency.
The useful question is not which application wins in the abstract. It is which one leaves the fewest surprises in your actual work. Ghostty is compelling when you want a fast, modern terminal with a deliberately smaller surface area. iTerm2 remains the safer choice when its accumulated Mac-specific features, automation hooks, or compatibility behavior are actively carrying part of your day.
Both can be excellent. The mistake is treating a migration as an identity decision instead of a bounded engineering change.
Start with the responsibilities of a terminal
A terminal emulator should render text clearly, provide local windows and splits, and get out of the way. It should not be the only place where important work lives. That distinction makes the comparison calmer.
| Need | Ghostty is usually a strong fit when | iTerm2 is usually a strong fit when |
|---|---|---|
| Daily local shell work | You want a quick, focused native terminal | You already depend on profile-specific behavior or scripts |
| Remote work | SSH and tmux own the durable state | Existing iTerm2 profiles and integrations are part of the workflow |
| Window management | A simple tab/split model is enough | You use advanced pane arrangements or session restoration intentionally |
| Configuration | You prefer a small text configuration | You prefer its mature preference UI and established ecosystem |
| Compatibility | Your fonts, shell, and tools work cleanly | You need a proven fallback for uncommon terminal behavior |
This is why raw rendering benchmarks are not a purchasing decision. A terminal that is theoretically faster but breaks one established workflow is slower in the only way that matters. Conversely, a terminal with a large feature set is not automatically more productive if most of that surface is configuration you never use.
Why Ghostty feels different
Ghostty is attractive because it makes the terminal feel less like a mini-platform. Its configuration is readable, its rendering is responsive, and the application is opinionated enough that you can spend less time collecting preferences. For a developer who mostly uses a shell, an editor, Git, a few local processes, and SSH, that can be a real improvement.
The tradeoff is that a smaller product surface asks you to keep responsibilities in the right places. Shell aliases belong in the shell. Host identity and transport rules belong in SSH configuration. A long-running deployment log belongs in tmux, a service dashboard, or the system that owns the deployment—not in a particular Mac window.
How To Configure Ghostty For A Productive macOS Development Terminal covers the deliberately boring setup that makes this work: readable type, a restrained theme, and only the shortcuts that survive ordinary use.
Why iTerm2 remains hard to replace
iTerm2 has earned its place in many Mac development environments. It has years of polish around profiles, triggers, shell integration, images and escape sequences, profile-specific behavior, and workflows that teams have quietly standardized around. If you have a profile for a production bastion, a trusted password-manager integration, or scripts that assume iTerm2 behavior, that is not legacy clutter. It is a dependency that deserves inspection.
There is also value in familiar failure modes. When an emulator has been in wide use for years, you are more likely to find a known workaround for an odd SSH, locale, or full-screen application problem. That matters to people supporting older systems, unusual hardware, or a wide range of customer environments.
The downside is not that iTerm2 is bad; it is that its capability makes it easy to put too much state in the terminal. Profiles proliferate. A hotkey solves a one-time irritation and becomes undocumented policy. The application may still be right for you, but it benefits from occasional pruning.
Run a migration test instead of a permanent switch
Do not replace your terminal on the morning you need it most. Install Ghostty alongside iTerm2 and run a small test for one or two weeks. Keep iTerm2 available, then test the things that would actually make you switch back:
- Open the repositories and language toolchains you use every day.
- Run a long test suite and read dense colored output.
- Exercise SSH through your usual jump hosts and VPN.
- Attach to a
tmuxsession after closing the laptop or changing networks. - Use your preferred editor, password manager, and clipboard workflow.
- Screen share a terminal in a meeting and make sure the text remains legible.
Write down failures, not vibes. A missing convenience may be worth adapting to. A broken remote workflow or accessibility problem is a reason to stop. The point of a parallel run is to make that distinction without drama.
Keep the migration cost low
The best terminal configuration is portable because it does not hide the important parts in the emulator. Start by moving durable definitions out:
~/.zshrc # aliases, prompts, shell behavior
~/.ssh/config # hosts, identities, jump rules
~/.config/ghostty/config # terminal rendering and a few keys
~/.tmux.conf # durable session behavior
Then choose one profile or configuration at a time. Recreate readability first: font, size, theme, padding. Recreate only repeated key workflows second. Leave novelty features until you can name the job they do. This is also a good time to delete old profiles whose hostnames no longer exist.
If your terminal work crosses machines regularly, Ghostty, tmux, And SSH: A Terminal Workflow That Survives Context Switching explains the boundary that makes either emulator easier to replace.
Make the decision on maintenance, not fashion
Choose Ghostty if a focused configuration, responsive rendering, and a clean separation between terminal, shell, and remote session make your ordinary work easier. Choose iTerm2 if its profiles, integrations, or compatibility support real tasks that you would otherwise need to rebuild. Keep both during the transition if that lowers risk.
There is no medal for using the newer terminal or the more configurable one. The right terminal is the one whose behavior you understand, whose state can survive a context switch, and whose setup you can reproduce on the next Mac. For more practical engineering workflow notes, return to Slaptijack.