Windows to Mac: Build a Practical Development Setup

When you move to Mac, the easiest way to lose time is to reinstall every tool you recognize from Windows on day one.

FreeMac's approach: get one real project running, then add a tool only for a clear need. A development setup is not complete because it contains many apps. It is complete when you can get code, install its dependencies, start the project, and make a Git commit you can push.

This guide is for developers moving from Windows to Mac. The opening system adjustments also help everyday users; from “The shortest development path” onward, follow only what your project needs. Product versions, licences, and features change, so use the official links for current details. This guide was checked on September 6, 2026.

Make Mac comfortable

Keep this section to migration details that affect daily work. For a broader transition guide, see the Windows to Mac Roadmap.

Trackpad, Finder, and screenshots

• Enable Tap to click in System Settings → Trackpad. Natural scrolling is a personal preference.
• In Finder, show all filename extensions, the path bar, and the status bar. Project folders, hidden configuration files, and file types are easier to identify.
• Learn ⌘ + Shift + 4 for a selected screenshot and ⌘ + Shift + 5 for the screenshot and recording panel.
• macOS now includes window tiling. Add Rectangle or Raycast window management only if you need fixed shortcuts, more layouts, or multi-display rules. Apple's guide

Keep migration tasks separate from development setup

Chinese input, external-drive formats, browser bookmarks, passwords, and chat-file migrations matter, but they are not your development environment. Keep this guide focused. Use the Roadmap and your system-preferences guide for those topics instead of installing unrelated apps here.

FreeMac's shortest development path

These five steps apply to most languages and frameworks. Verify each one before moving on.

1. Install Command Line Tools and Homebrew.
2. Configure Git identity and repository authentication.
3. Choose runtimes and package managers for the current project.
4. Select one editor and run the project.
5. Make one commit. Your development setup is now usable.

1. Command Line Tools and Homebrew

Start with Apple's Command Line Tools. They provide Git, build tools, and prerequisites used by many installers:

xcode-select --install

Then get the current installer from Homebrew:

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

At the end, the installer prints “Next steps.” Copy the brew shellenv command it gives you. Apple Silicon usually uses /opt/homebrew; Intel Macs usually use /usr/local. Do not copy another Mac's path into your shell configuration.

Open a new Terminal window and verify:

brew --version

Use a mirror only when the network needs one

Try the official installer first. When GitHub or downloads are genuinely failing or slow, follow a current guide from a trusted mirror. For example, the USTC Homebrew mirror guide covers its installer, API, and bottles. A mirror is a network remedy, not a permanent requirement; know how to return to official sources.

2. Git: Identity is not login

Install Git with Homebrew and set the identity used in your commits:

brew install git
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git --version

user.name and user.email identify commits; they do not grant access to private repositories or let you push. Next, use the method your team expects: HTTPS login or an SSH key. GitHub users can follow the official SSH guide; follow your team's documentation for GitLab, Gitea, or a self-hosted service.

If you use a proxy, do not copy an arbitrary port. Configure Git's http.proxy and https.proxy only when your own network requires them, and retain the way to remove them:

git config --global --unset http.proxy
git config --global --unset https.proxy

3. Runtimes and package managers: the project comes first

Do not begin by asking for “the best Node version on Mac.” Read the repository: .nvmrc, the engines and packageManager fields in package.json, its README, and its lockfile decide which tools that project needs.

Node.js projects

For a new project, choose the current LTS. At the checked date, Node 24 is LTS and Node 22 is in maintenance. Existing projects should still follow their own requirements rather than being upgraded by default. fnm is one way to manage multiple Node versions:

brew install fnm
echo 'eval "$(fnm env --use-on-cd)"' >> ~/.zshrc
source ~/.zshrc

# Example for a new project; replace 24 with the project's requirement.
fnm install 24
fnm default 24
node --version

Follow the package manager already chosen by the repository:

For a new pnpm project, manage it through Corepack instead of casually installing an unrelated global version:

corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

Other languages

Install Python, Go, Rust, Java, and .NET only when the project calls for them. Follow the repository README or official instructions; your team's conventions should also determine version managers.

4. Editor and terminal: choose one working combination

VS Code is a stable starting point:

brew install --cask visual-studio-code

Cursor can be evaluated as an AI-assisted editor, but it does not need to become a second primary editor. First make one editor open the project, understand its language, run a terminal, and debug it.

The built-in Terminal is already enough for development. iTerm2, Warp, Starship, and themes improve comfort; they should never block project startup.

FreeMac's take: Choose an editor by whether you can reliably open a project, understand team configuration, run tests, and resolve conflicts—not by which one advertises the most AI features. AI is an enhancement, not the foundation.

5. Verify with a real project

The useful test is a real workflow, not a page of version numbers:

# Replace with your team's repository.
git clone git@github.com:your-org/your-project.git
cd your-project

# Choose npm / pnpm / yarn / bun based on the repository lockfile.
pnpm install
pnpm dev

If you do not have a project yet, create a Next.js example. It tests the Node path, not every development stack:

pnpm create next-app@latest hello-mac
cd hello-mac
pnpm dev

Make a small change, run the project's check or test, inspect git status, then commit it. Once you can complete “clone → install → start → commit” in your own repository, stop adding foundation tools.

Add only when needed: Docker, AI, and local models

These are useful when they solve a defined problem; they are not developer identity badges.

Docker and local databases

When a project needs containers, install Docker Desktop. The current Homebrew cask is:

brew install --cask docker-desktop

Start Docker Desktop, then use docker info to confirm the engine is running. Docker Desktop is not free for every commercial case: personal use, education, non-commercial open source, and qualifying small businesses are free; check Docker's subscription FAQ for company use.

This database example is for temporary local development only. It uses weak passwords and restricts ports to the local machine:

services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    ports:
      - "127.0.0.1:5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

  adminer:
    image: adminer
    ports:
      - "127.0.0.1:8080:8080"

volumes:
  postgres_data:

In the folder containing docker-compose.yml, start and check it:

docker compose up -d
docker compose ps
docker compose logs --tail=50

Use docker compose down to stop services. It keeps named volumes by default; only use docker compose down -v after confirming you no longer need local data.

AI coding tools

Claude Code, Cursor, and other AI tools belong after a project already runs. Installing a client does not itself provide usable service: Claude Code needs an eligible subscription, Console account, or supported cloud-provider access. Team projects also need to follow code, secret, and data-handling rules.

Ollama local models

Install Ollama only when you need to run models locally:

brew install --cask ollama

An already downloaded local model can run on the machine, but the initial model download requires a network connection, and Ollama also has cloud features. For strict local-only requirements, disable cloud features following its official FAQ. Model size, quantization, memory, and context length determine the actual experience; test your own workload instead of relying on a slogan about a Mac generation.

Common blockers

Finish by recording a repeatable setup

Once a real project runs, record only the tools you actually need. Homebrew users can export a Brewfile and keep it with version notes in a personal configuration repository:

brew bundle dump --force --file=~/Brewfile

This is not a day-one requirement. It becomes useful once your toolkit has settled and you want to restore it quickly on the next Mac.

FreeMac's conclusion: a new Mac does not need to become a Mac full of tools on its first day. Run a real project first. Every tool you add after that should have a named problem it solves. That is a development environment you can maintain.

Continue reading

• Windows to Mac Roadmap
• Free Mac developer software rankings