Vor etwas über zwei Jahren startete ich für mich persönlich ein Experiment. Ich habe mir einen MacBook Pro mit dem zu der Zeit neuen M1 Prozessor gekauft. Für mich war das tatsächlich ein großer Schritt, da ich meinen Fokus auf der .NET Plattform von Microsoft habe und damit seit über 15 Jahren bis auf wenige Linux-Ausflüge primär auf Windows unterwegs war. Der neue M1 Prozessor und dessen Balance aus Leistung und Akkulaufzeit war dabei ein Auslöser der Entscheidung für das Experiment. Es kamen aber auch andere Faktoren dazu. Immer häufiger bin ich etwa bei Kunden und im Bekanntenkreis auf macOS Benutzer gestoßen. Die Zeit war also mehr als reif, mich selbst als Entwickler mit der Plattform zu beschäftigen. Über meine Erfahrungen, Ärgernisse und warum es für mich Stand heute eine gute Entscheidung war, erfährst du mehr in diesem Artikel.
Inhalt
Tastatur als die erste Hürde
Was ich bei dem Experiment maximal unterschätzt habe, ist die Tastatur. Kleine Unterschiede sind dabei direkt sichtbar, so verfügt macOS neben der Control-Taste auch über eine Option- und eine Command-Taste. In Windows existieren letztere beiden nicht. Das nächste, auf was man typischerweise stößt, ist die abweichende Position der @-Taste. Richtig interessant wird es dann aber beim Entwickeln, da die doch recht regelmäßig benötigten eckigen und geschweiften Klammern ebenfalls an anderer Stelle liegen – und diese Zeichen am MacBook Pro nicht einmal auf den Beschriftungen der Tasten auftauchen. Auch Tastenkombinationen liegen anders, das unter Windows übliche STRG+C etwa ist unter macOS Command+C. Da ich neben den MacBook Pro trotzdem weiterhin parallel auch einen Windows Laptop nutze, musste ich hier regelmäßig im Kopf umschalten.
Stand heute, zwei Jahre nach dem Kauf des MacBooks habe ich mich halbwegs daran gewöhnt. Geholfen hat eine Tastatur, welche sowohl eine Beschriftung für Windows, als auch eine Beschriftung für macOS auf den Tasten hat. Beim Wechseln zwischen den Systemen passiert es mir allerdings schon immer wieder, dass man mal Command+C unter Windows oder STRG+C unter macOS versucht. Das hat aber so weit keine negativen Folgen.
.NET Entwicklung lief von Anfang an gut
Unabhängig von der Tastatur lief die Arbeit mit .NET von Anfang an relativ gut. Einzig das Thema IDE war zu Beginn etwas unklar. Mit dem mittlerweile eingestellten Visual Studio for Mac (Siehe [1]) bin ich persönlich nie wirklich warm geworden. Gleiches gilt für C#-Erweiterungen von Visual Studio Code. Letzteres finde ich für kleine Themen sehr wertvoll. Für Projektmappen mit mehreren Projekten allerdings fühlt es sich für mich schnell mehr nach einem etwas besseren Texteditor als wie nach einer ausgewachsene IDE an. Demgegenüber hat sich die IDE Rider von JetBrains einen Weg in meinen Arbeitsalltag ergattert. Rider ist Cross-Plattform, hat alle Funktionen, die man von einer IDE erwartet und ist dazu noch angenehm flott.
Vom Framework selbst gab es nie Probleme. Webentwicklung mit ASP.NET Core funktioniert unter macOS reibungslos. Desktop-Entwicklung etwa mit WPF funktioniert zwar nicht, dafür gibt es mit Avalonia aber eine sehr gute Alternative (Siehe [2]). Was fehlt, sind eher die Tools drum herum. JetBrains migriert einige Produkte wie dotTrace auf macOS. Andere Tools, etwa aus der OpenSource-Szene, fehlen leider. Ein gutes Beispiel dafür ist IlSpy (Siehe [3]). Zwar existiert ein älterer Fork auf Basis von Avalonia, dieser läuft aber nicht stabil. Der Nuget Package Explorer ist ein weiteres Beispiel. Hier existiert für macOS lediglich eine Version auf Basis von UNO / Webassembly, welche im Browser ausgeführt werden kann.
Insgesamt läuft das Entwickeln von .NET Applikationen sehr gut. In 2023 war ich die deutlich längere Zeit auf macOS unterwegs, als auf Windows.
Vorsicht bei Docker
Beim ersten Start überraschend, aber am Ende trotzdem logisch sind möglicherweise fehlende Docker-Images für die ARM Architektur. Dieses Problem hat sich zwar nach und nach verbessert, insbesondere zu Beginn bin ich aber öfters auf Images gestoßen, die nur für die X86 Architekturen verfügbar waren. Die X86 Emulation in macOS macht hier zwar einen guten Job, zusammen mit Docker lief aber nicht alles stabil. Daher an dieser Stelle eine (kleine) Warnung: Solltet ihr regelmäßig Docker verwenden, dann prüft, ob die für euch wichtigen Images auch für die ARM Architektur verfügbar sind.
Gute Auswahl an Cross-Plattform Software
Ähnlich wie beim Entwickeln selbst achte ich seit dem Kauf des MacBook Pro deutlich stärker darauf, überwiegend Cross-Plattform Software einzusetzen. Das geht bei den typischen Office Programmen los, geht weiter über Bildbearbeitung bis zum Passwort-Manager. Glücklicherweise lassen sich in vielen Bereichen gute Produkte finden. Es gibt aber auch einige wenige Stellen, an denen es schwieriger ist. So fehlt mir beispielsweise Paint.NET auf macOS. Klar, es gibt gute Alternativen wie etwa Gimp, für mich und meine Einsatzzwecke sind diese dann aber schon einen Tick zu komplex.
Erfahrung bez. Nutzung von macOS ist Gold wert
Abschließend möchte ich darauf eingehen, warum mein Experiment mit dem MacBook Pro aus meiner Sicht eine sehr gute Entscheidung war. Primär geht es dabei um die Erfahrung, die ich mit dem Betriebssystem und dem Apple Ökosystem sammeln konnte. Insbesondere bei meiner Tätigkeit als Trainer: In fast allen meiner Trainings saß bis jetzt jemand mit einem MacBook. Da ich die Plattform mittlerweile gut kenne, kann ich auch hier bei Problemen gut unterstützen. Ein anderes Beispiel kommt aus meiner Tätigkeit als Entwickler. Ich kann meine Applikationen neben Windows ebenfalls relativ einfach auf macOS testen und kenne auch einige Besonderheiten des Betriebssystems.
In Summe steige ich allerdings nicht vollständig auf macOS um. Stattdessen habe ich für mich eine andere Lösung gefunden. Mein mobil-Laptop ist und bleibt vermutlich in der Zukunft ein MacBook Pro. Die Akkulaufzeit und der in der Praxis nicht hörbare Lüfter sind einfach ideal für unterwegs. Meine Workstation für anspruchsvolle Aufgaben wird aber weiter ein Windows Laptop bleiben. Das liegt daran, dass neue Funktionen von .NET i. d. R. zunächst bei Visual Studio verfügbar sind. Es gibt für mich aber auch Gründe, die unabhängig von meiner Tätigkeit als Entwickler sind. Gaming ist das beste Beispiel. Die Auswahl von Games ist auf macOS leider nach wie vor mies.
Verweise
- Weiterentwicklung von Visual Studio for Mac wurde eingestellt
https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022 - Cross-Plattform Alternative für WPF
https://avaloniaui.net/ - OpenSource .NET Decompiler
https://github.com/icsharpcode/ILSpy
Ebenfalls interessant
- Cross-Plattform GUI mit C# und Avalonia
https://www.rolandk.de/wp-posts/2020/07/cross-platform-gui-mit-c-und-avalonia/