Push-Nachrichten von MacTechNews.de

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

macOS High Sierra 10.13.4: Beta zeigt Warnung beim Start von 32-Bit-Apps

Der gestrige Abend stand im Zeichen der ersten Entwickler-Beta von iOS 11.3 mit den groß angekündigten Neuerungen für iPhone und iPad. Doch auch für die kommenden Systemversionen von macOS und tvOS verteilte Apple Testversionen an Entwickler. Die Beta von macOS 10.13.4 sticht dabei mit einem Warnhinweis hervor, der beim Start bestimmter Apps erscheint.

2018: Ende der 32-Bit-Ära auf dem Mac
Konkret werden Anwender mit einem Warnfenster konfrontiert, wenn sie eine App starten, die noch für 32-Bit-Prozessoren optimiert sind. Der Text darin bereitet sie auf das bereits angekündigte Schicksal dieser Apps vor, ab dem nächsten großen macOS-Update in diesem Herbst nicht mehr lauffähig zu sein.

Langsames Ausklingen
Apples Warnungen sind in macOS 10.13.4 noch sehr zurückhaltend. Die Warnung taucht lediglich beim ersten Start auf und lässt sich einfach wegklicken, spätere Starts enthalten sie nicht mehr. Doch Apple hat bereits angekündigt, ab der darauffolgenden Systemversion 10.13.5 deutlich aggressiver darauf hinzuweisen, damit das Ende ab macOS 10.14 für niemanden mehr eine Überraschung darstellt.

Seit diesem Monat keine neuen 32-Bit-Apps mehr im Mac App Store erlaubt
Das Vorgehen auf dem Mac reflektiert Apples Maßnahmen auf iOS. Bevor 32-Bit-Apps dort mit iOS 11 stillgelegt wurden, zeigten die letzten Versionen von iOS 10 ebenfalls immer wieder jene Warnung an. Nutzer sollen sich alsbald nach einer Alternative für diese Programme und App umschauen oder den Entwickler um baldige Updates mit Optimierung für 64-Bit-Prozessoren drängen. Eingetragene Entwickler dürfen seit diesem Monat keine neuen 32-Bit-Apps mehr in den Mac App Store einreichen. Ab Juni dieses Jahres müssen auch sämtliche Updates der bestehenden Apps 64-Bit-fähig sein.

Beim Mac ist Apple sehr viel weniger restriktiv als bei iOS. Immerhin folgt das Ende von 32 Bit auf der Computer-Plattform erst geschlagene 12 Jahre, nachdem die Macs auf 64-Bit-Prozessoren umgestiegen sind. Die von Apple stets gebrauchte Formulierung, macOS High Sierra sei das letzte macOS, welches 32-Bit-Apps »ohne Kompromisse« unterstütze, lässt semantisch sogar noch die Möglichkeit offen, dass auch macOS 10.14 über Umwege mit 32-Bit-Apps zurechtkommt.

Kurz: 5G-Netze noch mit sehr wenigen Nutzern ++...

Vor 30 Jahren: Apple holt Sanierer – kann das s...

Kopplung "iPhone + Apple Watch" sowie Anbindung...

Apples interne Einschätzung: Zwei Jahre Rücksta...

Mac mini M4: Reparaturhandbuch bestätigt austau...

iPhone 16 Pro: Erfahrungen

Aufpreise, Vergleich zu M3 und Spezifikationen:...

Mac mini M4 im ersten Test: Was hält der kleine...

Kommentare

nane25.01.18 09:15

Die Apple Menschen schaffen es wirklich, Zweifel und Zurückhaltung statt Begeisterung und Vorfreude auf ein neues Mac OS zu wecken.

Das Leben ist ein langer Traum, an dessen Ende kein Wecker klingelt.

Mendel Kucharzeck25.01.18 09:18

