C'est une réponse en deux parties:
- Unicode est étonnamment difficile à analyser et à rendre (cela frappe Android également, mais dans mon expérience limitée, cela entraîne un dessin incorrect, pas un crash)
- Une grande partie du SDK Android est Java, et lorsque les programmes Java sortent des rails, ils lancent une exception. Les exceptions déroulent la Pile proprement et vous pouvez tenter une récupération, bien que fréquemment tout soit perdu et votre meilleure corse d'action est de sauvegarder les données de l'utilisateur dans un nouveau document et d'essayer de redémarrer. Une grande partie du SDK iOS semble être écrite en ObjC, mais ce n'est que du C. La manière par défaut du C de traiter les choses qui sortent des rails (et parfois d'ObjC) n'est pas une exception, mais "faire ce que le matériel fait" avec quelques instructions de piège jetées dans le mélange. Cela peut aboutir à un signal (SEGV, ou parfois BUS) qui peut peut-être être déroulé, mais c'est difficile et généralement il est ignoré et le programme est terminé.
Il n'y a aucune raison technique pour que la gestion de l'Unicode d'iOS doive rester en C, mais utiliser un autre langage n'est pas une solution miracle. Oh, et je ne suis pas 100% familier avec la façon dont Android gère Unicode. Il est tout à fait possible qu'il utilise la même bibliothèque C (ou C++) ICU qu'iOS (elle est Open Source, très complète et plutôt bonne, je pense qu'IBM l'a écrite à l'origine, mais elle a de nombreux contributeurs). Les couches supérieures sur les deux systèmes doivent encore faire beaucoup de travail.
Je me dis aussi que le "beaucoup plus d'attention" s'applique.