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

AppKit, Catalyst und SwiftUI: Welche UI-Frameworks Apple für die eigenen Apps nutzt

Carbon war neben dem neueren AppKit viele Jahre lang das Mittel der Wahl, wenn es um die Gestaltung der User Interfaces (UI) von Anwendungen für Notebooks und Desktops aus Cupertino ging. 2019 schob Apple das in die Jahre gekommene Framework aufs Altenteil und führte gleich zwei neue APIs für Bedienoberflächen ein: SwiftUI und Mac Catalyst. Letztere dient bekanntlich der Portierung von iOS-Apps, welche UIKit nutzen, auf macOS. Dieser Wandel sowie die damit teilweise verbundene Modernisierung spiegelten sich natürlich auch in Apples hauseigenen Apps wider, die das Unternehmen mit dem Mac-Betriebssystem ausliefert.


Entwickler analysiert Anteile von AppKit, Catalyst und SwiftUI
Der Entwickler Alexandre Colucci untersuchte jetzt, welche Frameworks der kalifornische Konzern für seine Anwendungen einsetzt. Dabei richtete er sein Augenmerk vornehmlich auf die Veränderungen, welche Apple seit dem Erscheinen von macOS Mojave vollzog und wie sich die Anteile von AppKit, Mac Catalyst und SwiftUI in den vergangenen Jahren entwickelten. Colucci beschränkte sich hierfür auf Apps, welche standardmäßig in macOS enthalten sind, darüber hinaus angebotene Software wie etwa Final Cut Pro oder Logic Pro waren nicht Gegenstand der Analyse, welche er in seinem Blog veröffentlichte.


Kleine Catalyst-Anfänge bereits in macOS Mojave
Die ersten Umstellungen erfolgten in macOS Mojave. Mac Catalyst befand sich 2018 noch in einer frühen Phase und lief Apple-intern unter dem Codenamen „Marzipan“. Entsprechend gering war die Zahl der Apps, welche das Unternehmen auf dieses Framework portierte: Lediglich Home, News, Aktien sowie Sprachmemos und somit gerade einmal ein Prozent der in macOS enthaltenen Anwendungen nutzten die neue Technologie. Diese stand damals übrigens Drittentwicklern noch nicht zur Verfügung und konnte nur von Apples eigenen Developern genutzt werden. Ähnlich zurückhaltend ging man in Cupertino bei macOS Catalina vor. Auf das nun offiziell verfügbare Mac Catalyst umgestellt wurden die Apps „Wo ist?“ und „Podcasts“ sowie der Picker in „Fotos“. Das neue SwiftUI verwendete Apple lediglich in der Kontakte-App. Die Prozentsätze veränderten sich im Vergleich zu macOS Mojave kaum.

macOS Big Sur beendet die Experimentierphase
Das änderte sich, als SwiftUI und Catalyst mit macOS Big Sur die Experimentierphase endgültig verließen. Vier weitere Apps, nämlich Karten, Nachrichten, Bildschirmzeit und das Wetter-Widget waren Portierungen von iOS-Anwendungen, SwiftUI hielt Einzug in sechs Programme. Dieser Trend setzte sich in macOS Monterey fort, in der derzeit noch aktuellen Version des Mac-Betriebssystems handelt es sich bei fünf Prozent aller Standard-Apps um SwiftUI-Anwendungen, vier Prozent fußen auf Catalyst. Während dieser Anteil im kommenden macOS Ventura nahezu gleich bleibt, macht SwiftUI einen großen Sprung auf zwölf Prozent. Berücksichtigt man die in /System/iOSSupport enthaltenen Binaries, bei denen es sich im Wesentlichen um iOS-Frameworks handelt, ergibt sich allerdings ein anderes Bild: Dann machen Catalyst-Anwendungen 20 Prozent aller mitgelieferten Apps aus, SwiftUI hat einen Anteil von 10 Prozent. Spitzenreiter ist aber nach wie vor AppKit, je nach Betrachtungsweise kommt dieses Framework auf 70 bis 85 Prozent.

