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

Apple blockiert UTM – nicht nur im App Store, sondern auch in Drittanbieter-Stores

Vielen ist das kostenfreie und quelloffene UTM ein Begriff: Mit der auf QEMU basierenden App lassen sich einfach Virtuelle Maschinen oder Emulationsumgebungen starten und somit beispielsweise Windows für x86 oder ARM auf dem Mac nutzen. Nicht nur aktuelle Windows-Varianten, sondern auch Windows 95 oder 98 lassen sich ohne großen Aufwand verwenden. UTM steht auf der Webseite wie auch im Mac App Store zum Download bereit. Von der Homepage ist der Download kostenlos – wer aber die Entwickler unterstützen möchte, kauft die App für 10 Euro im Mac App Store.


UTM steht auch für iPad und iPhone zur Verfügung – jedoch sind hier einige Hürden zu überwinden, um die App zum Laufen zu bekommen, denn im App Store ist UTM nicht zu finden. Der Grund ist, dass Apple in der Vergangenheit keinerlei Emulations- oder Virtualisierungslösungen im App Store für iPhone und iPad zugelassen hat.

Regeländerung
Im April 2024 vollzog Apple jedoch eine Änderung der Regeln im App Store: Ab sofort waren Retro-Emulatoren im App Store geduldet, um zum Beispiel Spiele für Nintendo-, Sony- und Sega-Konsolen auf dem iPhone oder iPad auszuführen. Natürlich machten sich die Hersteller von UTM sofort Hoffnungen, dass der Konzern auch UTM, welches oftmals für ältere Computerspiele genutzt wird, im offiziellen App Store zulässt. Doch leider schaltete Apple und auch das Apple Review Board auf stur und begründete die Ablehnung mit der Aussage, dass ein PC keine Spiele-Konsole sei:


Dies ist insofern noch nachvollziehbar, da sich mittels UTM ein komplettes Computer-Betriebssystem virtualisieren oder emulieren lässt. Nicht verständlich ist jedoch, warum UTM auch nicht in alternativen App Stores gestattet ist:

Regel 4.7 gilt nicht für alternative App Stores
Im April passte Apple die Regel 4.7 im App Store an – und erlaubte wie zuvor geschrieben Konsolen-Emulatoren. Die App Store Review Guidelines beziehen sich auf den App Store – und eine klar definierte Untermenge der Regeln auf alternative App Stores. Regel 4.7 gilt aber nur im App Store, nicht für alternative App Stores – doch trotzdem lehnte Apple auch die Freigabe von UTM für alternative App Stores ab.

Ohne JIT
Jedoch wäre, selbst wenn Apple UTM freigegeben hätte, die Geschwindigkeit deutlich reduziert, da Apple keine Apps mit integrierten Just-In-Time-Compilern im App Store erlaubt. Die Entwickler von UTM wollen Apples Entscheidung deshalb akzeptieren, da UTM ohne JIT aufgrund der mangelhaften Performance sowieso keine gute Nutzererfahrung bieten würde.

Kommentare

MikeMuc10.06.24 09:06
Gibt es nicht für IOS dies „ Playgrounds for Swift“? Das muß doch auch einen Irgendwie gearteten Compiler beinhalten. Falls ja, warum darf Apple und andere nicht?
0
janstolle10.06.24 09:14
Dort wird nur die Anwendung selbst einmal vollständig kompiliert. Die Just In Time Compilation funktioniert anders.
+2
Marcel Bresink10.06.24 09:31
MikeMuc
Das muß doch auch einen Irgendwie gearteten Compiler beinhalten. Falls ja, warum darf Apple und andere nicht?

So gut wie alle Apps von Apple verstoßen gegen die App Store-Regeln und dürften eigentlich nicht angeboten werden. Aber Apple nimmt sich selbst von allen Regeln aus.

Das ist einer der Hauptgründe, warum der App Store so enorm wettbewerbsverzerrend ist. Besonders in den USA dürfte das noch viel Ärger für Apple geben.
+7
deus-ex
deus-ex10.06.24 09:34
MikeMuc
Gibt es nicht für IOS dies „ Playgrounds for Swift“? Das muß doch auch einen Irgendwie gearteten Compiler beinhalten. Falls ja, warum darf Apple und andere nicht?

