Visual Studio zu Mac in der Praxis: Tag-eins-Checkliste, IDE-Wahl, Tastaturbelegung

Wenn du gerade ein MacBook bekommen hast und instinktiv im „Startmenü“ nach Visual Studio suchst oder im Explorer eine .sln doppelklickst – dann ist nicht das SDK das Schwierigste, sondern das Muskelgedächtnis. Dieser Artikel richtet sich an .NET-, C++- oder Full-Stack-Entwickler, die jahrelang Visual Studio oder Visual Studio Code unter Windows genutzt haben. Er liefert eine reproduzierbare Umgebungs-Checkliste in drei Phasen – „Tag eins kompilieren, Woche eins PR, Monat eins CI“ – und erklärt am Ende, wann iOS-Builds auf einen Cloud-Mac ausgelagert werden sollten.

Erste zwei Stunden: Terminal, Git und dotnet zum Laufen bringen

Installiere nicht sofort das volle Xcode. In der Reihenfolge unten stellst du meist innerhalb von 120 Minuten den Hauptpfad Lösung öffnen → F5 debuggen wieder her.

1. Command Line Tools und Homebrew

xcode-select --install          # Dialog bestätigen; reicht, wenn du nur Git und clang brauchst
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Auf Apple Silicon ist das Homebrew-Präfix /opt/homebrew (Intel: /usr/local). Nach der Installation brew doctor ausführen und auf Fehler prüfen.

2. .NET SDK und gängige CLIs

brew install --cask dotnet-sdk
brew install git gh jq fzf ripgrep
dotnet --info                   # SDK-Version und RID (osx-arm64) prüfen

Wenn das Team eine SDK-Version festlegt, global.json im Projektroot anlegen:

{
  "sdk": {
    "version": "8.0.400",
    "rollForward": "latestFeature"
  }
}

3. Git-Identität und Zeilenenden

git config --global user.name "Dein Name"
git config --global user.email "you@company.com"
git config --global core.autocrlf input   # input auf dem Mac empfohlen; vermeidet Zeilenenden-Diffs fürs ganze Repo bei Windows-Kollegen

Stolperfalle: Zeigt ein von Windows geklontes Repo „alle Dateien modified“, liegt es in neun von zehn Fällen an core.autocrlf und .gitattributes. Team-Regeln am ersten Tag vereinheitlichen – günstiger als später die Historie zu bereinigen.

IDE-Wahl: Rider, VS Code oder Windows behalten?

Microsoft hat den Support für Visual Studio for Mac beendet (08/2024). Realistische Optionen:

Entscheidungshilfe:

• Reines ASP.NET Core / API / Konsolen → Rider oder VS Code, eine Wahl reicht.
• .NET MAUI mit iOS-Release → lokal Rider + Xcode (oder VS Code + Xcode CLI); Android-Emulator läuft direkt auf dem Mac.
• Team nutzt einheitliche ReSharper-Regeln → Rider-Lizenz mit Firmen-JetBrains-Konto abstimmen.

Tastatur und Fensterverwaltung: Ctrl-Gewohnheiten in drei Tagen umstellen

Auf dem Mac übernimmt ⌘ die Rolle von Windows-Ctrl für Speichern, Kopieren, Einfügen und Rückgängig. Diese Tabelle ausdrucken und neben den Monitor kleben:

Fensterverwaltung ist der zweite Schmerzpunkt: Rectangle (kostenlos) oder Magnet installieren und mit ⌃+⌥+Pfeiltasten Win11-ähnliche Snap-Layouts nutzen. Bei mehreren Monitoren: Systemeinstellungen → Displays → Displays haben eigene Spaces, damit Vollbild-Apps nicht zwischen Bildschirmen springen.

Terminal, Shell und Docker: von PowerShell zu zsh

Empfohlenes Minimal-Setup

brew install starship eza bat fd
# ~/.zshrc-Ausschnitt
eval "$(starship init zsh)"
alias ls='eza --icons'
alias cat='bat'

PowerShell-Nutzer

`brew install powershell` ist möglich, aber Team-Skripte sind meist bash/zsh; langfristig persönliche Aliase nach zsh migrieren.

Docker Desktop

Ähnlich wie unter Windows; auf Apple Silicon Image-Architektur beachten (linux/arm64 vs amd64). Nach Containerisierung der Datenbank funktioniert localhost in Verbindungsstrings auf dem Mac gleich.

Datenbank-GUIs

Azure Data Studio, DBeaver und TablePlus gibt es für macOS; SSMS gibt es nicht nativ – Azure Data Studio als Ersatz.

.NET MAUI und iOS: lokale Entwicklung, Builds aufteilen

Typische Arbeitsteilung für MAUI-Cross-Platform-Projekte auf dem Mac:

1. Rider / VS Code: gemeinsame UI und Geschäftslogik bearbeiten.
2. Lokale Simulator: iOS/Android-UI debuggen (Xcode + Android-Studio-Emulator nötig).
3. Release-Archive: dotnet publish startet die Xcode-Toolchain; auf CI ist ein fester macOS-Knoten stabiler.

Kommst du von nur Windows mit Visual Studio, hängst du beim ersten iOS-Paket lange bei Signierung und Provisioning Profiles – das ist Apple-Workflow, nicht IDE-Wahl. Siehe Apple Developer — Xcode-Support für SDK- und macOS-Versionen.

Wochen-eins-Checkliste: bei Teamarbeit nichts vergessen

Wo Visual-Studio-Gewohnheiten auf dem Mac landen

Wann ein Cloud-Mac statt weiterer lokaler Konfiguration

Diese Szenarien sind in Teams, die von Visual Studio auf den Mac wechseln, häufig:

• Windows bleibt Firmen-Standarddesktop, nur Mobile braucht macOS-Builds → dedizierten Mac mieten, Pipeline per SSH von Windows starten.
• Mehrere Xcode-Versionen (iOS 16/17/18 parallel) → mehrere Xcodes fressen lokal Speicher; Knoten in der Cloud sind sauberer getrennt.
• Kurzes Kundenprojekt, iOS-Lieferung in drei Monaten → Tages-/Wochenmiete amortisiert schneller als Mac-mini-Kauf.

Bei Unsicherheit: vor dem Kauf eines zweiten „nur-für-Builds“-Macs mit Tagesmiete ein echtes Repo xcodebuild archive laufen lassen und 36-Monats-TCO vergleichen. Zum Abgleich: GitHub Actions macOS Runner – Knotenkosten.

Fazit: Der Workflow wandert, nicht eine einzelne IDE

Visual-Studio-Entwickler auf dem Mac: Tag eins Homebrew, dotnet, Git und IDE-Wahl; Woche eins Zeilenenden, Schlüssel und Team-Skripte vereinheitlichen; Monat eins iOS-CI und schwere Kompilate vom Laptop auf stabile macOS-Knoten verlagern. Tools wechseln (Rider, VS Code, Cursor), aber der Rhythmus bauen, debuggen, liefern darf nicht abbrechen.

Wenn du MAUI + iOS-Pipelines aufsetzt: lokal schlank bleiben, Archive an den Cloud-Mac – Rechenleistung fürs Kompilieren, nicht untätig in der Schublade.