nane
Apple muss dafür sorgen, dass man nicht zu viele Altlasten mit sich rumschleppt - alle APIs in 32- und 64-Bit-Form zu pflegen ist mit Sicherheit Aufwand und auch mit einigen technischen Hürden verbunden. Seit 10.6 lassen sich ohne große Schwierigkeiten 64-Bit-Apps bauen, außer wenn der Entwickler ebenfalls eine Menge von Altlasten mit sich rumschleppt.

nane25.01.18 09:22

Mendel Kucharzeck
ja, absolut richtig. Wir werden jetzt alle eine Runde "weinen" auf hohem Niveau und dann doch wieder begeistert auf die neue Version updaten. Apple wird sicher ein paar "must have" Kracher einbauen. Also eigentlich wie immer

Das Leben ist ein langer Traum, an dessen Ende kein Wecker klingelt.

-2

andreas6325.01.18 09:22

Nun bei den Apps kann man oft auf 64 Bit gehen. Ganz anders bei Treibern - wie zB. USB SCanner Treiber die oft noch 32 Bit sind jedoch bisher auch unter High Sierra noch arbeiten.

Mendel Kucharzeck25.01.18 09:27

andreas63
Meinst du KEXTs? Die müssen doch jetzt schon 64 Bit sein - der Kernel kann doch nicht 32 und 64 Bit KEXTs mischen wenn ich mich nicht vertue?

NikNik25.01.18 09:29

Mendel Kucharzeck

alle APIs in 32- und 64-Bit-Form zu pflegen ist mit Sicherheit Aufwand und auch mit einigen technischen Hürden verbunden.

Ist es nicht. Der Aufwand beschränkt sich auf "einmal neu kompilieren". Alle "stressigen" APIs hat Apple schon vor Jahren entfernt. Es gibt, außer dass Apple Geld sparen will, keinen Grund den kompletten 32bit Support rauszuwerfen.

Schau dir mal Debian an. Die "pflegen" nicht nur 32bit und 64bit, sondern auch dazu noch ARM, PPC und MIPS. Und die sind kein Multimilliarden-Dollar Unternehmen.

Lefteous25.01.18 09:29

Manche geschäftskritische Anwendungen sind eben nun mal leider 32 Bit.

Stereotype25.01.18 09:32

nane

Die Apple Menschen schaffen es wirklich, Zweifel und Zurückhaltung statt Begeisterung und Vorfreude auf ein neues Mac OS zu wecken.

Wenn du so sehr unter Zweifel und Zurückhaltung leidest, solltest du das mal überdenken und etwas dagegen unternehmen.

-5

nane25.01.18 09:39

Stereotype

Wenn du so sehr unter Zweifel und Zurückhaltung leidest, solltest du das mal überdenken und etwas dagegen unternehmen.

Ja, ich lese immer die Kommentare hier und dann ist wieder alles gut

Das Leben ist ein langer Traum, an dessen Ende kein Wecker klingelt.

sonorman25.01.18 09:40

Noch ein Grund mehr, den Abschied von InDesign CS6 zu beschleunigen.
Hoffentlich kommt bald Affinity Publisher. Und hoffentlich ist es brauchbar!

UWS25.01.18 09:55

nane

Apple wird sicher ein paar "must have" Kracher einbauen. Also eigentlich wie immer

Und welche waren das z.B. bei den letzten beiden, Sierra und High Sierra? Oder habe ich die Ironie übersehen?

There is no cloud…it’s just someone else’s computer.

Mendel Kucharzeck25.01.18 10:01

NikNik
Natürlich ist das großer Aufwand, das zu pflegen. In einfachen Anwendungen ist es mit einer Neukompilierung getan - sobald aber beispielsweise Pointer-Arithmetik dazukommt, wird's schon schwerer. Für Apple sind aber die Probleme wahrscheinlich anderer Natur - 32-Bit-Apps auf einem 64-Bit-Kernel auszuführen ist kein triviales Unterfangen, besonders wenn noch Helfer-Prozesse hinzukommen, die die Fähigkeit haben müssen, mit 32-Bit und 64-Bit-Apps reden zu müssen.

steve.it25.01.18 10:21

NikNik

