macOS for Linux and Windows Switchers

There is a specific kind of frustration that comes from switching to macOS after years on Linux or Windows. It is not the frustration of incompetence — you know how computers work. It is the frustration of a system that insists on doing familiar things in unfamiliar ways, without explanation, and with an air of certainty that its way is better. The maximize button does not maximize. The Ctrl key does not do what you expect. Cut-and-paste for files does not work the way you think. The file system layout looks wrong.

That friction is real, and anyone who tells you the transition is seamless either has never used a serious Linux or Windows setup or has forgotten what it was like. But here is what I can tell you after going through it: the macOS mental model is internally consistent and, once absorbed, genuinely good for a specific kind of work. The adjustment period is measured in weeks, not months. This guide is meant to compress that adjustment period by explaining the why behind every friction point, not just the how.

We will cover the mental model shift, keyboard remapping, launcher tools, window management, filesystem differences, developer environment setup, terminal options, and the ten most common frustrations new switchers encounter — with direct solutions for each.

The Mental Model Shift: Application-Centric vs Window-Centric

The single biggest conceptual difference between macOS and every other mainstream desktop operating system is this: macOS is application-centric, not window-centric.

On Windows, the fundamental unit of the desktop is the window. Close all windows for an application and the application is gone. The taskbar is a list of open windows. Alt+Tab cycles through windows. If you open Notepad and close the Notepad window, Notepad is done.

On Linux with most window managers — GNOME, KDE, i3, whatever — the story is similar. Windows are the things you manage. Even if the WM has workspace or application concepts, closing windows is effectively closing applications.

macOS works differently at a fundamental level. Applications persist even when they have no windows open. Close every Chrome window and Chrome is still running — its icon has a dot under it in the Dock, its menus are still in the menu bar, and Cmd+Tab still shows it. To actually quit an application, you must press Cmd+Q, not Cmd+W. Cmd+W closes the current window. Cmd+Q quits the application. Many switchers spend their first weeks accidentally piling up dozens of running applications because they have been closing windows and thinking they were quitting apps.

Window-centric model (Windows/Linux WMs):
  [App Window A] [App Window B] [App Window C]
         |               |               |
  Close window  =  Close window  =  Close window
  (app quits)      (app quits)      (app quits)

Application-centric model (macOS):
  [Application A]   [Application B]   [Application C]
       |                  |                  |
  [Window 1]         [Window 1]         (no windows)
  [Window 2]         [Window 2]             |
       |                  |          (still running,
  Cmd+W closes       Cmd+W closes    menus still active)
  the window         the window
       |
  Cmd+Q quits the entire application

Once you understand this, the rest of macOS starts making sense. The Dock is not a taskbar — it is a persistent launcher that also shows what is currently running. A dot under a Dock icon means the application is running. No dot means it is not. Applications you use frequently can be pinned to the Dock regardless of whether they are running; applications that are currently running but not pinned appear on the right side of the Dock temporarily.

The menu bar is the other piece of this puzzle. On Windows and Linux, application menus live inside the application window. On macOS, the menu bar at the top of the screen is always the menu bar for whichever application currently has focus. Click on another application and the menu bar changes. This sounds disorienting — and for the first week it is — but it means the menu bar is always in the same place on a large screen, you never hunt for it inside a window, and you can reach it reliably with the keyboard.

Native fullscreen creates a new Space. This is the other major surprise. When you press the green maximize button on a macOS window or press Ctrl+Cmd+F, you do not get a window that fills the screen. You get the application occupying an entirely new virtual desktop (a “Space” in macOS terminology), and macOS animates a transition to it. This has two implications: first, you cannot see other windows behind a fullscreened app the way you can in Windows; second, you can swipe between Spaces with three fingers on the trackpad. Many switchers immediately hate this behavior. The solution for most is to avoid the green button for maximizing and use a window management tool (covered in the window management section) to fill the screen without going fullscreen.

Why the application-centric model is actually better for certain workflows: once internalized, it means your application state persists across window operations. A terminal application with no visible windows still has all its environment, history, and processes intact. A notes app with no open window is still running and can respond to a global hotkey to pop up a new note. The model maps well to “I am working on several projects simultaneously and I want each tool to maintain its state.” It maps poorly to “I want everything to disappear when I close it.” Both models have valid use cases; macOS chose one and committed to it.

Keyboard Remapping Essentials

macOS has four modifier keys: Control, Option (labeled “Alt” on most keyboards), Command (the clover/Cmd symbol), and Shift. Understanding their roles is essential and takes about a week to fully internalize.

