Fazit: Ich würde mich für eine eigenständige Lösung entscheiden, es sei denn/bis Sie überzeugende Beweise dafür haben, dass das Setzen der Frameworks in /Library/Frameworks/ eine spürbare Verbesserung für Ihr spezielles Szenario bietet. Überprüfen Sie die Auswirkungen beider Vorgehensweisen, aber ich bevorzuge es, die Frameworks zunächst mit der App zu gruppieren.
Der dynamische Linker (dyld) ist ziemlich schlau über das Laden von Frameworks und Wiederverwendung, was bereits in den meisten Fällen geladen wurde. Wenn sich mehrere Apps an verschiedenen Orten befinden, die ein Framework verwenden, ist es definitiv vorzuziehen, es unter /Library/Frameworks/ zu installieren. Da es scheint, dass sich alle "Apps", auf die Sie sich beziehen, in Ihrem .app-Bundle befinden, scheint es keinen großen Nutzen für diesen Ansatz zu geben, da sie alle mit dem gleichen Pfad verknüpft sind, der dyld sollte aufgreifen. (Es ist nicht nur ein Benutzer haben Admin-Berechtigungen erforderlich /Library zu ändern, aber der Installationsprozess sofort wird komplexer.) Siehe auch den letzten Teil der my answer to a related SO question für Ideen über Einführung Leistung von ausführbaren Dateien zu analysieren, einschließlich dyld Aktivität zu untersuchen.
Eine weitere Überlegung ist der Grad der Kontrolle, die Sie über Rahmen Versionierung haben, wenn sie in Ihrem App-Bundle gespeichert sind. Wenn Sie ein Framework absichtlich "publizieren", indem Sie es an einem öffentlich zugänglichen Ort platzieren, müssen Sie bereit sein, die Konsequenzen anderer zu akzeptieren, die sich möglicherweise dafür entscheiden, dagegen zu verlinken. Wenn jedoch ein Framework nur in Ihrem App-Bundle verteilt wird, hat jeder Entwickler, der sich dafür entscheidet, einen Link zu erstellen, niemand außer sich selbst. :-)
Ein weiterer Vorteil dieses Ansatzes besteht darin, dass Sie mehrere Versionen Ihrer Anwendung erstellen und nebeneinander ausführen können. –