Die Gerüchte bewahrheiteten sich vollständig: Apple kehrt Intel beim Mac den Rücken und setzt in Zukunft auf Apple-eigene ARM-Prozessoren und eigene GPUs. Doch es gibt eine Vielzahl von Mac-Programmen, welche umgestellt werden müssen. Apple bietet zwar mit Rosetta 2.0 eine schnelle Lösung, um bestehende Software weiterzuverwenden – doch über kurz oder lang müssen Entwickler ihre Programme anpassen.


Meist wenig Arbeit
Zuerst die gute Nachricht: In der Dokumentation bezüglich der Migration sind keine größeren Stolperfallen zu finden. Apple unterstützt sogar weiterhin OpenGL und OpenCL auf "Apple Silicon Macs" – nur bei OpenCL findet sich eine kleine Einschränkung: So lassen sich OpenCL-Compute-Programme nicht auf der CPU ausführen, sondern nur auf der GPU. Dies dürfte aber für die allermeisten Entwickler kein Problem darstellen.

Apple dokumentiert im Migration Guide diverse kleinere Unterschiede zwischen der x86- und der Apple-A-Architektur. So können zum Beispiel bestimmte Fließkommazahlenberechnungen anders ausfallen und der Datentyp BOOL verhält sich in Grenzfällen ebenfalls unterschiedlich.

In den allermeisten Fällen sollte die Portierung von bestehenden Apps mit minimalen Anpassungen möglich sein. Nur, wenn Assembler-Code für x86 verwendet wird, sind größere Maßnahmen notwendig. Dies dürfte aber nur in den wenigsten Apps der Fall sein, da mittlerweile Compiler einen so guten Job machen, dass sich manuelle Anpassungen in den meisten Fällen zeitlich nicht lohnen.

Alle Bestandteile vorhanden
Apple scheint mit macOS 11 Big Sur und der ARM-Umstellung keine Frameworks entfernt zu haben – dies macht das Portieren von bestehenden Apps deutlich einfacher, da in den meisten Fällen keine weitreichenden Code- oder gar Architektur-Änderungen erforderlich sind. Hätte Apple Bibliotheken über Bord geworfen, wäre der Umstieg auf macOS Big Sur und ARM-Macs für Entwickler eine deutlich größere Hürde.

Portierung von MacStammbaum
MacStammbaum ist ein komplexes Projekt und nutzt viele Apple-Technologien. Von CloudKit, SceneKit, Metal, OpenGL über MapsKit bis hin zu CoreData – fast das gesamte Apple-Ökosystem wird verwendet. Es stellt also fast den Worst-Case-Fall einer Migration dar – einmal abgesehen von x86-Assembler-Code, welcher sich nicht im Projekt wiederfindet.


Auf der Apple Developer Connection gibt es zwei unterschiedliche Xcode-Downloads: Einmal Xcode 12 mit Unterstützung für iOS 14, macOS Big Sur und watchOS 7. Ein anderer Download-Link führt zu Xcode 12 für Universal Apps. Diese Version bringt Unterstützung für das neue "Universal 2"-Format mit, welches ARM- und Intel-Codebestandteile in einer einzelnen App ermöglicht. Xcode 12 stellt das Projekt beim Öffnen so um, sodass die Standard-Architekturen "ARM" für macOS-Apps beinhalten:


Beim ersten Kompilierungsversuch gibt es noch eine Menge Warnungen, da Apple manche APIs mit macOS 11 Big Sur auf die Deprecation-Liste gesetzt hat – die meisten hiervon sind aber mit einer einfachen Umbenennung aus der Welt zu schaffen. MacStammbaum konnte, ohne jedwede Code-Änderung, als Universal-2-App kompiliert werden. Ausprobieren konnten wir das Resultat natürlich nicht – da wir noch keinen ARM-Mac haben. Mit größeren Schwierigkeiten ist aber nicht zu rechnen, trotzdem muss natürlich die gesamte App getestet werden, um mögliche Probleme zu erkennen. Das Kompilieren für Intel und ARM dauerte auf einem betagten 2014er MacBook Pro mit Intel i7 rund 5 Minuten – doppelt so lange wie nur für eine Architektur. Heraus kam eine App, welche auf Intel und "Apple Silicon" laufen soll:


Es ist damit zu rechnen, dass die allermeisten reinen Mac-Programme, welche sich im Mac App Store befinden oder außerhalb dessen zum Download angeboten werden, mit einem ähnlich geringen Aufwand angepasst werden können – daher ist die Zeitspanne, die Apple den Entwicklern gibt, ausreichend. Erste ARM-Macs sollen bereits in diesem Jahr auf den Markt kommen.