Free Press

La plateforme Cocoa est maintenant représentée par quatre saveurs distinctes, ou sous-plateformes, avec les SDK macOS, iOS/iPadOS, watchOS et tvOS. Chaque SDK est constitué de bibliothèques individuelles généralement appelées « Frameworks ».

Du côté Objective-C, chaque framework est un bundle avec l’extension .framework qui contient à la fois des fichiers binaires (.dylib, ce qui est comparable à .dll sous Windows) et des fichiers d’en-tête Objective-C. Pour Elements, chaque framework du SDK est représenté par un fichier .fx qui agrège toutes les métadonnées des en-têtes afin de les rendre plus faciles et plus rapides à consommer pour le compilateur Elements.

Elements est livré avec des fichiers .fx précréés pour tous les frameworks des SDK Apple standard qui sont livrés avec les dernières versions des quatre SDK (ainsi que pour certaines versions plus anciennes).

Vous pouvez trouver une liste complète de tous les frameworks dans les listes ci-dessous. Vous verrez que de nombreux frameworks sont partagés par certains ou même tous les SDK, fournissant une vaste bibliothèque de classes qui vous permettent d’écrire du code qui peut être compilé pour et partagé entre toutes les sous-plateformes, tandis que chaque SDK fournit également un nombre important de frameworks qui sont spécifiques à la plate-forme.

• Tous les cadres SDK macOS
• Tous les cadres SDK iOS
• Tous les cadres SDK tvOS
• Tous les cadres SDK watchOS
• Tous les cadres Mac Catalyst

Regardons certains de ces cadres plus en détail.

Foundation

Probablement, le framework le plus critique pour toute application Cocoa est le framework Foundation, car – comme son nom l’indique – il fournit une grande partie des classes de fondation qui constituent une application sur le runtime Objective-C. Cela inclut la plupart des classes standard avec des préfixes NS* (à part les classes GUI, plus d’informations à ce sujet ci-dessous), des types simples et essentiels comme NSString, NSArray et autres, aux classes qui fournissent un accès aux services de base du système d’exploitation, comme NSFileManager pour l’accès au disque, NSNotificationCenter pour travailler avec les notifications, les classes NSURL* pour travailler avec les requêtes réseau, et bien d’autres encore.

Lire la suite à propos de Foundation.fx. Il est disponible sur toutes les sous-plateformes Cocoa.

Interfaces utilisateur : AppKit vs. UIKit vs. WatchKit.

Les similitudes entre les SDK iOS, watchOS, tvOS et macOS se dissipent lorsque nous entrons dans le domaine du développement de l’interface utilisateur – et pour une bonne raison, car l’interface utilisateur des applications sur ces plateformes est largement différente. Pour cette raison, les SDK fournissent trois cadres très distincts :

AppKit est inclus dans le SDK macOS uniquement, et fournit toutes les classes et contrôles dont vous avez besoin pour créer des applications Mac. Pour des raisons d’héritage, la plupart de ces classes partagent un préfixe de nommage commun avec Foundation et commencent par NS*, et les classes avec lesquelles vous travaillerez incluent NSWindow, NSButton, NSTableView et similaires.

UIKit est le framework que iOS et tvOS utilisent pour fournir leurs interfaces utilisateur, et ses classes commencent par un préfixe UI*. De nombreux concepts sont partagés par AppKit et UIKit, mais les classes sont différentes &mdash certaines plus que d’autres. Par exemple, les deux frameworks ont une classe pour représenter la couleur (NSColor et UIColor, respectivement) qui fonctionnent de manière très similaire, tandis que d’autres concepts sont assez uniques à UIKit, comme son utilisation de contrôleurs prédéfinis comme UINavigationController et UITabBarController. UIKit présente également des différences (certaines mineures, d’autres très importantes) entre iOS et tvOS.

WatchKit, enfin, est utilisé par watchOS pour construire l’interface utilisateur de l’Apple Watch en termes d’Apps, de Glances et de Notifications. (Il y a aussi ClockKit pour construire les Complications de la montre.) WatchKit utilise une approche différente et plus simple pour la conception de l’UI que UIKit.

Les différents frameworks forcent le développeur à repenser et à concevoir l’UI de son application depuis le début, mais c’est une bonne chose, car les paradigmes de l’UI sur chaque plateforme sont fondamentalement différents, UIKit étant largement piloté par le tactile (à la fois directement et via la télécommande Siri sur l’Apple TV) et AppKit étant utilisé pour une interaction plus traditionnelle de type souris+clavier.

Mais beaucoup de concepts derrière les frameworks sont similaires, et vous trouverez que l’apprentissage de la création d’applications sur l’un se traduira facilement dans l’autre dans de nombreux cas. Par exemple, les trois frameworks adoptent le paradigme Modèle-Vue-Contrôleur pour séparer l’interface utilisateur réelle de la classe « contrôleur » qui la pilote. Cela devient évident dès que vous commencez à créer votre première interface utilisateur, car plutôt que d’implémenter votre propre classe de fenêtre ou de vue (en raison de la nature à fenêtre unique d’iOS, les applications UIKit pensent principalement en termes de vues, et non de fenêtres) dans le code comme vous le feriez dans .NET ou Delphi, vous implémentez un  »contrôleur » de fenêtre (ou de vue).