Kommentare

Embrace22.08.22 17:20
In dem Zusammenhang sei auch die Kritik an den neuen Systemeinstellungen bei macOS Ventura erwähnt. Klar, ist noch Beta, aber da scheint aktuell bei SwiftUI noch einiges im Argen zu liegen.

Ich bin über Daring Fireball darauf aufmerksam geworden:
Dabei wird auf folgenden Twitterthread verwiesen:

Hier nur ein Screenshot (unter dem zweiten Link gibt es viele Videoschnipsel):

John Gruber
With AppKit, famously, it actually took extra work to make a basic UI look wrong. […]
If Apple can’t make professional-looking settings panels with SwiftUI, how can anyone be expected to?
+3
ttwm22.08.22 17:42
Den Fehler gibt es wohl (ist das auch bei jedem anderen Beta-Tester so?), aber selbst bei Apple weiß ich nicht, ob da nicht irgend etwas komplett schief gelaufen ist und in der internen Version das alles noch schön aussah. Genauso weiß ich nicht, aus welchem Grund der Fehler vorhanden ist – SwiftUI als Grund heranzuziehen scheint ja zum Teil schon sehr in Mode (ob das begründet ist, kann ich als Nicht-macOS-Entwickler natürlich nicht sagen, hab aber auch schon andere Meinungen gehört…)
0
gfhfkgfhfk22.08.22 17:54
Mir scheint im Artikel ist ein Fehler enthalten. Carbon wurde doch sehr viel früher zum alten Eisen gezählt, da es noch auf der ursprünglichen Mac Toolbox basierte. Apple hat jahrelang Cocoa als Mittel für die Applikationsentwicklung favorisiert.
+7
surangumal22.08.22 18:02
Der Herr fghfkgfhfk hat absolut Recht.

Siehe auch https://en.wikipedia.org/wiki/Carbon_(API)

"Apple did not create a 64-bit version of Carbon while updating their other frameworks in the 2007 time-frame, and eventually deprecated the entire API in OS X 10.8 Mountain Lion, which was released on July 24, 2012."
+3
milk
milk22.08.22 18:07
gfhfkgfhfk
Mir scheint im Artikel ist ein Fehler enthalten. Carbon wurde doch sehr viel früher zum alten Eisen gezählt, da es noch auf der ursprünglichen Mac Toolbox basierte. Apple hat jahrelang Cocoa als Mittel für die Applikationsentwicklung favorisiert.
Es geht aber um die Entwicklung von Interfaces. Was wirklich gemeint ist, das ist UIKit. Und das wurde durch SwiftUI nicht abgelöst sondern ergänzt.

Das Problem ist, und das sieht man an den neuen Apple UIs sehr gut: SwiftUI ist super für schnelle Prototypen, aber sobald man etwas ganz bestimmtes umsetzen möchte, kann man das in der Regel direkt vergessen und zu UIKit-Komponenten zurückgehen. Man kann UIKit und SwiftUI sehr frei mischen, aber in meiner Erfahrung macht das noch immer keinen Sinn. Ich jedenfalls verlasse mich auch heute noch zu 100% auf UIKit. Die neuen Swift Charts werden vermutlich das erste Modul, wofür ich dauerhaft SwiftUI einsetzen (müssen) werde, da es die nicht nativ in UIKit gibt.

Nachtrag: Am Mac heißt UIKit dann AppKit, man sieht hier, dass ich fast nur für iOS entwickle.
+3
Dupondt22.08.22 20:48
gfhfkgfhfk & surangumal:

