Итог: я бы выбрал автономный, если / пока у вас нет убедительных доказательств того, что установка каркасов в /Library/Frameworks/ предложит заметное улучшение для вашего конкретного сценария. Проверьте эффективность выполнения этого в обоих направлениях, но я предпочитаю для начала сгруппировать фреймворки с приложением.
Динамический компоновщик (dyld) довольно умен в загрузке фреймворков и повторном использовании того, что уже было загружено в большинстве случаев. Если в разнородных местах есть несколько приложений, использующих среду, определенно предпочтительнее установить ее на /Library/Frameworks/. Однако, поскольку кажется, что все «приложения», на которые вы ссылаетесь, находятся в вашем пакете .app, вряд ли у этого подхода будет много пользы, поскольку все они будут связаны по одному и тому же пути, который dyld должен забрать на. (Пользователь не только должен иметь права администратора для изменения /Library, но и процесс установки мгновенно усложняется.) См. Последнюю часть моего ответа на связанный вопрос SO , чтобы узнать, как анализировать запуск выполнение исполняемых файлов, в том числе проверка dyld активность.
Еще одним соображением является степень контроля над версиями фреймворка, когда они хранятся в вашем комплекте приложений. Если вы намеренно «публикуете» фреймворк, помещая его в каноническое общедоступное место, вы должны быть готовы принять последствия, которые другие, возможно, захотят связать с ним. Однако, если фреймворк распространяется только внутри вашего пакета приложений, любой разработчик, который в любом случае решит ссылаться на него, не будет никого обвинять, кроме себя. : -)