Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Portierung einer Mac-App auf "Apple Silicon" – am Beispiel von MacStammbaum

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.

Kommentare

netspy
netspy23.06.20 08:10
Danke für die Nachtschicht und den schnellen Bericht! Das macht Hoffnung, dass der Umstieg relativ einfach zu bewerkstelligen ist und uns Entwicklern nicht so viele Probleme wie befürchtet bereiten wird.
+13
jens-ulrich
jens-ulrich23.06.20 08:14
Solange der Softwarehersteller noch da ist und es so bewerkstelligen kann, ist alles gut. Aber es machen jedes Jahre Software-Buden zu, deren Programme, die man lieb gewonnen hat und mit denen viele eigene Projekte/Daten erstellt wurden, dann wieder auf der Strecke bleiben; siehe Abschalten von 32-bit. Es müsste eine Verpflichtung geben, daß dann der Code openSource wird.

Apropos 32-bit: Was passiert wohl, wenn man in macOS 11 versucht eine 32-bit-App zu installieren. Wird sie abgelehnt oder portiert? Letzteres wäre natürlich der Hammer
+1
deus-ex
deus-ex23.06.20 08:27
macOS ist doch seit dem jetzigen Release schon 64Bit only. Da geht jetzt schon nix mehr mit 32Bit. Hat mit ARM jetzt nichts zu tun.
+8
pünktchen
pünktchen23.06.20 08:27
jens-ulrich
Apropos 32-bit: Was passiert wohl, wenn man in macOS 11 versucht eine 32-bit-App zu installieren. Wird sie abgelehnt oder portiert? Letzteres wäre natürlich der Hammer

Na was meinst du wohl wozu die 32-bit Programme in Catalina rausflogen? Wohl kaum allein um die Intelversion von macOS zu verschlanken sondern auch um die Umstellung auf ARM /sorry, Apple Silicon / vorzubereiten.
+7
Marcel_75@work
Marcel_75@work23.06.20 08:31
Wäre interessant, wenn ihr in einem weiteren Artikel noch erwähnen könntet, welche APIs/Frameworks mit 10.11 Big Sur als 'deprecated' gekennzeichnet werden.
-1
tranquillity
tranquillity23.06.20 08:32
Es ist nicht 10.11, sondern 11.0 ...
+3
DTP
DTP23.06.20 08:32
MTN
[MacStammBaum] stellt also fast den Worst-Case-Fall einer Migration dar
Wie auch schon bei den letzten Plattformwechseln, ist der Worst Case ein eigenes User Interface, also Elemente, die der Entwickler selbst erstellt hat. Wie bei InDesign oder Photoshop. Daher dauert da die Portierung WESENTLICH länger als bei Apps, die (fast nur) UI-Elemente aus Apples Werkzeugkasten (Library) nehmen.
MTN
…daher ist die Zeitspanne, die Apple den Entwicklern gibt, ausreichend.
Weiß nicht, ob das so ist. Denn zum einen, sind ja meist Kunden nicht bereit, für eine Portierung zu zahlen. Und dann stellt doppelte Pflege (UI Elemente auf MacOS X und MacOS 11) eine zeitliche Herausforderung dar nicht nur für kleine Entwickler. Denn Testen ist ja nicht kostenlos (= ohne Zeitaufwand).

Ich sehe den Vorteil für mich als Kunden bei der ARM Umstellung noch nicht. Denn meine Macs werden nicht sonderlich heiß, sind schnell genug und auch die MacBook Pro's laufen i.d.R. lang genug. Ich bin gespannt, was genau Apple (an Hardware) vorstellen wird.
+1
chevron
chevron23.06.20 08:33
Wie verhält es sich mit der Applikationsgröße?
+2
RamUwe23.06.20 08:40
Im Moment interessiert mich eher, ob die Software später auch noch auf Intel-Macs laufen wird, v.a. wenn der Umstieg erfolgt ist.
+2
pünktchen
pünktchen23.06.20 08:41
Universal Binaries von PPC/X86 waren meist kaum grösser.
0
DTP
DTP23.06.20 08:43
RamUwe
Im Moment interessiert mich eher, ob die Software später auch noch auf Intel-Macs laufen wird, v.a. wenn der Umstieg erfolgt ist.
Das hängt davon ab:
Wenn der Entwickler sich den Aufwand macht, Universal Binaries zu pflegen, ja. Sonst nicht, da MacOS x86 keinen ARM Emulator wie Rosetta 2 bekommt (ja nur andersherum).
0
pünktchen
pünktchen23.06.20 08:43
RamUwe
Im Moment interessiert mich eher, ob die Software später auch noch auf Intel-Macs laufen wird, v.a. wenn der Umstieg erfolgt ist.

Ich denke das dürfte erst dann ein Problem werden wenn eine neue Version von macOS Intel nicht mehr unterstützt und sich die Entwickler zwischen neuen Möglichkeiten oder Rückwärtskompatibilität entscheiden müssen. Also vermutlich in drei Jahren.
0
RamUwe23.06.20 08:52
pünktchen
Ich denke das dürfte erst dann ein Problem werden wenn eine neue Version von macOS Intel nicht mehr unterstützt und sich die Entwickler zwischen neuen Möglichkeiten oder Rückwärtskompatibilität entscheiden müssen. Also vermutlich in drei Jahren.

Da würde die Leasingdauer unsere Mac Pros enden, den wir in diesen Tagen anschaffen wollten.