Schau dir mal Debian an. Die "pflegen" nicht nur 32bit und 64bit, sondern auch dazu noch ARM, PPC und MIPS. Und die sind kein Multimilliarden-Dollar Unternehmen.

Das ist richtig. Aber schau Dir mal an, was für Qualitätsprobleme Apple bei der Software hat. Ja, das ist peinlich.
In dem Zuge ist es mir lieber, wenn dann 32 Bit weg fällt und darauf keine Ressourcen mehr fallen.

Mich persönlich betrifft das AFAIK auch ohnehin nicht. Ich nutze schon lange nur noch 64 Bit Apps (einzige Ausnahme ist evtl. die Kindle-App, die das letzte mal, als ich geschaut hatte, noch in 32 Bit vorlag - erwarte von Amazon ein Update, sofern noch nicht geschehen).

Beim Mac erwarte ich mir auch, dass alte Zöpfe, die nicht mehr benötigt werden, abgeschnitten werden.
Welche Software liegt denn nicht in 64 Bit vor:
- alte Software, wo das Update auf die neue Version gescheut wird (häufig aus finanziellen Interessen). (= Pech)
- nicht mehr gepflegte Software (= Pech)
- aktuelle Software, bei der der Entwickler sich nicht bewegt (=> vermutlich Ausnahme).

Kann ein aktueller Apple A11 überhaupt noch 32 Bit ausführen? Würde mich nicht wundern, wenn das ein reiner 64 Bit SoC ist. Und falls dann in Zukunft mal Apple in Macs ARMs verwenden sollte (als Haupt-CPU) oder sich die Möglichkeit offenhalten möchte, wäre das in dem Fall auch schon mal ein Schritt.

-2

nane25.01.18 10:26

UWS

Und welche waren das z.B. bei den letzten beiden, Sierra und High Sierra? Oder habe ich die Ironie übersehen?

APFS, Siri, Tabs, Bild-in-Bild, automatisches entsperren, iCloud Drive...
Klar, nicht für alle entscheidend, aber vielleicht doch interessant für viele.

Das Leben ist ein langer Traum, an dessen Ende kein Wecker klingelt.

MikeMuc25.01.18 10:30

UWS

nane

Apple wird sicher ein paar "must have" Kracher einbauen. Also eigentlich wie immer

Und welche waren das z.B. bei den letzten beiden, Sierra und High Sierra? Oder habe ich die Ironie übersehen?

Ich lege noch ein paar Systeme mehr drauf. Der Spielkram seit 10.7. ist mir völlig schnurz. Den ganzen Cloudkrempel brauch ich bei der Arbeit nicht. Und Adobe hat nun auch seit langem keine Riesen Schritte bei Indesign gemacht. Zumindest nix was mir von Vorteil gereicht.
Mir würden die Sicherheitupdates für 10.6 reichen

sunni25.01.18 10:40

MikeMuc

Mir würden die Sicherheitupdates für 10.6 reichen

Mac OS X 10.6 ist das Windows XP von Apple. Hält sich ewig.
Ich hab auch noch 10.6er als Server auf einem Mac mini von 2007 oder 2008 am laufen.

stefan25.01.18 10:54

NikNik

Schau dir mal Debian an. Die "pflegen" nicht nur 32bit und 64bit, sondern auch dazu noch ARM, PPC und MIPS. Und die sind kein Multimilliarden-Dollar Unternehmen.

Die verkaufen aber auch keine Hardware, zu der sie das Betriebssystem ohne weitere Kosten mitgeben.
Es gab solche Übergänge schon mehrmals: 68k PowerPC, PowerPCIntel, OS 9 OSX, und jedesmal gab es auch eine Übergangszeit, in der es möglich war, die Software weiter zu nutzen, und in der die Entwickler sie umstellen konnten. Daher verstehe ich die Aufregung nicht. Fortschritt hat immer etwas damit zu tun, dass man Altes hinter sich lässt. Und 64bit ist keine Zukunft mehr, sondern schon lange Standard.

Leider muss ich momentan auch noch mit 32bit Software arbeiten und bin daher auch auf die älteren Systemversionen angewiesen.

