Free Press

Die Cocoa-Plattform wird jetzt durch vier verschiedene Varianten oder Unterplattformen repräsentiert, mit den SDKs für macOS, iOS/iPadOS, watchOS und tvOS. Jedes SDK besteht aus einzelnen Bibliotheken, die üblicherweise als „Frameworks“ bezeichnet werden.

Auf der Objective-C-Seite ist jedes Framework ein Bundle mit der Erweiterung .framework, das sowohl Binärdateien (.dylib, vergleichbar mit .dll unter Windows) als auch Objective-C-Header-Dateien enthält. Für Elements wird jedes Framework im SDK durch eine .fx-Datei repräsentiert, die alle Metadaten aus den Headern zusammenfasst, um sie für den Elements-Compiler einfacher und schneller zu verarbeiten.

Elements wird mit vorgefertigten .fx-Dateien für alle Frameworks in den Standard-SDKs von Apple geliefert, die mit den neuesten Versionen der vier SDKs ausgeliefert werden (sowie für ausgewählte ältere Versionen).

Eine vollständige Liste aller Frameworks finden Sie in den Listen unten. Sie werden sehen, dass viele der Frameworks von einigen oder sogar allen SDKs gemeinsam genutzt werden und eine umfangreiche Bibliothek von Klassen bereitstellen, mit denen Sie Code schreiben können, der für alle Unterplattformen kompiliert und gemeinsam genutzt werden kann, während jedes SDK auch eine beträchtliche Anzahl von Frameworks bereitstellt, die plattformspezifisch sind.

• Alle macOS SDK-Frameworks
• Alle iOS SDK-Frameworks
• Alle tvOS SDK-Frameworks
• Alle watchOS SDK-Frameworks
• Alle Mac Catalyst-Frameworks

Schauen wir uns einige dieser Frameworks genauer an.

Foundation

Das wohl wichtigste Framework für jede Cocoa-Anwendung ist das Foundation-Framework, da es – wie der Name schon sagt – einen Großteil der Basisklassen bereitstellt, aus denen eine Anwendung auf der Objective-C-Laufzeitumgebung besteht. Dazu gehören die meisten Standardklassen mit NS*-Präfixen (abgesehen von GUI-Klassen, mehr dazu weiter unten), von einfachen und essentiellen Typen wie NSString, NSArray und dergleichen bis hin zu Klassen, die den Zugriff auf zentrale Betriebssystemdienste ermöglichen, wie NSFileManager für den Festplattenzugriff, NSNotificationCenter für die Arbeit mit Benachrichtigungen, NSURL*-Klassen für die Arbeit mit Netzwerkanfragen und viele, viele mehr.

Lesen Sie mehr unter Foundation.fx. Es ist auf allen Cocoa-Unterplattformen verfügbar.

Benutzerschnittstellen: AppKit vs. UIKit vs. WatchKit.

Die Ähnlichkeiten zwischen den iOS-, watchOS-, tvOS- und macOS-SDKs verschwinden, wenn wir in den Bereich der Entwicklung von Benutzeroberflächen eintreten – und das aus gutem Grund, denn die Benutzeroberfläche für Anwendungen auf diesen Plattformen ist sehr unterschiedlich. Aus diesem Grund bieten die SDKs drei sehr unterschiedliche Frameworks:

AppKit ist nur im macOS SDK enthalten und bietet alle Klassen und Steuerelemente, die Sie für die Erstellung von Mac-Anwendungen benötigen. Aus Legacy-Gründen teilen sich die meisten dieser Klassen ein gemeinsames Namenspräfix mit Foundation und beginnen mit NS*. Zu den Klassen, mit denen Sie arbeiten werden, gehören NSWindow, NSButton, NSTableView und ähnliche.

