NSString действительно кластер классов. Это означает, что по разным причинам, включая производительность в зависимости от содержимого и размера, а также для поддержки бесплатного моста через CFString при создании NSString, вы можете получить один из многих частных классов, которые возвращают YES для isKindOf: когда вы спрашиваете, является ли это NSString и он будет отвечать на все методы в классе NSString. Это похоже на протокол, но все объекты будут говорить, делать и быть NSString в общедоступном API.
Как указано в документации для NSString и CFString, это концептуально массив UTF16 unichar
Он может и будет использовать другое внутреннее представление, где он представляет преимущество для реализации. Обычно производительность иногда объем памяти. Но вы можете положиться на него, предоставляя вам массив C unichar, когда его попросят, или что-нибудь еще, что обещает API.
У него было долгое время для созревания, и он внутренне настраивался почти в каждом выпуске.
Короче говоря, да, вы можете думать об этом как о поддержке массива UichFich Unichar, в значительной степени совпадающего с описанием логической строки в стандарте Unicode. Но нужно помнить, что вам действительно не нужно беспокоиться о том, что внутри, а только о том, что вам сказано, что внутри.
Это одна из лучших реализаций Юникода.
Если вы хотите получить более полную картину того, как это работает, вы можете посмотреть (большинство) источника CFString на opensource.apple.com
Это C и Core Foundation (объектно-ориентированный C) и довольно стилизованный, так что не ждите, что поймете все сразу.
NSString и CFString имеют методы для возврата и создания из unichar. Большинству людей это не нужно.
Если вы делаете, будьте осторожны, будьте готовы много читать и делать наивные ошибки. Юникод это большая тема. Правильное обращение с этим - наука и искусство на этом уровне. Это одна из причин NSString. Он обрабатывает много сложных вещей, поэтому вам не придется так часто, если вы не хотите или не должны.