Carbon spielte zwar allerspätestens seit 2012 keine Rolle mehr, war aber noch bis einschließlich Mojave in macOS enthalten. Aus Catalina entfernte Apple es dann 2019 endgültig, weil der Support für 32-Bit-Anwendungen entfiel.
-1
Christoph_M
Christoph_M23.08.22 09:40
Ich verstehe die Unterschiede nicht, bin aber kein Entwickler. Was ist jetzt Appkit und was ist SwiftUI? Bin jetzt verwirrter als ich es vorher war
0
matt.ludwig23.08.22 10:18
Christoph_M
Ich verstehe die Unterschiede nicht, bin aber kein Entwickler. Was ist jetzt Appkit und was ist SwiftUI? Bin jetzt verwirrter als ich es vorher war

Dann findest du hier schon mal grundlegende Infos




Und falls du es noch detaillierter wissen möchtest


+1
Weia
Weia23.08.22 13:53
Christoph_M
Ich verstehe die Unterschiede nicht, bin aber kein Entwickler.
Dann haben die Unterschiede aber doch auch keinerlei Relevanz für Dich?

Das sind, grob vergleichbar unterschiedlichen Programmiersprachen, verschiedene Werkzeuge, um grafische Nutzeroberflächen zu erstellen, und haben jeweils ihre Vor- und Nachteile.
🦖The dinosaurs invented Jesus to test our confidence in science
0
gfhfkgfhfk23.08.22 14:47
milk
Es geht aber um die Entwicklung von Interfaces. Was wirklich gemeint ist, das ist UIKit. Und das wurde durch SwiftUI nicht abgelöst sondern ergänzt.
Nein, aus dem Kontext ist erkennbar, dass das FrameWork für macOS gemeint war. Vor dem Merger mit NeXT hat Apple für den Macintosh die Mac Toolbox entwickelt. Diese war zuerst (System 1 bis 5 meines Wissens) in ObjectPascal (nicht mit der Borland Sprache gleichen Namens verwechseln) geschrieben. Es gab dann als FrameWork für die schnellere Applikationsentwicklung das ebenfalls ObjectPascal geschriebene FrameWork MacApp.

Meines Wissen erfolgte dann mit System 6 der Wechsel von ObjectPascal zu C für die Mac Toolbox und C++ für MacApp (Version 3). Es gab neben dem Apple eigenem FrameWork noch zwei weitere wichtige FrameWorks TCL (Think Class Library, als Bestandteil von Symantec C++ wesentlich nur 68k) und PowerPlant (Teil von Metrowerks CodeWarrior nur PowerPC).

Für A/UX wurde bereits eine Mac Toolbox entwickelt, die es erlaubt Mac Programme zu schreiben, die als UNIX Programme liefen, aber ein klassisches Mac GUI hatten. Dazu mussten einige Funktionen aus der Mac Toolbox entfernt werden.

Mit dem Merger von Apple und NeXT wurde das klassische MacOS beerdigt, und durch ein verändertes Openstep for Mach ersetzt, was zu MacOS X unbenannt wurde. NeXTSTEP, Openstep for Mach nutzen ein eigenes Framework für die Applikations Entwicklung, was bei neuen MacOS X in Cocoa umbenannt wurde. Openstep bzw. Cocoa war in Objective-C geschrieben.

Aus diesem Cocoa wurde dann bei der Portierung von MacOS X auf die iDevices UIKit und auf macOS/MacOS X wurde es irgend wann in AppKit unbenannt.

SwiftUI ist nun ein neues einheitliches Framework, um Apps für macOS und iOS schreiben zu können.

P.S. Mal wieder zu lang geworden, und ich hoffe es sind keine größeren Fehler drin.
+2
Unwindprotect24.08.22 10:53
gfhfkgfhfk
SwiftUI ist nun ein neues einheitliches Framework, um Apps für macOS und iOS schreiben zu können.

Und WatchOS und AppleTV
+1
macuser11
macuser1125.08.22 00:37
@gfhfkgfhfk
Stabile Geschichtsstunde 👍
0

Kommentieren

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