Physical keyboard layout (Apple keyboard, left side):
+----------+----------+----------+----------+
|   fn     | Control  | Option   | Command  |
|          |   (^)    |   (⌥)   |   (⌘)   |
+----------+----------+----------+----------+

Physical keyboard layout (Apple keyboard, right side):
+----------+----------+
| Command  | Option   |
|   (⌘)   |   (⌥)   |
+----------+----------+

Command is your new Ctrl for application shortcuts. This is the biggest adjustment for Linux and Windows users. The shortcuts you have used for decades are almost all there, just with Cmd instead of Ctrl:

This table deserves to be printed and taped to your monitor for the first two weeks. The Cmd+, shortcut for application preferences is especially useful — nearly every well-behaved macOS application respects it.

The Control key on macOS still exists but is used for different purposes: it controls the shell (Ctrl+C to interrupt, Ctrl+D for EOF), it is used in Emacs-style navigation in text fields (Ctrl+A for beginning of line, Ctrl+E for end of line — these work everywhere in macOS, not just in Emacs), and it is part of some system shortcuts like Ctrl+Up for Mission Control.

Option is the power key. Linux power users who miss their Alt key should learn what Option does, because it is often more useful. Hold Option and click a menu item to reveal hidden or alternative actions. Option+Delete deletes the entire word to the left (word-by-word deletion rather than character-by-character). Option+Left/Right arrow jumps by word in text fields. Option+Shift+Left/Right selects by word. In many applications, Option reveals additional toolbar buttons or changes the behavior of visible buttons. In the Finder, Option+drag copies instead of moves. Hold Option while clicking the Wi-Fi, Bluetooth, or battery icons in the menu bar to get diagnostic information.

The function row defaults to media controls on Apple keyboards. F1/F2 control brightness, F3 is Mission Control, F4 is Launchpad, F7/F8/F9 are media controls, F10/F11/F12 are volume. To send actual F-key codes to applications (which you need for vim, terminal emulators, and many developer tools), hold the fn key. You can invert this behavior in System Settings → Keyboard → Keyboard → “Use F1, F2, etc. keys as standard function keys” — which most developers should do immediately, since reaching for fn every time you want to use F-key bindings in your editor becomes exhausting.

Remap Caps Lock immediately. This is possibly the most widely recommended macOS tip among developers, and it is correct. Caps Lock is a large key in valuable real estate and you probably use it approximately never for its intended purpose. Go to System Settings → Keyboard → Keyboard Shortcuts → Modifier Keys and remap it to:

• Escape if you use vim or neovim heavily (makes the escape key reachable without leaving the home row)
• Control if you use Emacs, terminal multiplexers, or any tool with heavy Ctrl usage

Many people remap Caps Lock to both Escape and Control simultaneously — tap it for Escape, hold it as Control. macOS does not natively support this dual mapping, but Karabiner-Elements does, and the “Caps Lock to Escape/Control” complex modification is one of the most installed configurations in the Karabiner community.

Karabiner-Elements is the nuclear option for keyboard remapping. It operates at the kernel level, supports complex conditional rules, and can do essentially anything: remap keys, create hyper keys (using all four modifiers simultaneously as a single modifier), remap the Touch Bar, change behavior based on which application is focused, or emulate Windows/Linux keyboard behavior if you are doing a gradual migration and need consistency across machines. If you find yourself fighting macOS keyboard behavior repeatedly, install Karabiner before building workarounds.

Spotlight vs Raycast vs Alfred

Every experienced macOS user has a launcher tool bound to Cmd+Space (or a similar hotkey), replacing or supplementing Spotlight. The launcher is arguably the single most impactful productivity tool on the platform. Here is the honest breakdown:

Spotlight

The built-in system launcher, invoked with Cmd+Space. In 2026 it is meaningfully better than it was five years ago: it can search files with good accuracy, perform unit and currency conversions, define words, launch applications, find contacts, query system settings, and surface Siri Suggestions. For pure application launching it is fast and reliable. Its weaknesses are its lack of extensibility, limited support for custom workflows, mediocre web search (it surfaces browser history and bookmarks but will not do arbitrary web queries well), and no clipboard history.

For a non-technical switcher who mainly needs to launch applications and find files, Spotlight is sufficient. For developers and power users, it gets outgrown quickly.

Alfred

Alfred has been the dominant third-party launcher on macOS for over a decade. The free version is a capable app launcher and file searcher. The Powerpack ($37 one-time or bundled in their pricing tiers) unlocks the features that made Alfred famous: Workflows (automation chains triggered by keywords), clipboard history with search, snippet expansion, 1Password integration, custom web searches, a filesystem file browser, terminal integration, and Fallback Searches. Alfred’s workflow ecosystem is mature, and its users tend to be intensely loyal — you will find Alfred workflows for nearly any service you can name.

