Il y a, en parlant à un haut niveau, quatre parties à iOS, en tant que plateforme de programmation, et elles sont écrites dans de multiples langages de programmation.
- Le firmware ROM
Le firmware ROM est écrit en assemblage ARM hautement optimisé. Il vit dans une ROM programmée par masque, ce qui signifie qu'il'fait partie de la conception de la puce, et qu'il est très difficile de le modifier, car pour le changer, il faut faire tourner une puce. C'est un processus coûteux.
Note : Dans les anciens processeurs, ce code a été écrit par Samsung, et il avait un bug dans le code de vérification de la signature qui permettait un dépassement de tampon qui vous permettait d'exécuter un code arbitraire sans une signature vérifiée. Ce code a été remplacé, mais je'ne suis pas sûr qu'en même temps, Apple n'ait pas inclus une PROM dans l'architecture du CPU pour pouvoir le mettre à jour en usine sans avoir à faire tourner la puce, mais ce serait logique.
Le firmware ROM est ce dans quoi le CPU fait son POST (Power On Self Tests) ; il se réinitialise avec l'adresse de base de ce code dans le compteur de programme, et commence à exécuter des instructions.
Ce code contient la vérification de la signature pour le reste du code, qui vit dans Flash, qu'il charge et transmet le contrôle à.
- Le firmware de démarrage et le noyau
Je'les regroupe parce que ce sont des morceaux de code hautement appariés, et ils doivent à peu près être maintenus synchronisés en lockstep. Techniquement, ils sont des projets distincts, et leur's aussi compilateur standalone runtime morceaux là aussi.
Le firmware ROM vérifie la signature cryptographique sur le firmware de démarrage, et lui remet le contrôle, qui vérifie ensuite la signature sur, et charge, le noyau et les images KEXT comme une image de cache combinée, puis remet le contrôle au noyau.
Le firmware de démarrage et le noyau sont implémentés dans une combinaison d'assemblage ARM hautement optimisé, de C, et d'eC++ (embedded C++).
Embedded C++ diffère du C++ ordinaire, en ce qu'il ne fournit pas d'héritage multiple, de RTTI (Run Time Type Information), de dynamic_cast, et quelques autres parties très coûteuses de la norme C++. Le runtime eC++ est assez standard, comparé à celui d'autres systèmes embarqués, et, bien sûr, ils partagent du code avec ces autres systèmes, mais ont diverge substantiellement.
Le noyau lui-même est écrit en ARM assembly et C ; IOKit et les pilotes (KEXTS -- Kernel EXTensionS) sont généralement juste C++, mais selon ce qu'ils doivent poke et qui les a écrit, contiennent parfois du C vanille et/ou un peu d'ARM assembly.
Les pilotes eux-mêmes contiennent aussi parfois des blobs binaires de firmware qui sont téléchargés sur les appareils (par exemple : le firmware pour le module caméra, le firmware pour la puce du contrôleur tactile, le firmware Baseband pour le CPU maniant le firmware GSM/CDMA et WiFi, et ainsi de suite).
Les blobs binaires dépendent des composants spécifiques utilisés pour une fonction particulière. Ils sont généralement écrits dans un combo de je-ne-sais-plus-quel-langage d'assemblage et de C.
Les applications que vous écrivez utiliseront très probablement certains appels dans le noyau pour faire des choses comme les E/S, et peuvent utiliser des pilotes, mais y accéderont généralement par le biais des Frameworks.
- Les Frameworks
Ce sont essentiellement des bibliothèques de l'espace utilisateur. Les plus spéciales d'entre elles sont les bibliothèques C et mathématiques, et les runtimes C++, Objective C et Swift.
Les bibliothèques C et mathématiques contiennent beaucoup de code piège d'appel système et des routines mathématiques codées à la main en assemblage. La partie en assembleur de celles-ci n'est pas publiée.
Les autres Frameworks vont dépendre de la fonction qu'ils remplissent, et de qui les a écrits. Une grande partie de ce code est en C++ (comme WebKit), Objective C, (comme Core Video), parfois ARM assembly, pour la vitesse, et de plus en plus fréquemment, Swift. Minimalement, il existe des liaisons de colle pour toutes les routines auxquelles vous pouvez accéder à partir des programmes Swift eux-mêmes.
Donc : Assemblage ARM, C, C++, Objective C et Swift.
- Applications
Cela inclut à la fois des programmes comme Springboard, que vous avez mentionné, et des programmes écrits par des développeurs tiers (Apps).
La dernière fois que j'ai entendu parler, Springboard était encore en Objective C, et utilisait des Frameworks comme LaunchServices, et ainsi de suite.
Si vous incluez les Apps des développeurs dans cela, la réponse va être "tout ce que le développeur a utilisé et a été capable d'obtenir sur la plateforme". Il'y a beaucoup de choses qui peuvent être faites dans des environnements de développement alternatifs maintenant, même si vous aurez éventuellement besoin d'un Mac pour déployer l'App.
So pour le code fourni par Apple : Assemblage ARM, C, C++, Objective C et Swift.
Note : J'ai joué avec quelques uns des langages et environnements de développement alternatifs, en particulier ceux qui essaient de gloser sur les différences entre Android et Mac OS. La plupart du temps, ils n'offrent pas une très bonne expérience utilisateur. Si je faisais le code d'une application qui doit être multiplateforme...
- I'd separate the UI portion of the code from the guts of the code, write the guts in as much C or C++ as I could
- I'd maybe add a HAL layer to gloss over calls into objective C from that core code
- I'd just totally rewrite the UI code for the target platform
- I'd occasionally recode hot-spots to be more platform specific, if they represented performance issues
That pretty much covers it, I think.