Weil der Compiler von Apple selbst kommt und somit von Apple kontrolliert wird. 3rd Party Compiler können Sicherheitslücken beinhalten bzw. Sicherheitslücken ausnutzen. Und Apple hat keine Kontrolle über diese. Ein Jailbreak ist mit einem JIT problemlos möglich und öffnet halt auch Tür und Tor für Kriminelle.
+5
ssb
ssb10.06.24 10:38
Deswegen wird auch nie ein iPad meinen Mac ersetzen - da ich beruflich leider viel mit Windows arbeiten muss und das auf einem M1 per UTM und Win11ARM mache.

Ist nicht der einzige Grund - auch der fehlende Zugriff auf das Dateisystem, kein Xcode etc. (und ich mag Swift einfach nicht) und nicht zuletzt das Fehler von mehreren Benutzern. Ich nutze mein iPad viel, aber eben nicht beruflich - dafür braucht es noch immer einen Mac.
+1
Marcel Bresink10.06.24 10:39
deus-ex
Weil der Compiler von Apple selbst kommt und somit von Apple kontrolliert wird.

Nein, das mag sich für den Laien vielleicht plausibel anhören, ist aber technisch gesehen Nonsens.

Ein Compiler, der funktioniert, erzeugt Programme, die grundsätzlich "Turing-mächtig" sind, völlig egal, wer ihn hergestellt oder unter Kontrolle hat. Der Funktionsumfang der entstehenden Programme wird in Wirklichkeit durch das SDK und die spätere Sandbox-Umgebung des laufenden Betriebssystems bestimmt. Für einen Jailbreak braucht man eine bereits vorher existierende Sicherheitslücke im Betriebssystem, wobei keine Rolle spielt, mit welchem Compiler man ein Programm erstellt, das diese Lücke ausnutzt.
+5
deus-ex
deus-ex10.06.24 11:21
Marcel Bresink
deus-ex
Weil der Compiler von Apple selbst kommt und somit von Apple kontrolliert wird.

Nein, das mag sich für den Laien vielleicht plausibel anhören, ist aber technisch gesehen Nonsens.

Ein Compiler, der funktioniert, erzeugt Programme, die grundsätzlich "Turing-mächtig" sind, völlig egal, wer ihn hergestellt oder unter Kontrolle hat. Der Funktionsumfang der entstehenden Programme wird in Wirklichkeit durch das SDK und die spätere Sandbox-Umgebung des laufenden Betriebssystems bestimmt. Für einen Jailbreak braucht man eine bereits vorher existierende Sicherheitslücke im Betriebssystem, wobei keine Rolle spielt, mit welchem Compiler man ein Programm erstellt, das diese Lücke ausnutzt.
Ich rede ja nicht davon dass das fertig kompilierte Programm eine Lücke ausnutzt, sondern der Compiler selbst eine Lücke hat die während des Kompilierprozesses ausgenutzt werden kann.
Gerade JIT Compiler sind für so etwas anfällig. Der Swift compiler in Playgrounds oder XCode ist ja kein JIT.
+2
ssb
ssb10.06.24 13:01
deus-ex
Der Swift compiler in Playgrounds oder XCode ist ja kein JIT.
Da wäre ich mir gar nicht mal so sicher - das basiert ja alles auf LLVM/clang und für eine final gelinkte (nicht ge-JIT-tette Anwendung) bräuchte man das komplette Framework in einer Version, die gelinkt werden kann und auch jedes Mal gelinkt wird. Da ich kein Freund von Swift bin, habe ich das noch nicht ernsthaft mit größeren Projekten probiert - aber ich kann mir gut vorstellen, dass Playgrounds "nur" LLVM-IR erzeugt und den per LLVM-JIT ausführt - einfach auch, weil es schneller geht.

Ansonsten nutzen auch einige Konsolen-Emulatoren am Ende QEMU zur Virtualisierung. Da könnte man die Begründung, UTM nicht zuzulassen weil es keine Konsole sondern einen PC emuliert, schon hinterfragen

Aber das sind Details - am Ende wird (aus Sicht von Apple) fremder Code irgendwie ausgeführt und in Playgrounds ist das erlaubt in QEMU aber nicht. Für Win11ARM in UTM bräuchte man auch gar keinen JIT, der Code kann ja nativ ausgeführt werden. Da dürfte mehr das Fehlen des Hypervisor-Frameworks zum Problem werden, weswegen UTM das auf iOS/iPadOS nicht nutzen kann.

Gefühlt dürfte es mehr darum gehen, dass Apple nicht möchte, dass man unter iOS/iPadOS Windows ausführen kann. Oder gar macOS.
+1

Kommentieren

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