The honest trade-off: Alfred’s Powerpack is a one-time purchase with a track record of multi-year updates. If you value that ownership model and want a stable, mature tool with excellent documentation, Alfred is excellent. Its workflows are powerful but use a custom visual flow editor, which has more learning curve than Raycast’s extension approach.

Raycast

Raycast is the current community darling among developers, and for good reason. The free tier is shockingly complete: app launcher, clipboard history with 3-month retention, window management (making a separate window manager optional), snippets, a calculator with unit conversion, file search, and full access to over 1,000 community extensions. Extensions are built with a React-based API and published to the Raycast store — they install in one click and cover GitHub, Linear, Jira, Notion, Slack, 1Password, Homebrew, and dozens of developer-specific workflows.

Raycast Pro ($8/month) adds AI features (access to GPT-4 and Claude directly from the launcher), longer clipboard history, and cloud sync. In 2026, Raycast for Teams allows organizations to deploy private internal extensions, and Presets let you share entire configuration bundles with teammates.

Recommendation for switchers in 2026: Install Raycast, bind it to Cmd+Space (you can disable Spotlight’s shortcut in System Settings → Keyboard → Keyboard Shortcuts → Spotlight), and spend 15 minutes installing extensions for the services you use daily. The free tier will cover most people’s needs entirely. The one scenario where Alfred has a clear edge is if you have been building Alfred Workflows for years and do not want to rebuild them — Alfred’s Workflow automation is deeper for very custom use cases.

To set up Raycast: download from raycast.com, run the setup wizard, and when it asks to replace Spotlight’s hotkey, say yes. Install the following extensions from day one: brew install raycast is not the right path — download the .dmg directly from the website. Essential extensions to install: Window Management (if you are not using Rectangle), Clipboard History (enable in Raycast preferences), GitHub (if you use GitHub), 1Password (if you use 1Password), and Color Picker if you do any design work.

Window Management

Let us be direct: macOS native window management is genuinely worse than Windows snap or Linux tiling window managers. This is not a matter of preference. Windows 11 Snap Layouts and i3/sway tiling are objectively better at placing windows precisely on screen. macOS gives you a green button that can maximize, fullscreen (creating a new Space), and — in recent versions — enter a split view with another app. That is it. There are no keyboard shortcuts for snapping to halves, thirds, or quarters. Dragging a window to the screen edge does nothing. For anyone coming from a workflow that relies on snapping, this is immediately jarring.

The mitigation path is straightforward: install a third-party window manager on day one.

Spaces and Mission Control

Before covering third-party tools, understand the native virtual desktop system. Spaces are macOS virtual desktops. You create them in Mission Control (Ctrl+Up arrow, or three-finger swipe up on the trackpad). Each Space is independent; most applications can exist on one Space or be set to “All Desktops” in Mission Control. Switch between Spaces with Ctrl+Left/Right or three-finger swipe left/right. Mission Control shows all open windows across all spaces at once, plus the Spaces bar at the top.

Hot Corners can trigger Mission Control, the Desktop, or other actions when you push the cursor into a screen corner. Configure in System Settings → Desktop & Dock → Hot Corners. Muscle memory for Ctrl+Up (Mission Control) and Ctrl+Left/Right (Space switching) is worth building even if you install a tiling manager, since these are the native navigation primitives.

