Local Packages in Xcode

Im Gegensatz zu Sprachen wie Java oder Kotlin hat Swift nicht die Möglichkeit das Projekt explizit in verschiedene Pakete zu unterteilen wie dies z.B. in Java möglich ist durch die Eröffnung von Namensräumen mit dem Package-Statement.
In einem iOS-Projekt sind alle Typen, die nicht explizit mit “private” oder “fileprivate” eingeschränkt wurden im ganzen Modul, d.h. in dem ganzen App-Projekt sichtbar. Dies kann schnell ziemlich unübersichtlich werden wenn das Projekt größer und damit komplexer wird.

Es ist dann schwierig die einzelnen Schichten in der App, wie z.B. Persistenz/Datenhaltung, generelle Services oder Benutzerschnittstelle voneinander sauber zu trennen, um zum einen die Testbarkeit des Codes zu verbessern aber auch um die Zuständigkeiten klar zu trennen. Schnell kann es dann passieren, dass eine untere Schicht ungewollt eine Abhängigkeit zu einer oberen, spezifischeren Schicht hat, was dann diverse Probleme mit sich bringen kann, die man leider dann erst recht spät bemerkt.

Apple empfiehlt, um eine solche Situation zu vermeiden, das Aufteilen des Projektes in unterschiedliche lokale Pakete ( https://developer.apple.com/documentation/xcode/organizing-your-code-with-local-packages ). Typen die in einem lokalen Paket definiert werden sind, solange sie nicht durch den Sichtbarkeitsmodifizierer “public” über die grenzen des Moduls, was in diesem Falle dann das Package ist, bekannt gemacht werden nur innerhalb des Packages sichtbar.

Dies ermöglich es dann in jedem lokalen Package eine öffentliche Schnittstelle zu definieren, eben durch “public“, und die internen, implementationsspezifischen Details in einem privaten Teil von den Verwendern zu verbergen. Dadurch hat man die Möglichkeit die internen Details auch später noch zu ändern und zu refactoren, solange man nicht die öffentliche Schnittstelle, also die API, dadurch bricht.

Der Verwender erlangt durch den Import des Packages dann Zugriff auf alle öffentlichen Schnittstellen und Datentypen. Die Internas bleiben ihm jedoch verborgen. 
Dadurch ist es auch einfacher einzelne Packages in anderen Projekten problemlos wieder zu verwenden und die App in eine diskrete Schichtenarchitektur zu zerlegen: