Ответ 1
Подумайте о Objective-C ivars, как о простой старой C-структуре. Когда вы создаете экземпляр класса, блок памяти создается достаточно большим, чтобы удерживать эту структуру.
Скажем, у вас есть NSString. Для использования NSString компилируется много и много существующего кода. Многие из этого кода встроены в библиотеки и рамки. Этот скомпилированный код был создан, зная, что ivars из NSString берут X число байтов и находятся в некоторых заданных смещениях в этой памяти.
Теперь в вашем собственном маленьком проекте можно сказать, что вы создаете категорию на NSString и хотите добавить ivar. Теоретически любой код в вашем проекте, который включает заголовочный файл для этой категории, будет знать, что размер этой "новой" NSString (плюс категории) принимает байты X + Y. Это очень похоже на подкласс. Этот недавно скомпилированный код может правильно обрабатывать дополнительные ivar (ы).
Но весь предварительно скомпилированный код, библиотеки и фреймворки, не знал бы о дополнительных иварах. Когда там создаются экземпляры NSString, память представляет собой только X байт, а не X + Y байтов. Хаос возникает, когда ваш код приложения получает ссылку на этот меньший фрагмент памяти и пытается получить доступ к байтам для категории ivar. Вещи будут идти бум.
С простым старым подклассом все работает, потому что любой код, который может использовать подкласс "ivars", знает о подклассах ivars. Но с категорией уже существовавший код не знает о дополнениях и не будет правильно создавать пространство для них.
Я полагаю, что я должен указать, что все вышеизложенное в значительной степени образовано. Я мог быть совершенно неправ. По крайней мере, кажется разумным.:)