Three-finger gestures on the trackpad:
  Swipe up    -->  Mission Control (all windows/spaces)
  Swipe down  -->  App Expose (current app's windows only)
  Swipe left  -->  Previous Space
  Swipe right -->  Next Space

Rectangle (Recommended)

Rectangle is free, open source, and actively maintained. It adds Windows-style snap zones plus extensive keyboard shortcuts for window positioning. Dragging a window to the left edge snaps it to the left half; dragging to a corner snaps to a quarter. Keyboard shortcuts handle everything:

Rectangle Pro (paid, $9.99) adds window arrangement profiles, per-app positioning rules, gaps between tiled windows, and other refinements. The free version handles the core snapping workflow perfectly well.

Moom

Moom ($15, from Many Tricks) bridges the gap between basic snapping and workspace management. Its distinguishing features are custom grid-based positioning with arbitrary division, saved window layout “snapshots” that restore your entire multi-window arrangement with a single click or keyboard shortcut, and excellent multi-display support. If you work in several distinct modes — say, a “writing” layout with your editor fullscreen and a reference window on the right, and a “code review” layout with a diff tool and browser — Moom’s layout saving is worth the price.

Magnet

Magnet ($7.99 on the Mac App Store) does what Rectangle does but is a paid Mac App Store app. It is polished, receives updates, and has a loyal user base. The honest assessment is that it is primarily useful for people who prefer Mac App Store purchases with automatic update management. For everyone else, Rectangle is the better default choice.

Stage Manager

Apple introduced Stage Manager in macOS Ventura (2022) as a reimagining of window management. Windows group into “stages” on the left side of the screen, and clicking a group brings all its windows forward. It works better on iPad where the interaction model aligns with the hardware. On desktop Mac with a large display, most users — including the author — turn it off after a few days. It imposes its own spatial logic on top of Spaces without making either system work better. Disable it in System Settings → Desktop & Dock → Stage Manager.

Yabai + skhd (For Tiling WM Devotees)

If you are coming from i3, sway, or bspwm and cannot function without automatic tiling, Yabai combined with skhd gives you a keyboard-driven tiling window manager on macOS. Be warned: Yabai’s most powerful features require disabling System Integrity Protection (SIP), which is a security trade-off you should understand before making it. The BSP (binary space partitioning) tiling mode works without SIP disabled, which covers most tiling workflows. brew install koekeishiya/formulae/yabai koekeishiya/formulae/skhd gets you started, and the Yabai wiki has thorough configuration documentation.

Filesystem Differences

APFS

Apple File System (APFS) has been the default since macOS High Sierra (2017) on SSDs. For day-to-day use it is transparent, but a few properties matter to developers and power users:

• Snapshots: APFS supports copy-on-write snapshots. Time Machine uses these for nearly instant backups. You can create manual snapshots with tmutil localsnapshot and list them with tmutil listlocalsnapshots /.
• Clones: File clones share data blocks until they diverge — copying a large file is nearly instantaneous and consumes no additional space until one copy is modified.
• Space sharing: Multiple APFS volumes can live in the same container, sharing free space dynamically rather than having fixed partition sizes.
• Strong encryption: FileVault encrypts the full volume using hardware keys on Apple Silicon, and encryption/decryption is effectively zero-cost in performance terms.

Case-Insensitivity: The Most Dangerous Default

By default, APFS on macOS is case-insensitive but case-preserving. The filesystem stores README.md and readme.md as different names (preserving case), but treats them as the same file (case-insensitive). You cannot have both in the same directory.

This causes real problems for developers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# On macOS:
touch Makefile
ls Makefile   # works
ls makefile   # ALSO works — same file
cat MAKEFILE  # ALSO works

# On Linux:
touch Makefile
ls Makefile   # works
ls makefile   # No such file or directory

The most common failure mode is a git repository containing two files that differ only by case — something that is valid on Linux and will work fine on a Linux server but breaks on macOS because both filenames resolve to the same inode. Git can get confused and show files as both modified and unmodified simultaneously. If you clone a repository that has this issue:

1

git config core.ignorecase false  # Makes git treat case as significant

This does not solve the filesystem limitation but it makes git behavior consistent with what Linux git would do. For development work targeting Linux servers, be cautious about filenames — especially with Python module imports, where import utils and import Utils resolve identically on macOS but would fail or import different things on Linux.

If you need a case-sensitive filesystem for a specific project, you can create a case-sensitive APFS volume in Disk Utility and put your project there. This is an advanced option but is the correct solution if you are maintaining a project that has case-sensitive filename requirements.

Directory Layout Differences

The macOS directory layout differs from Linux FHS in several ways that affect developers immediately:

Linux FHS          macOS equivalent         Notes
-----------        ----------------         -----
/home/username     /Users/username          Users directory in /Users, not /home
/opt               (does not exist natively) Homebrew creates /opt/homebrew on Apple Silicon
/etc               /etc (symlink to /private/etc)
/tmp               /tmp (symlink to /private/tmp)
/usr/local/bin     /opt/homebrew/bin (AS)   Intel Macs use /usr/local
N/A                /Library                 System-level app support, preferences, extensions
N/A                ~/Library                User-level equivalent, hidden by default

/Users/username instead of /home/username means scripts that hardcode /home/ will fail. Use $HOME or ~ in scripts, never hardcode the path.

The Library folder (~/Library) is hidden by default. To access it: in Finder, hold Option and click the Go menu — Library appears. Or open Terminal and open ~/Library. It contains Application Support (per-app data), Caches, Preferences (plist files for most app settings), and Keychains. When debugging an application that is misbehaving, clearing its ~/Library/Application Support/<AppName> and ~/Library/Caches/<AppName> directories often resolves it.

The ~/.config directory works as expected — macOS applications that follow the XDG Base Directory specification will store configuration there, and many developer tools (neovim, git, various CLI tools) do. The XDG spec is not system-enforced the way it might be on a modern Linux distribution, but it works fine when applications implement it.

iCloud Drive and Your Home Directory

By default, a new Mac will offer to sync your Desktop and Documents folders to iCloud Drive. This sounds convenient and is catastrophic for developers. It means your home directory files can be in one of several states: fully local, evicted to iCloud (and marked with a download icon), partially downloaded, or in the process of syncing. A large git repository in an iCloud-synced folder will trigger constant background file activity, slow down operations, and can cause bizarre git behavior when files are mid-sync.

Turn this off immediately: System Settings → Apple ID → iCloud → iCloud Drive → (uncheck) Desktop & Documents Folders. This moves your files back to purely local storage. Use iCloud for what it is good at — syncing photos, contacts, and non-development files.

Developer Setup

The Exact Sequence

Do these steps in order on a fresh Mac:

Step 1: Install Xcode Command Line Tools

1

xcode-select --install

A dialog will appear asking to install the Command Line Tools package. Click Install, not “Get Xcode” (which downloads the full Xcode IDE — gigabytes you do not need unless you are developing iOS or macOS apps). This installs: git, make, clang, python3 (Apple’s system Python, not one you should use for development), and several other build-essential equivalents. Everything after this depends on this step being complete.

Step 2: Install Homebrew

1

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Homebrew is the package manager macOS should have shipped with. On Apple Silicon Macs, it installs to /opt/homebrew. On Intel Macs, it installs to /usr/local. The installer will tell you which.

Step 3: Add Homebrew to your PATH

After installation, the Homebrew installer will print instructions to add it to your PATH. Do this now or nothing will work:

1
2
3
4
5
6
7

# For Apple Silicon (M1/M2/M3/M4):
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

# For Intel Macs:
echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/usr/local/bin/brew shellenv)"

