Swift-Imports mit einem Wrapper-Modul zusammenfassen

Das Problem der sich wiederholenden Imports

In jedem Swift-Projekt mittlerer Größe hast du am Anfang fast jeder Datei denselben Satz an Imports. Foundation, SwiftUI, OSLog, vielleicht Observation – die Liste wächst, wenn du neue Frameworks übernimmst. Mit dem Wechsel zu strukturiertem Logging via OSLog habe ich festgestellt, dass ich import OSLog in fast jeder Datei neben den üblichen Verdächtigen hinzufüge.

Die Lösung ist ein Wrapper-Modul, das alles, was du häufig brauchst, über einen einzigen Import re-exportiert.

Das Wrapper-Modul einrichten

Erstelle ein neues Target in deinem Swift Package oder Xcode-Projekt. In meinem Fall habe ich es AppFoundation genannt. Das gesamte Modul besteht aus einer einzigen Datei:

// Sources/AppFoundation/Exports.swift
@_exported import Foundation
@_exported import SwiftUI
@_exported import OSLog
@_exported import Observation

Das @_exported-Attribut macht alle öffentlichen Symbole jedes Frameworks für jede Datei verfügbar, die AppFoundation importiert. Jetzt braucht jede Datei in deiner App nur noch:

import AppFoundation

In deiner Package.swift hat das Target keinen eigenen Quellcode über die Exports-Datei hinaus. Dein App-Target deklariert eine Abhängigkeit von AppFoundation, und alle re-exportierten Frameworks werden überall verfügbar.

Zu berücksichtigende Kompromisse

Dieser Ansatz hat klare Vorteile: weniger Boilerplate, weniger Merge-Konflikte in Import-Abschnitten und eine zentrale Stelle, um neue Framework-Imports hinzuzufügen. Aber es gibt Kompromisse.

Erstens ist @_exported ein unterstrichenes Attribut, was bedeutet, dass es nicht offiziell Teil der stabilen Swift-API ist. In der Praxis ist es seit Jahren stabil und wird im Ökosystem weit verbreitet verwendet, aber es gibt keine formale Garantie.

Zweitens können implizite Abhängigkeiten es schwerer machen zu verstehen, was eine Datei tatsächlich nutzt. Wenn jede Datei Zugriff auf alles hat, verlierst du den Dokumentationswert expliziter Imports. Wenn du später ein Modul in ein eigenständiges Package extrahierst, musst du die expliziten Imports wieder hinzufügen.

Für App-Targets, bei denen Bequemlichkeit wichtiger ist als strikte Modularität, spart das Wrapper-Modul-Pattern echte Zeit. Für wiederverwendbare Bibliotheken bleiben explizite Imports die bessere Wahl.