- Im Swift-Forum wurde die Beschwerde geäußert, dass die Einbindung von Swift ins Betriebssystem die Lage für Entwickler verschlechtert habe
- Als Reaktion darauf gab es die sarkastische Bemerkung: Willkommen in der Welt der Bibliotheken, die mit dem Betriebssystem ausgeliefert werden
- Dieser Artikel erklärt auf Grundlage von Erfahrungen bei der Entwicklung von Swift bei Apple, warum Swift Teil des Betriebssystems wurde und welche Probleme daraus entstanden
OS-Abhängigkeiten
- Früher erlaubten Personal Computer einem laufenden Prozess, die gesamte Maschine zu kontrollieren; heute läuft der Betriebssystem-Kernel immer und stellt grundlegende OS-Dienste bereit
- Die meisten modernen Betriebssysteme ermöglichen es, Programme zu erstellen, die über eine System-Call-Schnittstelle bestimmte privilegierte Aufgaben anfordern können
- Bei heutigen Apple-Betriebssystemen ist die System-Call-Schnittstelle je nach OS-Version nicht stabil, daher müssen für grundlegende Aufgaben die C/POSIX-Standardbibliothek und ihre Erweiterungen verwendet werden
Apples Modell (vor Swift)
- Vor Swift waren die meisten öffentlichen APIs von Apple in C oder Objective-C geschrieben und wurden als nativer Code bereitgestellt
- Neue OS-Versionen enthielten neue binärkompatible Versionen bestehender Bibliotheken und stellten damit eine Obermenge bereit, die auch APIs älterer Versionen umfasste
- Der Hauptnachteil dieses Modells war, dass neue Funktionen und APIs an neue OS-Versionen gebunden waren
Swift "Beta" 1 bis 5
- Von Swift 1 bis Swift 5 gab es viele Veränderungen, und ABI-Stabilität war immer ein Ziel von Swift
- Beim Übergang zu Swift 5 waren die meisten Probleme gelöst, und es musste ein Weg gefunden werden, Swift ins Betriebssystem aufzunehmen, ohne bestehende Apps und Projekte zu beeinträchtigen
Die Umstellung
- Bei der Integration von Swift ins Betriebssystem musste ein Weg gefunden werden, ohne bereits aufgebaute Apps und Projekte zu zerstören
- Mit einer Funktion namens
rpath kann eine ausführbare Datei dynamische Bibliotheken finden, indem sie eine Reihe von Verzeichnissen durchsucht statt eines fest verdrahteten Pfads
Was wir verloren haben
- Durch die Aufnahme von Swift ins Betriebssystem mussten Apps Swift nicht mehr selbst mitliefern, und weil Swift- und Objective-C-Runtime zusammen ausgeliefert wurden, waren Leistungsverbesserungen möglich
- Externe Swift-Mitwirkende standen jedoch vor dem Problem, dass neue APIs nur auf neuen Betriebssystemen vorhanden sind
Alternativen
- Es gibt einige vernünftige Möglichkeiten, wie Apple die Situation für Entwickler verbessern könnte, aber ob Apple das tatsächlich tun wird, ist unklar
Fazit
- Dass Swift ins Betriebssystem aufgenommen wurde, mag für App-Entwickler ein schlechtes Geschäft gewesen sein, aber Apple konnte nicht darauf verzichten, Systembibliotheken in Swift schreiben zu können
Das ist nichts Neues bei Swift
- Viele der Probleme rund um Swift sind eine Folge von Bibliotheken, die zusammen mit dem Betriebssystem ausgeliefert werden
- Sowohl technische als auch soziale Veränderungen bei Swift wirken sich auf diese Probleme aus
Meinung von GN⁺
- Dass Swift Teil des Betriebssystems wird, bedeutet für Entwickler stärkere Einschränkungen, ist aber eine unvermeidliche Folge von Apples Modell zur Verteilung von Bibliotheken
- Der Artikel betont die Komplexität der Softwareentwicklung und die Bedeutung des Bibliotheksmanagements, indem er die technischen und operativen Herausforderungen bei der Integration von Swift ins Betriebssystem und mögliche Lösungen untersucht
- Die OS-Integration von Swift brachte für App-Entwickler größere Dateigrößen und Kompatibilitätsprobleme mit sich, half Apple jedoch dabei, Konsistenz und Sicherheit des Gesamtsystems zu wahren, indem sie die Möglichkeit schuf, Systembibliotheken in Swift zu schreiben und zu aktualisieren
Noch keine Kommentare.