The reason this goes in .zprofile rather than .zshrc is explained below, but the essential point is: it must be evaluated before any tool that depends on Homebrew paths.

Step 4: Install core developer tools

1

brew install git wget curl jq ripgrep fd bat eza htop

Brief rationale for each: ripgrep replaces grep for code searching (significantly faster, respects .gitignore); fd replaces find with sane defaults; bat is a cat replacement with syntax highlighting and git integration; eza is a maintained fork of exa, replacing ls with color and icons; htop is a better top.

Step 5: Configure git

1
2
3
4

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global core.editor nvim  # or vim, or nano, your choice

Step 6: Generate SSH keys and add to keychain

1

ssh-keygen -t ed25519 -C "you@example.com"

Accept the default path (~/.ssh/id_ed25519), set a passphrase. Then add to the macOS keychain so you are not asked for the passphrase on every use:

1

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Create ~/.ssh/config with:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

This makes macOS automatically add the key to the SSH agent from Keychain at login. You type your passphrase once, ever.

.zshrc vs .zprofile: The Shell Config Split

macOS ships with zsh as the default shell (since Catalina). The config file split confuses many people arriving from Linux where .bashrc handled everything:

• .zprofile — sourced for login shells (a new terminal window, SSH session, or any shell that inherits the environment fresh). Put PATH modifications, environment variables, and eval statements for tools like Homebrew and mise here.
• .zshrc — sourced for interactive shells (any shell you type commands in, including shells spawned from an existing shell). Put aliases, functions, prompt configuration, and completion setup here.
• .zshenv — sourced for every shell, including non-interactive shells started by scripts. Only put variables that truly need to be available everywhere (e.g., EDITOR, LANG).

On Linux with bash, .bashrc is sourced for interactive shells and .bash_profile or .profile for login shells — the same split exists, but macOS terminal emulators default to opening login shells, which means .zprofile runs reliably. The practical rule:

1
2
3
4
5
6
7
8
9

# ~/.zprofile — the right place for these:
eval "$(/opt/homebrew/bin/brew shellenv)"
eval "$(mise activate zsh)"

# ~/.zshrc — the right place for these:
alias ll='eza -la --git'
alias cat='bat'
source /opt/homebrew/share/zsh-autosuggestions/zsh-autosuggestions.zsh
PROMPT='%n@%m %~ %# '

Shell Enhancement: Vanilla zsh vs Oh My Zsh vs Starship

Oh My Zsh is the popular choice for zsh enhancement — it provides an enormous plugin and theme ecosystem with simple installation. The honest assessment: it is slightly bloated (adds tens of milliseconds to shell startup) and many of its plugins do things you can configure in vanilla zsh. It is excellent if you want to get a productive shell quickly without manual configuration.

