Cocoa est une API native d'Apple pour le développement orienté objet sur son système d'exploitation Mac OS X. C'est l'une des cinq API majeures disponibles pour Mac OS X, les autres étant : Carbon, la boîte à outils Macintosh (pour l'environnement obsolète Classic), POSIX (pour l'environnement BSD) et Java. Certains environnements, comme Perl et Ruby sont considérés comme mineurs, car ils n’ont pas accès à toutes les fonctionnalités et ne sont généralement pas utilisés pour le développement d'applications à part entière.
Les applications Cocoa sont typiquement construites en utilisant les outils de développement fournis par Apple, Xcode (anciennement ) et Interface Builder, en utilisant les langages de programmation Objective-C et Swift. De plus, l'environnement de programmation Cocoa peut être accessible en utilisant d'autres outils, comme Ruby (via et ) et C# (via Xamarin). Il est aussi possible d'écrire un programme Objective-C Cocoa dans un simple éditeur de texte et de le compiler par la suite avec GCC ou en utilisant les scripts makefile de GNUstep.
Pour l'utilisateur final, les applications dites Cocoa sont considérées comme étant celles écrites en utilisant l'environnement de programmation Cocoa. Habituellement, ces applications ont un ressenti différent dû à l'automatisation d'une multitude d'aspects de l'application par l'environnement Cocoa. Ceci est ainsi fait pour suivre la politique de développement d'Apple.
Au fil des versions de Mac OS X, on assiste à un rapprochement progressif de Cocoa et de Carbon, construits de plus en plus à partir de la même base (). Certaines applications Carbon, tirant parti des nouvelles fonctionnalités de Mac OS X, ne fonctionnent plus sous Mac OS 9 et la limite se fait de plus en plus floue. Il est rare de trouver des applications Cocoa qui ne font aucun appel à l’API Carbon.
L'histoire de Cocoa Cocoa est dérivé des environnements de développement NeXTSTEP et OPENSTEP créés par NeXT à la fin des années 1980. Apple acquit NeXT en et commença par conséquent à travailler sur le système d'exploitation Rhapsody, supposé être le successeur direct d'OPENSTEP. Ce dernier devait avoir un système d'émulation pour les applications macOS, appelé . Et par opposition à ce système d'émulation, les bibliothèques et les objets binaires de bases dérivés d'OPENSTEP furent au contraire appelés . Rhapsody évolua finalement vers Mac OS X et la devint Cocoa. C'est ainsi que les classes Cocoa commencent toutes par le préfixe « NS » (représentant soit la création d'OPENSTEP par l'association NeXT-Sun, soit NeXTSTEP, le propriétaire de NeXT pour OPENSTEPApple explique l'histoire du préfixe NS) : NSString, NSArray, etc.
Une grande part du travail fourni pour développer OPENSTEP fut réutilisé dans le développement de Mac OS X, Cocoa étant la partie la plus visible. Il y a néanmoins plusieurs différences entre la et Cocoa. Par exemple, NeXTSTEP et OPENSTEP utilisaient PostScript pour l'affichage à l'écran de textes et d'images, tandis que Cocoa dépend de Quartz (qui utilise les composants PDF pour l'imagerie). Cocoa dispose aussi, dans une certaine mesure, du support de l'internet, comprenant entre autres les classes NSURL et WebKit HTML, tandis qu'il n'y avait qu'un support rudimentaire des systèmes réseaux sous OPENSTEP, par l'intermédiaire des classes NSFileHandle et des Berkeley sockets.
Avant d'être ce que l'on connaît, Cocoa était le nom d'une application permettant aux enfants de créer des projets multimédias. Cette application, originellement connue sous le nom de , est désormais accréditée par une entreprise tierce nommé StageCast et est vendue sous le nom de . Le développement de ce programme fut arrêté après le retour de Steve Jobs chez Apple et le nom « Cocoa » fut réutilisé pour éviter le délai dû à l'enregistrement d'une nouvelle marque. StageCast accepta par la suite de vendre l'ancien Cocoa sous un nouveau nom.
Gestion de la mémoire Une des fonctionnalités importantes de l'environnement Cocoa est sa facilité pour gérer la mémoire allouée dynamiquement. La classe NSObject de Cocoa, de laquelle la plupart des classes sont dérivées, implémente un compteur de référence pour la gestion de la mémoire. Les objets dérivés de la classe racine NSObject répondent à des messages de rétention (retain) et de libération (release). Un nouvel objet alloué dérivant de NSObject créé avec alloc ou copy dispose d'un compteur de retiens dont la valeur est de un. Envoyer à cet objet un message de retiens provoquera l'incrémentation de son compteur, tandis qu'envoyer un message de libération décrémentera son compteur. Lorsque le compteur de retiens d'un objet atteint zéro, ce dernier est désalloué et sa mémoire est libérée (la désallocation est aux objets Objective-C, ce que la destruction est aux objets C++. La méthode dealloc est similaire à un destructeur en C++.) Cette approche pour la gestion de la mémoire est très similaire au COM développé par Microsoft.
En plus de la comptabilisation manuelle des références, les développeurs peuvent choisir l'utilisation de plusieurs (que l'on pourrait traduire par « réserves d'auto-libération »). Envoyer le message autorelease à un objet va l'enregistrer, en vue d'une future libération, dans l’ la plus proche de son processus. Lorsque l’ est elle-même libérée, elle envoie à toutes les classes enregistrées le message de libération correspondant. Ces « réserves de libération » sont souvent créées puis libérée au début et à la fin d'une boucle d'événement, garantissant que, durant l'exécution, le programme a achevé avec succès le bloc d'instruction où les objets étaient auto-libérés. En d'autres termes, les performances de l'application sont plus prévisibles et la gestion de la mémoire est totalement transparente pour l'utilisateur. Ceci se démarque nettement des systèmes de gestion automatiques de la mémoire où, dans la plupart des cas, l'application va parfois se bloquer soudainement lors de la mise en route du ramasse-miettes.
Néanmoins, un ramasse-miettes automatique existe également pour Cocoa. Ce dernier est disponible sous Objective-C 2.0, en utilisant Xcode 3.0 inclus dans Mac OS X 10.5 Leopard. Le programmeur a désormais le choix de gérer manuellement la mémoire ou non. À ce sujet, les avis sont divisés. Certains disent que la comptabilisation des références est supérieure car elle permet au développeur d'accéder à un contrôle précis sur certains objets à désallouer, tout en n'ajoutant pas la charge de devoir inspecter chaque objet que le programme désalloue. Par ailleurs, la baisse de performances habituellement imputée aux ramasse-miettes automatiques est ici très négligeable. En revanche, d'autres disent que ce système est inutile puisqu'un ramasse-miettes automatique semblable à celui proposé par Java est supérieur, simplement parce que ce dernier réduit les erreurs dues au programmeur dans la gestion de la mémoire. Dans Cocoa, le ramasse-miettes automatique peut être utilisé ou non, en fonction des préférences du projet. De plus, il peut être activé ou désactivé à différents points du programme. Le ramasse-miettes automatique est déprécié depuis Mac OS X 10.8, Apple préconise le comptage de référence automatique ARC (en) introduit avec Mac OS X 10.7.
Framework principal Cocoa est principalement constitué de trois bibliothèques Objective-C appelées . Les sont similaires en fonctionnalité aux bibliothèques partagées — un objet compilé qui peut être dynamiquement chargé dans une adresse mémoire du programme pendant l'exécution — mais les offrent aussi des ressources liées, des fichiers d'en-tête, ainsi qu'une documentation fournie.
, ou plus simplement est apparu pour la première fois dans OpenStep. Sur Mac OS X, il est basé sur . est une bibliothèque orientée objet générique, fournissant des outils de manipulations de chaîne de caractères, de valeurs numériques ou encore diverses structures de données. Des outils pour le calcul distribué et les boucles événementielles ainsi que des fonctionnalités indirectement liées à l'interface graphique utilisateur sont aussi proposée par . ou AppKit est directement hérité de l'original NeXTSTEP Application Kit. Il contient du code permettant de créer et d'interagir avec les interfaces graphiques utilisateurs. AppKit est construit comme une sur-couche de et utilise par conséquent le même préfixe « NS ». ou de persistance, il facilite l'enregistrement des objets dans un fichier, et par la suite leur chargement en mémoire.
Une partie clef de l'architecture Cocoa est son modèle de visualisation complet. L'organisation, bien que réalisée de façon conventionnelle pour un framework application, est basée sur le modèle de dessin PDF fourni par Quartz. Ce modèle permet la création de contenu dessiné personnalisé en utilisant des commandes de dessin dans le style PostScript, ce qui implique aussi une prise en charge automatique de l'impression. Par ailleurs, depuis que le Cocoa se charge du cadrage, de la taille ou du déplacement d'objets graphiques, ainsi que d'autres tâches inhérentes à la création de ces objets, le programmeur n'a plus besoin d'implémenter ces fonctionnalités basiques et peut se concentrer uniquement sur les fonctionnalités propres à son application.
Modèle-Vue-Contrôleur À la fin des années 1970, l'équipe Smalltalk travaillant à Xerox PARC instaura une méthode de conception menant à un développement aisé tout en maximisant la réutilisation du code. Appelé « Modèle-Vue-Contrôleur » (MVC), le concept sépare une application en trois couches distinctes interagissant entre elles. Les classes modèles représentent les données pures comme des documents, des fichiers de configuration ou des objets en mémoire. Les vues sont, comme leurs noms l'indiquent, des représentations (souvent visuelles) des données. Les classes contrôleur lient les modèles avec leur(s) vues respectives et les maintiennent synchronisées.
L'architecture de Cocoa est une application stricte des principes MVC. Sous OpenStep, la plupart des classes fournies étaient soit des vues de haut-niveau, soit des classes modèles de bas-niveau comme NSString. Comparé à des systèmes MVC similaires, OpenStep souffrait de l'absence d'une vraie couche modèle. Il n'y avait pas de classes pour stocker et représenter un « document » par exemple. Ainsi, pendant la transition vers Cocoa, la couche modèle fut grandement étendue, introduisant un certain nombre de classes pré-intégrées fournissant des fonctionnalités basiques aux applications de bureau.
Dans Mac OS X 10.4, Apple introduisit la famille de classe NSController, fournissant des comportements prédéfinis à la couche contrôleur. Ces classes sont considérées comme une partie du système Cocoa , faisant une utilisation étendue des protocoles, comme le et . Le terme réfère à la relation entre deux objets, principalement entre une vue et un contrôleur. Les permettent au développeur de se concentrer plus sur la mise en relation des objets plutôt que sur la planification de leur comportement.
Avec l'arrivée de Mac OS X 10.4, Apple élargit en introduisant le , qui standardisa le suivi des changements et la rémanence dans le modèle. En réalité, ce simplifie grandement les changements fait aux applications, l'annulation de ces changements (si nécessaire), la sauvegarde des données sur le disque et enfin la relecture de ces dernières.
En fournissant ce pour les trois couches MVC, le but d'Apple est de réduire la quantité de que les développeurs avaient à écrire pour maintenir la cohésion du programme, leur permettant ainsi de passer plus de temps sur les fonctionnalités spécifiques de leurs applications.
Association tardive