NikNik25.01.18 11:03

Mendel Kucharzeck

Sorry, nimm es bitte nicht persönlich, aber das ist schlicht die alte Leier die bei dem Thema immer wieder runtergebetet wird. Sie wird durch ständige Wiederholung nicht richtiger. Natürlich geht 32bit Anwendungen auf 64bit Systemen nicht "einfach" so. Aber sobald die entsprechenden Elemente vorhanden sind, wie sie ja nun sind, ist der nachfolgende Aufwand gering. Auch Inter-Prozess-Kommunikation ist keine Hürde, da man dort erst recht keine Adresszeiger austauscht, sondern normale Daten. Das geht anders gar nicht.

Fast der kompletten Open Source Welt ist es vollkommen egal auf welcher Bitbreite und welcher Architektur eine Anwendung läuft. Auch geht dort nicht mit jedem zweiten OS-Update die Abwärtskompatibilität flöten. Und auch hier beklagt niemand die enormen Aufwände die angeblich vorhanden sind.

Sorry, da braucht mir niemand erzählen, dass es bei Apple angeblich zuviel Aufwand ist. Apple will einfach nicht, auf Kosten der Kunden.

Smallersen25.01.18 11:20

Tja, da werde ich noch viele Jahre auf High Sierra kleben bleiben - ich könnte mein Geschäft ohne 32 Bit Apps schließen. Bei vielen ist kein Nachfolger oder Update in Sicht - anderes zu benutzen wäre eine deutliche Verschlechterung bzw. es gibt quasi keine Alternativen. Das sind mindestens 20-30 fundamentale Programme bei mir.
Erstaunlich, dass sogar aktuelle Adobe Programme teils noch 32 Bit sind. Deshalb kann ich den Wechsel für 10.14 noch nicht so recht glauben.

Das wären ansonsten wirklich schlechte Nachrichten.

Mendel Kucharzeck25.01.18 11:25

NikNik
Nimms auch nicht persönlich bitte, aber es stimmt nicht was du sagst. Mittels Inter-Process-Communication tauscht man öfters auch Speicherbereiche aus, z.B. den Speicherbereich eines Structs (beispielsweise einen Header, der vor einem größeren Daten-Blob liegt). Dort ist es einfach mistig, wenn du das Struct einmal als 32-bit-Variante und 64-bit-Variante handlen musst im XPC-Helper.

Der Vergleich mit der Open-Source-Welt hinkt auch: Es ist richtig, dass du dort ein komplettes Betriebssystem meist in 32-bit oder 64-bit-Variante bekommst oder selbst kompilierst. Auch Programme, die du selbst kompilierst, kannst du meist auf 32- oder 64-Bit-Systemen ausführen - nur das Ausführen einer 32-Bit-App auf einem 64-Bit-Kernel oder umgekehrt stellt oft Hürden dar.

NikNik25.01.18 11:40

Mendel Kucharzeck

nur das Ausführen einer 32-Bit-App auf einem 64-Bit-Kernel oder umgekehrt stellt oft Hürden dar.

Tut es eben einfach gar nicht. Es gibt keine "Hürden" bei der Ausführung von 32bit Anwendungen auf einem 64bit OS. Der Kern lädt einfach die 32bit-Varianten der benötigten Bibliotheken und gut ist. Apple will diese einfach nur nicht mehr erstellen und mitliefern.

Dass Apples APIs stellenweise bescheiden sind, ist bekannt. Aber genauso wie Apples OpenGL Implementierung einfach lachhaft ist, ist hier ebenfalls nicht die Lösung "dann schmeißen wir es eben weg und streichen es ersatzlos". Und es geht hier auch nicht darum eine Anwendung zu erstellen die gegen Apples krude API 32bit und 64bit kompilierbar ist, sondern schlicht darum, dass einfach mal funktionierende Software weiterhin funktioniert und nicht künstlich blockiert wird. Zukünftige Software darf gerne 64bit only sein.