Starship is a cross-shell, cross-platform prompt written in Rust. It is fast, renders in under 5ms, and has a sensible default configuration that shows git status, language versions, and exit codes without any setup. Install it with brew install starship and add eval "$(starship init zsh)" to ~/.zshrc. If you are on multiple platforms and want a consistent prompt everywhere, Starship is the right choice.

Vanilla zsh with manual configuration is underrated. Modern zsh has excellent built-in completion, history search with HIST_IGNORE_DUPS and setopt HIST_FIND_NO_DUPS, and the only external plugins most developers need are zsh-autosuggestions and zsh-syntax-highlighting (both installable via Homebrew). A clean, fast shell you understand is worth more than a feature-heavy shell with configuration you did not write.

Managing Language Versions with mise

The old approach was per-language version managers: pyenv for Python, nvm for Node.js, rbenv for Ruby. Each has its own configuration format, its own shell hook, and its own set of quirks. In 2026, mise (pronounced “meez”) is the right unified answer.

1
2

brew install mise
echo 'eval "$(mise activate zsh)"' >> ~/.zprofile

mise reads .nvmrc, .python-version, .tool-versions, and its own .mise.toml configuration files, making it backward-compatible with existing projects. Use it like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Install and use a specific Python version:
mise use --global python@3.12

# Install Node.js LTS globally:
mise use --global node@lts

# Per-project overrides (creates .mise.toml):
cd ~/projects/myapp
mise use python@3.11 node@20

# Show all installed tool versions:
mise list

A single .mise.toml in your project root replaces Pipfile (for Python version), .nvmrc, .ruby-version, and .tool-versions. Teammates who have mise installed pick up the tool versions automatically when entering the project directory.

Apple Silicon and Rosetta 2

If you are on an Apple Silicon Mac (M1 through M4 series), the vast majority of developer tooling runs natively on ARM64 in 2026. Homebrew fully supports Apple Silicon. Most Python packages, Node modules, Ruby gems, Docker images, and development tools have ARM64 builds.

Rosetta 2 is a translation layer that lets you run x86_64 binaries on Apple Silicon. Install it with:

1

softwareupdate --install-rosetta --agree-to-license

You need Rosetta primarily for legacy tools that have not been ported, older versions of language runtimes (Ruby 2.x, for instance), and a handful of niche applications. For most development workflows in 2026, you will encounter Rosetta situations rarely.

To check which architecture a binary is running under:

1
2

arch                    # shows arm64 or i386 (i386 = running under Rosetta)
file $(which python3)   # shows Mach-O 64-bit executable arm64, or x86_64

To run a command explicitly under Rosetta (for testing or compatibility):

1
2

arch -x86_64 zsh        # spawn an x86_64 shell
arch -x86_64 brew install <package>  # install an x86_64 version

Terminal Options

macOS ships with Terminal.app, which is more capable than it looks. It supports 256 colors, unlimited scrollback, custom profiles, window groups (saved sets of windows), and integration with the macOS keychain for SSH. For users who came from Windows Subsystem for Linux or who do not heavily customize their terminal, Terminal.app is genuinely sufficient. Give it a fair chance before immediately replacing it.

That said, three third-party terminals have earned significant adoption, and one of them is likely the right choice for experienced developers.

iTerm2

iTerm2 has been the de facto standard macOS terminal for over a decade, and its feature set reflects that history. The distinguishing capabilities:

• tmux control mode (tmux -CC): this is the feature no other terminal has matched. When you SSH into a remote server and attach tmux with -CC, iTerm2 converts tmux’s panes and windows into native iTerm2 splits and tabs. You get native macOS scrollback, copy-paste, and window management for remote sessions. For anyone who uses tmux heavily on remote servers, this alone justifies iTerm2.
• Triggers: regex-based rules that fire on matched output — highlight error lines, run a script when a build fails, annotate log output automatically.
• Profiles: save complete terminal configurations (colors, font, default directory, startup commands) and switch between them instantly.
• Shell integration: hook into the shell to mark command prompts and output blocks, enabling features like clicking on a previous command to jump to its output, rerunning commands with a click, and getting notified when a long command finishes.
• Python scripting API: automate anything — create windows, run commands, respond to events.

The weaknesses: iTerm2 is relatively heavy at ~185 MB idle memory, its configuration UI is complex enough to be occasionally overwhelming, and its rendering is slower than GPU-accelerated alternatives.

Warp