Ich meine, klar, kann man dann noch immer weiterarbeiten, wenn man nicht das neuste an Software benötigt. Doof ist es bei dem geplanten Investment trotzdem. Allerdings bin ich auch skeptisch, dass der nächste Mac Pro ARM so modular ist wie der jetzige.
+2
subjore23.06.20 09:38
Ich glaube nicht, dass die Entwickler sich so schnell entscheiden müssen. Apple selbst wird ja auch noch bestimmt bis 2025 ein Intel macOS ausliefern.
Warum sollten Entwickler in 3 Jahren die hälfte der Nutzerschaft ausschließen wollen?
Es kann natürlich sein, dass sie bei der Entwicklung neuer Programme sich auf die iPad/ ARM Mac Plattform konzentrieren wollen. Aber die Meisten Bibliotheken wird es trotzdem noch für x64 geben.
0
pünktchen
pünktchen23.06.20 09:47
RamUwe
Allerdings bin ich auch skeptisch, dass der nächste Mac Pro ARM so modular ist wie der jetzige.

Ich denke die werden bei der Entwicklung ARM schon mit im Blick gehabt haben. Der grösste Teil des MP ist doch eh eine PCI Erweiterungsbox mit passender Kühlung.
+3
gacki23.06.20 10:04
DTP
MTN
[MacStammBaum] stellt also fast den Worst-Case-Fall einer Migration dar
Wie auch schon bei den letzten Plattformwechseln, ist der Worst Case ein eigenes User Interface, also Elemente, die der Entwickler selbst erstellt hat.

Interessant wäre in diesem Zusammenhang auch, wie es sich mit externen UI- und anderen Frameworks verhält.
Wenn ich mich nicht täusche, greifen z.B. heute deutlich mehr Applikation auf Sachen wie Qt zurück.
Edit: Und die Frage nach Gerätetreibern steht auch im Raum.
0
Mendel Kucharzeck
Mendel Kucharzeck23.06.20 10:26
Weil es jetzt schon die dritte PM ist, die ich erhalte: Ja, MacStammbaum 9 wird aller Voraussicht nach ein kostenfreies Update für ARM-Macs zum Launch bekommen.
+7
hallo0223.06.20 10:50
Verstehe ich das richtig; Rosetta kommt nur zum Einsatz, wenn es sich um ein X86 only Programm handelt? Sprich, bei einem Universal Programm steht kompilierter Code nativ für X86 und A zur Verfügung?
Aber trotzdem können die besten Ergebnisse (voller Nutzen der A Architektur) in Zukunft nur erreicht werden, wenn ausschliesslich für A kompiliert wird?
Danke.
0
maliker23.06.20 10:51
Insgesamt vergessen aber viele, dass sich Entwickler auch mittelfristig nicht vor den neuen Plattform verschließen können. Gerade häufig sind zahlungskräftige Kunden diejenigen, die sich in regelmäßigen Abständen neue Geräte anschaffen. Wenn bei vielen Produkten die neue Unterstützung nicht da ist, hält es auch vom Kauf der Software ab.

Für viele Softwareentwickler von Pro-Tools natürlich ein schwieriges Spiel: Viele Pro-Apps brauchen deutlich länger für die Portierung. Aber auch das wird sich über die Zeit lösen lassen.
0
maliker23.06.20 10:52
hallo02
Verstehe ich das richtig; Rosetta kommt nur zum Einsatz, wenn es sich um ein X86 only Programm handelt? Sprich, bei einem Universal Programm steht kompilierter Code nativ für X86 und A zur Verfügung?
Aber trotzdem können die besten Ergebnisse (voller Nutzen der A Architektur) in Zukunft nur erreicht werden, wenn ausschliesslich für A kompiliert wird?
Danke.

Genau, ansonsten wird Rosetta nicht verwendet und der ARM-basierende Teil der Universal-Binary wird verwendet und nativ ausgeführt.
+2
subjore23.06.20 12:01
hallo02
Verstehe ich das richtig; Rosetta kommt nur zum Einsatz, wenn es sich um ein X86 only Programm handelt? Sprich, bei einem Universal Programm steht kompilierter Code nativ für X86 und A zur Verfügung?
Aber trotzdem können die besten Ergebnisse (voller Nutzen der A Architektur) in Zukunft nur erreicht werden, wenn ausschliesslich für A kompiliert wird?
Danke.
Nein, der volle Nutzen der A Architektur steht dir auch mit den Universellen Programmen zur Verfügung.
+2
zinne
zinne23.06.20 20:06
Hat jemand eine Ahnung was man mit Electron Apps machen müsste? Ich baue die mit einem npm-packager, da komme ich mit Xcode gar nicht in Berührung... vermutlich warten, bis es einen packager gibt der Apple Silicon unterstützt...
0
subjore24.06.20 00:50
zinne
Hat jemand eine Ahnung was man mit Electron Apps machen müsste? Ich baue die mit einem npm-packager, da komme ich mit Xcode gar nicht in Berührung... vermutlich warten, bis es einen packager gibt der Apple Silicon unterstützt...

Ja vermutlich. Du müsstest darauf warten, dass Elektron das unterstützt. Dann müsste der Rest eigentlich auch von alleine gehen. Das ist ja wie mit einem Browser. Wenn der Browser an die neue Architektur angepasst wird, können die Webseiten auch weiterhin wie vorher angezeigt werden.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.