Die Open Source Welt verschenkt ihre Software und kriegt es portabler, stabiler und funktionsreicher hin als Apple, aber Apple streicht ein Feature nach dem anderen und und nennt es Fortschritt.

AMD wurde letztens erst dafür zusammengestaucht, weil ihr neuer Treiber unter Windows nicht mit einigen DX9 Titeln funktionierte. Hier wird einfach mal der komplette Support für alles gestrichen.

Mendel Kucharzeck25.01.18 11:57

NikNik

Ich glaube du über-simplifizierst das ganz gewaltig. Die Libraries haben ja eine Menge Abhängigkeiten - sie reden zum Beispiel mit dem Kernel oder XPC-Helpern. Überall musst du darauf achten und weichen einbauen, ob du gerade mit 32-Bit oder 64-Bit-Version redest.

Ein Punkt der Kritik ist aber meines Erachtens nach richtig an Apple: Die setzen Entwickler ganz schon unter Druck. Natürlich halten sie ihr System sauber, in dem sie sich schnell von Legacy-Zeugs verabschieden - allerdings bedeutet das für Entwickler, dass öfters mal ein komplettes Rewrite der Software ansteht. Ein Konkurrent unserer Software MacStammbaum, Reunion, ist zum Beispiel noch Carbon - wird also nicht als 64-Bit-App erscheinen können ohne fast kompletten Rewrite.

NikNik25.01.18 12:24

Mendel Kucharzeck

Ein Kernel funktioniert im Großen und Ganzen getrennt von der auszuführenden Software. Er stellt nur einen Set an APIs bereit, die eine Anwendung (in dem Fall hauptsächlich die C-Library) benutzen kann. In Linux z.B. hat sich diese API seit Kernel 2.4 nicht verringert. Es sind Funktionen hinzu gekommen, aber es wurde keine gestrichen. Jegliche alte Software läuft weiterhin.

Im Userland ist die Sache noch einfacher. Ja, GTK3 ist nicht zu GTK2 kompatibel. Macht ja nichts. Liefert man einfach GTK2 mit und fertig ist die Sache. Ja, libpng 1.4 ist auch nicht mehr kompatibel zu libpng 1.2... na und? Liefert man eben libpng1.2 mit. Funktioniert auch, kann jeder kostenlos ausprobieren.

Der Mythos ist hier einfach, dass Apple irgendwelche Probleme damit hätte, oder ihr System "sauber halten" würde. Die meisten Probleme löst ein Compiler und/oder eine vernünftige API.

Apple spart sich eben minimalen Aufwand bei maximalem Schaden beim Kunden. Windows und Linux könnten sich nie erlauben dem Entwickler zu sagen: "Schreibe mal deine Anwendung komplett neu, ich führe das nicht mehr aus". Kleinere Anpassungen OK, aber das was Apple hier abzieht ist um Dimensionen größer.

steve.it25.01.18 12:26

NikNik

Bis auf den Punkt, dass die extra 32 Libs erst geladen werden müssen und auch Ram verbrauchen. Klar, das ist vernachlässigbar.
Bei Microsoft Windows ist diese 32 Bit Thema übrigens anders und eleganter mittels
WOW64 gelöst.
https://de.wikipedia.org/wiki/WOW64

NikNik

Apple will diese einfach nur nicht mehr erstellen und mitliefern.

Ja, genau so sieht es aus. Finde es aber dennoch gut, was Apple macht. Auf einem Mac möchte ich ungern Altlasten haben, insb. wenn die nicht mehr benötigt werden (dass es offenbar noch Programme gibt, die immer noch nicht in 64 Bit vorliegen - nach Jahren - und der ein oder andere diese offenbar noch benötigt ist eine andere Geschichte).

Wie ich schon schrieb: Kann Apple A11 überhaupt noch 32 Bit Programme ausführen oder ist dies ein reiner 64 Bit SoC? Dies könnte auch die Entscheidung bei Apple beeinflussen, falls man mit dem Gedanken spielt evtl. macOS auf eigene SoCs umzustellen.

NikNik