Warp takes a different conceptual approach to the terminal. Commands and their output are grouped into “blocks” — discrete visual units that you can navigate, select, copy, and share independently. The AI features, which felt awkward at launch, have matured: natural language to command translation works well (type what you want to do, get the command), and error diagnosis correctly suggests fixes for a meaningful percentage of real errors.

The honest criticisms of Warp: it requires an account and communicates with Warp’s servers (the AI features in particular), which makes it inappropriate for air-gapped or sensitive environments. It is memory-hungry at ~340 MB idle. Its block-based model is alien to anyone with deep terminal muscle memory, and some experienced developers find it condescending — the terminal is a tool for people who know what they are doing, and wrapping it in an AI assistant changes the interaction model in ways not everyone wants.

For developers coming from Windows who are accustomed to richer GUI tools and are not already deeply attached to terminal conventions, Warp is a reasonable choice. For experienced Linux terminal users, the friction is likely not worth the AI features.

Ghostty

Ghostty is a newer terminal written in Zig with a custom GPU rendering engine targeting Metal on macOS. In 2026 it is the performance leader by a significant margin — ~3x the throughput of iTerm2, 2ms input latency versus iTerm2’s 12ms, and ~28 MB idle memory. It is free, open source (MIT license), requires no account, and has no telemetry. Configuration uses a plain text config file rather than a GUI, which appeals to the dotfiles crowd.

The weakness is age — Ghostty lacks the deep feature set that iTerm2 has accumulated over fifteen years. tmux -CC mode is not available. The trigger system does not exist. Some edge cases in terminal rendering compatibility surface. But for developers who want a fast, native-feeling terminal without feature bloat, Ghostty is the right choice in 2026 and is gaining significant momentum.

Recommendation: Come from Linux with a heavy terminal workflow? Install iTerm2 first for the familiar experience and the tmux -CC feature. If you find Ghostty’s speed compelling and can live without the advanced iTerm2 features, migrate to Ghostty. Avoid Warp unless you specifically want AI command assistance and are comfortable with its cloud dependency model.

Common Frustrations and Solutions

1. “Where’s my maximize button?”

The green button in the top-left of every macOS window does not maximize — it either triggers native fullscreen (which creates a new Space) or, in some applications, “zooms” to a calculated best size. Neither behavior matches the Windows/Linux maximize behavior of “fill the screen with this window.”

Solution: Install Rectangle and use Ctrl+Option+Return to maximize without fullscreen. If you accidentally click the green button and end up in fullscreen, press Escape or Ctrl+Cmd+F to exit.

2. “Cut and paste files in Finder doesn’t work”

This one generates genuine frustration. In Finder, Cmd+X does not cut files. Cmd+C copies them, and you might expect Cmd+V to paste, leaving the original behind (the cut-and-move behavior). macOS does not work this way.

Solution: Copy with Cmd+C as usual, then use Cmd+Option+V to move (not copy) the file to the destination. The file is removed from the original location. It is an odd ergonomic choice but becomes natural quickly.

3. “I can’t see file extensions”

macOS hides file extensions by default. document.pdf displays as just document. This is maddening for any technical user.

Solution: In Finder, open Settings (Cmd+,), click the Advanced tab, and check “Show all filename extensions.” Do this first thing on any Mac you use regularly.

4. “Homebrew installs are slow”

Homebrew checks for updates before every operation by default, which can add 30+ seconds to brew install commands when updates are available.

Solution: Set HOMEBREW_NO_AUTO_UPDATE=1 in your environment to skip the auto-update check when installing packages. Run brew update && brew upgrade on your own schedule instead.

1
2

# Add to ~/.zprofile:
export HOMEBREW_NO_AUTO_UPDATE=1

For organizations where Homebrew downloads are slow due to network conditions, HOMEBREW_BOTTLE_DOMAIN can redirect binary bottle downloads to a mirror, though the official CDN is generally fast enough in 2026.

5. “My dotfiles from Linux don’t work”

Two layers of incompatibility bite Linux users bringing their dotfiles to macOS:

Shell differences: Your .bashrc from Linux will not be sourced automatically if your shell is now zsh. You need .zshrc. Additionally, many bash-specific constructs (source works, but local in functions behaves slightly differently, array syntax differs).

BSD vs GNU coreutils: macOS ships with BSD versions of sed, awk, grep, find, xargs, and others. These are functionally similar to GNU versions but have different flags. sed -i '' instead of sed -i; find . -name "*.txt" works the same but find . -maxdepth might behave differently in edge cases; awk is slightly older POSIX-only in the BSD version.

Solution: brew install coreutils gnu-sed gawk grep findutils then add them to your PATH before the system utilities:

1
2
3
4

