Hay, hablando a alto nivel, cuatro partes en iOS, como plataforma de programación, y están escritas en múltiples lenguajes de programación.
- Firmware de la ROM
El firmware de la ROM está escrito en ensamblador ARM altamente optimizado. Vive en una ROM programada con máscara, lo que significa que es parte del diseño del chip, y muy difícil de cambiar, porque para cambiarlo hay que girar un chip. Esto es un proceso costoso.
Nota: En los antiguos procesadores, este código fue escrito por Samsung, y tenía un error en el código de verificación de la firma que permitía un desbordamiento de búfer que permitía ejecutar código arbitrario sin una firma verificada. Este código ha sido reemplazado, pero no estoy seguro de si al mismo tiempo, Apple no incluyó una PROM en la arquitectura de la CPU para poder actualizarla en fábrica sin tener que girar el chip, pero eso tendría sentido.
El firmware de la ROM es en lo que la CPU POSTs (Power On Self Tests); se reinicia con la dirección base de este código en el contador de programa, y comienza a ejecutar instrucciones.
Este código contiene la verificación de la firma para el resto del código, que vive en Flash, que se carga y entrega el control a.
- Firmware de arranque y kernel
Estoy agrupando estos porque son piezas de código altamente emparejadas, y más o menos tienen que mantenerse en sincronía en lockstep. Técnicamente, son proyectos separados, y también hay piezas de ejecución independientes del compilador.
El firmware de la ROM verifica la firma criptográfica en el firmware de arranque, y le entrega el control, que luego verifica la firma en, y carga, las imágenes del kernel y KEXT como una imagen de caché combinada, y luego entrega el control al kernel.
El firmware de arranque y el kernel están implementados en una combinación de ensamblador ARM altamente optimizado, C y eC++ (C++ embebido).
El C++ embebido difiere del C++ normal en que no proporciona herencia múltiple, RTTI (Run Time Type Information), dynamic_cast y un par de otras partes muy costosas del estándar C++. El tiempo de ejecución de eC++ es bastante estándar, comparado con el de otros sistemas embebidos, y, por supuesto, comparten código con esos otros sistemas, pero han divergido sustancialmente.
El propio kernel está escrito en ensamblador ARM y C; IOKit y los drivers (KEXTS — Kernel EXTensionS) suelen ser sólo C++, pero dependiendo de lo que tengan que pinchar y de quién los haya escrito, a veces contienen vanilla C y/o algo de ensamblador ARM.
Los propios controladores también contienen a veces bloques binarios de firmware que se descargan en los dispositivos (por ejemplo: el firmware para el módulo de la cámara, el firmware para el chip controlador táctil, el firmware de banda base para la CPU que maneja el firmware GSM/CDMA y WiFi, y así sucesivamente).
Los bloques binarios dependen de qué componentes específicos se utilizan para una función particular. Suelen estar escritos en una combinación de no sé qué lenguaje de ensamblaje y C.
Las aplicaciones que escriba probablemente utilizarán algunas llamadas al kernel para hacer cosas como E/S, y pueden utilizar controladores, pero normalmente accederán a ellos a través de Frameworks.
- Los Frameworks
Son básicamente bibliotecas de espacio de usuario. Las más especiales son las bibliotecas de C y matemáticas, y los tiempos de ejecución de C++, Objective C y Swift.
Las bibliotecas de C y matemáticas contienen una gran cantidad de código trampa de llamada al sistema y rutinas matemáticas codificadas a mano en ensamblador. La parte de ensamblaje de estas no se publica.
Los otros Frameworks van a depender de la función que cumplen, y de quién los escribió. Mucho de ese código está en C++ (como WebKit), Objective C, (como Core Video), a veces en ensamblador ARM, por velocidad, y cada vez más frecuentemente, Swift. Como mínimo, hay enlaces de cola para todas las rutinas a las que se puede acceder desde los propios programas Swift.
Entonces: Ensamblador ARM, C, C++, Objective C, y Swift.
- Aplicaciones
Esto incluye tanto programas como Springboard, que has mencionado, como programas escritos por desarrolladores de tercera parte (Apps).
Lo último que he oído es que Springboard estaba todavía en Objective C, y utilizaba Frameworks como LaunchServices, etc.
Si incluyes Apps de desarrolladores en esto, la respuesta va a ser «lo que el desarrollador haya utilizado y haya podido meter en la plataforma». Hay un montón de cosas que se pueden hacer en entornos de desarrollo alternativos ahora, aunque eventualmente se necesitará un Mac para desplegar la aplicación.
Así que para el código suministrado por Apple: ARM assembly, C, C++, Objective C, y Swift.
Nota: He jugado con un par de lenguajes y entornos de desarrollo alternativos, en particular los que tratan de pasar por alto las diferencias entre Android y Mac OS. En su mayor parte, tienden a no dar lugar a una muy buena experiencia de usuario. Si yo estuviera haciendo el código de una aplicación que tuviera que ser multiplataforma…
- 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.