Im Userland ist die Sache noch einfacher. Ja, GTK3 ist nicht zu GTK2 kompatibel. Macht ja nichts. Liefert man einfach GTK2 mit und fertig ist die Sache. Ja, libpng 1.4 ist auch nicht mehr kompatibel zu libpng 1.2... na und? Liefert man eben libpng1.2 mit. Funktioniert auch, kann jeder kostenlos ausprobieren.

Trotzdem machen das viele Linuxer ungern. Besonders schön wird es, wenn wegen einer Anwendung ein halbes KDE installiert werden muss.

Klar, das geht alles. Bei Apple hat man aber eine andere Philosophie und will Wildwuchs vermeiden (finde ich im Fall vom Mac gut).

Mendel Kucharzeck25.01.18 12:40

NikNik

Ich muss dir hoffentlich nicht erklären, was das Problem an solchen Konstellationen ist, oder?

steve.it25.01.18 12:51

OT:
AFAIK kann Windows für ARM "nur" x86 (32 Bit) emulieren - also "nur" 32 Bit Windows-Programme ausführen. Kann sein, dass der Grund dafür eine Lizenzgeschichte ist. Keine Ahnung.
Jedenfalls verlängert Microsoft durch diesen Move das Leben von 32 Bit Anwendungen im Jahr 2018 .

NikNik25.01.18 12:58

Mendel Kucharzeck

Ich muss dir hoffentlich nicht erklären, was das Problem an solchen Konstellationen ist, oder?

Das Problem, dass man ggf. teuer gekaufte Software verliert und ggf. neu kaufen muss ist wesentlich größer als "Ich hab da noch eine alte Library auf dem System installiert". Dieser vorgetäuschte Sauberkeitsfimmel ist rein künstlich und hat keinerlei technische Grundlage oder Bewandtnis. Ein installiertes GTK2 stört ein installiertes GTK3 in keinerlei Art und Weise.

Klar wünscht sich das auch ein Linux-User nicht, so viel installiert zu haben, aber es wird ihm nicht aufdiktiert, ihm werden keine Sicherheitsupdates vorenthalten und ihm wird auch nicht mal eben die halbe Steam-Library unbrauchbar gemacht, auch wenn die 32bit Anwendung gar keine großartigen Bibliotheken benutzt.

steve.it25.01.18 13:07

Mit der Argumentation wird man nie alten Kram los, da es immer User gibt, die noch uralt-Software einsetzen. Es ist nicht so, dass es erst seit gestern 64 Bit Software bei macOS gibt.
Ich bin z.B. extrem froh, dieses Carbon-CFM-Zeug los zu sein. Hier hätte man auch so argumentieren können. Wurde auch. Klar, das ist nicht 100 Prozent vergleichbar.

NikNik25.01.18 13:12

steve.it

Mit der Argumentation wird man nie alten Kram los, da es immer User gibt, die noch uralt-Software einsetzen.

Microsoft löst das Problem z.B. indem sie den alten Kram nicht mitinstallieren und die Anwendung zwar im Standard nicht startet, aber du bist jederzeit in der Lage noch alte Versionen von .NET oder alte C-Libraries nachzuinstallieren. Linux indirekt ebenso.

Jeder User kriegt hier ein "sauberes" System, aber der der es wirklich noch braucht, darf weiterhin sein System "vollmüllen".

Apple schiebt einfach allem ein Riegel vor, egal wie und warum.

Mendel Kucharzeck25.01.18 13:14

NikNik

Dieser vorgetäuschte Sauberkeitsfimmel ist rein künstlich und hat keinerlei technische Grundlage oder Bewandtnis.

Ich glaub wir sollten unsere Unterhaltung hier beenden, einig werden wir uns nicht. Ich bin nicht sicher ob du selbst Programmierer bist oder nicht. Falls ja, bitte zeig mir deinen Code nicht

-1

Weitere News-Kommentare anzeigen

macOS High Sierra 10.13.4: Beta zeigt Warnung beim Start von 32-Bit-Apps

Kommentare

Kommentieren

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