# In ~/.zprofile, after Homebrew setup:
export PATH="$(brew --prefix)/opt/coreutils/libexec/gnubin:$PATH"
export PATH="$(brew --prefix)/opt/gnu-sed/libexec/gnubin:$PATH"
export PATH="$(brew --prefix)/opt/grep/libexec/gnubin:$PATH"

After this, sed, grep, and the other tools in your PATH are the GNU versions, and your Linux shell scripts should work without modification.

6. “App won’t open — unidentified developer”

macOS Gatekeeper prevents launching applications that are not signed by an Apple Developer account or distributed through the App Store. First launch of a downloaded app will often produce “cannot be opened because it is from an unidentified developer.”

Solution: Right-click (two-finger click on trackpad) the application icon and select Open. A different dialog appears that includes an Open button. Click it once and macOS remembers the exception. Alternatively, if you have already seen the block dialog, go to System Settings → Privacy & Security → scroll down to find the blocked app and click Open Anyway. Never disable Gatekeeper entirely (sudo spctl --master-disable) — it is a meaningful security layer.

7. “Where’s Task Manager?”

Solution: Activity Monitor is the macOS equivalent — search for it in Spotlight (Cmd+Space, type “Activity Monitor”). It shows CPU, memory, energy, disk, and network usage per process. The CPU column sorts by current usage, Memory by RAM consumption. For command-line users, top works as on Linux; brew install htop gives you the interactive version; brew install bottom provides a modern Rust-based alternative.

1
2
3
4

# Quick one-liners for process investigation:
ps aux | grep <processname>   # find a process
lsof -i :8080                 # what's using port 8080
sudo lsof -p <PID>            # all files open by a process

8. “File copy progress is invisible”

You copy a large folder in Finder and nothing visible seems to be happening. No progress bar, no indication that anything is occurring.

Solution: Click the Finder icon in the Dock (not a Finder window, the icon itself). A progress display appears. Alternatively, open any Finder window — the copy progress appears in the sidebar. This is a discoverability failure in macOS; the progress is there but requires knowing where to look.

9. “Right-click doesn’t work on my trackpad”

A single-button trackpad trips up Windows users who are used to a physical right mouse button.

Solution: Two-finger click anywhere on the trackpad is right-click. Or hold Control and click. If neither is working, go to System Settings → Trackpad → Point & Click → Secondary click — ensure it is set to “Click with two fingers” or “Click in bottom-right corner” based on your preference. The two-finger click behavior is the standard and works everywhere.

10. “My Linux shell scripts fail”

Beyond the BSD/GNU coreutils issue covered above, other common script failure modes on macOS:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Script uses /bin/bash but expects bash 4+ features (macOS ships bash 3.2):
#!/usr/bin/env bash            # use env to find the Homebrew bash
brew install bash
# Add /opt/homebrew/bin/bash to /etc/shells, then scripts get bash 5.x

# Script uses /usr/bin/python3 directly:
# Apple's system python3 is a stub that prompts to install Xcode tools.
# Use the mise-managed or Homebrew Python instead.
which python3                 # verify it points to Homebrew/mise path

# Script uses realpath, which is not in BSD coreutils by default:
brew install coreutils        # provides realpath, among others

# Script uses mktemp with GNU flags:
# BSD mktemp does not accept -p for custom temp directory; use $TMPDIR

Closing Notes

The macOS adjustment period is real but bounded. Most Linux and Windows switchers find their footing within two to four weeks of daily use. The mental model shift — application-centric persistence, the menu bar as application context, Cmd replacing Ctrl — accounts for the majority of the friction, and it genuinely clicks all at once rather than gradually.

The legitimate criticisms of macOS are worth naming directly: window management is behind competitors and requires third-party tools to reach parity; filesystem case-insensitivity is a latent bug waiting to happen for any developer working on Linux-targeted software; the system is expensive, opinionated, and occasionally condescending about how much control it gives you. These are real costs.

The genuine strengths — the hardware-software integration on Apple Silicon, the quality of first-party applications (Preview, Keynote, Final Cut for those who use it), the trackpad experience which remains the best in the industry, the consistent application model across all macOS software, and the Unix foundation underneath — make it a genuinely excellent daily driver for development work. The tooling covered in this guide — Homebrew, Raycast, Rectangle, Ghostty or iTerm2, mise — fills the remaining gaps. After the adjustment period, most people who switch do not switch back.

Keep this guide bookmarked for the first few weeks. The frustrations covered in the last section cover most of what trips people up, and the keyboard shortcut table will save significant time. The rest is muscle memory, and muscle memory is just repetition.