UIKit ist das Framework, das sowohl iOS als auch tvOS verwenden, um ihre Benutzeroberflächen bereitzustellen, und seine Klassen beginnen mit einem Präfix UI*. Viele Konzepte werden von AppKit und UIKit geteilt, aber die Klassen sind unterschiedlich &mdash einige mehr als andere. Zum Beispiel haben beide Frameworks eine Klasse zur Darstellung von Farbe (NSColor bzw. UIColor), die sehr ähnlich funktionieren, während andere Konzepte ziemlich einzigartig für UIKit sind, wie z. B. die Verwendung von vordefinierten Controllern wie UINavigationController und UITabBarController. UIKit hat auch Unterschiede (einige geringfügig, einige sehr signifikant) zwischen iOS und tvOS.

WatchKit schließlich wird von watchOS verwendet, um UI für die Apple Watch in Bezug auf Apps, Glances und Benachrichtigungen zu bauen. (Es gibt auch ClockKit für die Erstellung von Komplikationen auf der Uhr.) WatchKit verwendet einen anderen und einfacheren Ansatz für das UI-Design als UIKit.

Die verschiedenen Frameworks zwingen den Entwickler, die UI seiner Anwendung von Grund auf zu überdenken und zu entwerfen, aber das ist eine gute Sache, weil die UI-Paradigmen auf jeder Plattform grundlegend unterschiedlich sind, wobei UIKit weitgehend durch Touch (sowohl direkt als auch über die Siri Remote auf Apple TV) angetrieben wird und AppKit für eine traditionellere Interaktion im Stil von Maus und Tastatur verwendet wird.

Aber viele der Konzepte hinter den Frameworks sind ähnlich, und Sie werden feststellen, dass das Erlernen der Erstellung von Anwendungen auf einem Framework in vielen Fällen leicht auf das andere übertragen werden kann. Zum Beispiel verwenden alle drei Frameworks das Model-View-Controller-Paradigma, um die eigentliche Benutzeroberfläche von der „Controller“-Klasse, die sie steuert, zu trennen. Dies wird in dem Moment deutlich, in dem Sie mit der Erstellung Ihrer ersten Benutzeroberfläche beginnen, denn anstatt Ihre eigene Fenster- oder Ansichtsklasse (aufgrund der Ein-Fenster-Natur von iOS denken UIKit-Anwendungen meist in Form von Ansichten und nicht in Fenstern) im Code zu implementieren, wie Sie es in .NET oder Delphi, implementieren Sie einen Window (oder View) “Controller“.

Andere Themen auf dieser Doku-Site, wie z.B. der Artikel Arbeiten mit XIB-Dateien, behandeln diese Konzepte ausführlicher.

Lesen Sie mehr unter AppKit.fx, UIKit.fx und WatchKit.fx.

Hinweis: Im macOS SDK existiert ein Cocoa.framework (und ein dazugehöriges Cocoa.fx). Dieses Framework ist lediglich ein Bündel aus Foundation und AppKit. Es ist nicht zu verwechseln mit unserer allgemeinen Verwendung des Begriffs „Cocoa“, um sich auf die gesamte Plattform zu beziehen.

Spezifischere UI-Frameworks

Beide SDKs enthalten zusätzliche Frameworks, die auf AppKit und UIKit aufbauen, um Zugang zu fortgeschritteneren oder spezifischen UI-Elementen zu bieten.

Zum Beispiel:

• Die macOS-, iOS- und watchOS-SDKs enthalten MapKit, das Klassen zur Integration von Apple Maps in Ihre Anwendung bereitstellt, sowohl zur Anzeige von Karten als auch zur Arbeit mit geografischen Daten. (MapKit arbeitet auch eng mit CoreLocation zusammen, das weiter unten behandelt wird.)
• Sowohl iOS als auch macOS enthalten das neue Social-Framework, mit dem Ihre Anwendung eine Benutzeroberfläche zum Teilen von Inhalten auf Twitter, Facebook, Sina Weibo und anderen sozialen Netzwerken anzeigen kann.
• iOS bietet das MessageUI-Framework für die Interaktion mit E-Mails und ermöglicht es dem Nutzer, E-Mails direkt aus der Anwendung heraus zu versenden.
• SpriteKit, neu in iOS 7.0 und OS X 10.9, und SceneKit (neu in OS X 10.9 und auch in iOS ab Version 8.0) erleichtern die Erstellung großartiger Spiele-UIs.