D’autres sujets sur ce site de docs, comme l’article Travailler avec des fichiers XIB discutent de ces concepts de manière plus détaillée.

Lisez-en plus aux sujets AppKit.fx, UIKit.fx et WatchKit.fx.

Note : Un Cocoa.framework (et Cocoa.fx correspondant) existe dans le SDK macOS. Ce framework est simplement un regroupement de Foundation et AppKit. Il ne doit pas être confondu avec notre utilisation générale du terme « Cocoa » pour désigner l’ensemble de la plateforme.

Cadres d’interface utilisateur plus spécifiques

Les deux SDK contiennent des cadres supplémentaires qui s’appuient sur AppKit et UIKit pour donner accès à des éléments d’interface utilisateur plus avancés ou spécifiques.

Par exemple :

• Les SDK macOS, iOS et watchOS contiennent MapKit, qui fournit des classes pour intégrer Apple Maps dans votre application, à la fois pour afficher des cartes et pour travailler avec des données géographiques. (MapKit fonctionne également en étroite collaboration avec CoreLocation, abordé ci-dessous.)
• IOS et macOS contiennent tous deux le nouveau cadre Social qui permet à votre application d’afficher une interface utilisateur pour le partage de contenu sur Twitter, Facebook, Sina Weibo et d’autres réseaux sociaux.
• iOS fournit le cadre MessageUI pour interagir avec les courriels et laisser l’utilisateur envoyer des courriels directement à partir de votre application.
• SpriteKit, nouveau dans iOS 7.0 et OS X 10.9 et SceneKit (nouveau dans OS X 10.9 et également dans iOS à partir de la version 8.0) facilite la création de superbes interfaces utilisateur de jeux.

Services système

Il existe également un tas de frameworks qui permettent à votre application d’interagir avec les services système, tels que :

• StoreKit pour gérer les achats in-app pour les applications iOS et Mac App Store.
• Sécurité pour accéder à la chaîne de clés du système, stocker et récupérer les mots de passe et les certificats, etc.
• CoreLocation pour travailler avec le GPS (et les services de localisation basés sur le Wifi).
• CoreAudio et CoreVideo pour travailler avec et lire les médias audio et vidéo.
• Addressbook et EventKit pour travailler avec les contacts et calendriers des utilisateurs (parallèlement à EventKitUI sur iOS).
• GameKit pour intégrer vos jeux avec Game Center.

(tous partagés entre toutes les plateformes) et plus encore.

Cadres de niveau inférieur

Si vous voulez aller au-delà de seulement AppKit/UIKit pour votre développement d’interface utilisateur, les deux SDK fournissent également des cadres qui vous permettent d’avoir les mains plus sales et de travailler avec l’interface utilisateur à des niveaux inférieurs.

• CoreGraphics est la base de tous les rendus graphiques dans les frameworks UI de base, et vous pouvez et allez travailler avec elle lors de la création de vos propres contrôles personnalisés.
• QuartzCore contient  »CoreAnimation », la bibliothèque qui fournit un accès sophistiqué mais facile à l’ajout d’animations à vos applications – un must pour toute application iOS et Mac moderne.
• GLKit vous permet d’ajouter des éléments basés sur OpenGL à vos applications UIKit/AppKit, tandis que les frameworks OpenGL (macOS) et OpenGLES (iOS et tvOS) de niveau inférieur vous donnent un accès complet aux API OpenGL brutes.

rtl.fx, libToffee.fx, libSwift.fx

En plus des cadres SDK de base, Elements fournit trois .fx fichiers supplémentaires qui sont cruciaux pour son fonctionnement.

• rtl.fx est encore plus fondamental que le framework Foundation, et contient toutes les API de bas niveau de style C qui constituent le système UNIX de base de macOS, iOS, watchOS et tvOS ; il contient également des bibliothèques telles que Grand Central Dispatch et CommonCrypto. Essentiellement, rtl.fx représente la plupart des en-têtes de /usr/include.
• libToffee.fx contient des types d’aide qui sont cruciaux pour le compilateur Elements lui-même. Par exemple, il contient un support interne pour les Future Types, les types génériques NSArray<T> et NSDictionary<T>, le support LINQ, et plus encore.
• libSwift.fx fournit des types et des fonctions supplémentaires spécifiques au langage Swift.

Toute application Cocoa référencera automatiquement rtl.fx, qu’elle soit explicitement listée dans les références ou non. Les références à libToffee.fx et libSwift.fx sont facultatives ; le compilateur émettra un avertissement/une erreur si des fonctionnalités sont utilisées qui nécessitent une référence à libToffee.fx ou libSwift.fx et qu’elles ne sont pas référencées.