Systemdienste

Es gibt auch eine Reihe von Frameworks, die es Ihrer Anwendung ermöglichen, mit Systemdiensten zu interagieren, wie z.B.:

• StoreKit, um In-App-Käufe für iOS- und Mac-App-Store-Apps zu handhaben.
• Sicherheit, um auf die Systemschlüsselkette zuzugreifen, Passwörter und Zertifikate zu speichern und abzurufen usw.
• CoreLocation, um mit GPS (und Wifi-basierten Standortdiensten) zu arbeiten.
• CoreAudio und CoreVideo, um mit Audio- und Videomedien zu arbeiten und diese abzuspielen.
• Addressbook und EventKit, um mit den Kontakten und Kalendern der Nutzer zu arbeiten (neben EventKitUI auf iOS).
• GameKit, um deine Spiele in Game Center zu integrieren.

(alles gemeinsam für alle Plattformen) und mehr.

Frameworks auf niedrigerer Ebene

Wenn Sie bei der Entwicklung Ihrer Benutzeroberfläche über AppKit/UIKit hinausgehen möchten, bieten beide SDKs auch Frameworks, mit denen Sie sich die Hände schmutzig machen und auf niedrigeren Ebenen mit der Benutzeroberfläche arbeiten können.

• CoreGraphics ist die Grundlage für das gesamte Grafik-Rendering in den Core-UI-Frameworks, und Sie können und werden damit arbeiten, wenn Sie Ihre eigenen benutzerdefinierten Steuerelemente erstellen.
• QuartzCore enthält “CoreAnimation“, die Bibliothek, die einen anspruchsvollen und dennoch einfachen Zugang zum Hinzufügen von Animationen zu Ihren Anwendungen bietet – ein Muss für jede moderne iOS- und Mac-App.
• Mit GLKit können Sie OpenGL-basierte Elemente zu Ihren UIKit/AppKit-Anwendungen hinzufügen, während die untergeordneten OpenGL- (macOS) und OpenGLES- (iOS und tvOS) Frameworks Ihnen vollen Zugriff auf die rohen OpenGL-APIs geben.

rtl.fx, libToffee.fx, libSwift.fx

Zusätzlich zu den Kern-SDK-Frameworks stellt Elements drei weitere .fx Dateien bereit, die für den Betrieb entscheidend sind.

• rtl.fx ist noch grundlegender als das Foundation-Framework und enthält alle Low-Level-APIs im C-Stil, die das Kern-UNIX-System von macOS, iOS, watchOS und tvOS ausmachen; es enthält auch Bibliotheken wie Grand Central Dispatch und CommonCrypto. Im Wesentlichen repräsentiert rtl.fx die meisten der Header in /usr/include.
• libToffee.fx enthält Hilfstypen, die für den Elements-Compiler selbst entscheidend sind. Zum Beispiel enthält es interne Unterstützung für Future Types, generische NSArray<T> und NSDictionary<T> Typen, LINQ-Unterstützung und mehr.
• libSwift.fx bietet zusätzliche Typen und Funktionen, die spezifisch für die Swift-Sprache sind.

Jede Cocoa-Anwendung wird automatisch auf rtl.fx verweisen, unabhängig davon, ob sie explizit in den Referenzen aufgeführt ist oder nicht. Referenzen auf libToffee.fx und libSwift.fx sind optional; der Compiler gibt eine Warnung/Fehler aus, wenn Funktionen verwendet werden, die eine Referenz auf libToffee.fx oder libSwift.fx erfordern und diese nicht referenziert werden.