Was Entwickler von Apples Sprache Swift 5 erwarten

Peter Müller, Halyna Kubiv |
Die WWDC steht bevor - und damit vermutlich auch eine neue Version der Open-Source-Programmiersprache Swift. Wir haben einen Entwickler zu seinen Erfahrungen und Wünschen befragt.
image description

Swift

Apple

Der Redakteur, Musik- , Audio- und Mac-Experte Christian Möller hat seine erste auf Swift 4 aufbauende App in den App Store gebracht, OLED-Uhr . Im Interview mit Macwelt spricht Möller über die Herausforderungen der Entwicklung, was er sich von Swift 5 wünscht und was man beachten sollte, will man selbst mit dem Programmieren beginnen.

Chris, du hast gewissermaßen den ersten Bildschirmschoner für das iPhone X entwickelt, sehe ich das richtig?

Ja (lacht), das kann man so sagen. Wobei der beste Bildschirmschoner immer noch das Abschalten des Displays ist.

Ich vermisse nur die fliegenden Toaster

Die gibt es vielleicht in Version 2.0 ;)

Aber die App hat ja einen ernsten Hintergrund: Wie sehr muss man diesen Einbrenneffekt beim iPhone X fürchten, was kann man im Normalbetrieb dagegen unternehmen?

Alle OLED-Displays leiden unter dem Einbrenneffekt, das liegt bin der Natur der Sache. Die leuchtenden organischen Substanzen altern nun einmal und das auch noch besonders schnell, wenn die OLED-Pixel lange Zeit eingeschaltet sind. Apple tut selbst schon etwas dagegen und lässt Elemente, die normalerweise immer fest an einer Stelle stehen – beispielsweise das Batterieladesymbol oder die WLAN-Feldstärkeanzeige – ganz leicht umherwandern, damit sie nicht immer dieselben Pixel benutzen. Viel mehr kann man da nicht tun. Als Anwender sollte man Apps vermeiden, die dauerhaft immer dieselben Grafikausgaben an der selben Position machen.

Kommen wir aber mal zur App selbst, respektive deren Entstehung. Das mag zwar deine erste im App Store sein, aber du hast früher schon programmiert?

Ja, tatsächlich habe ich schon im Alter von 19 Jahren meine ersten Codezeilen in BASIC und Z80-Assembler in die Tastatur gehackt.

Wow! Auf welchem Rechner?

Das war 1983 auf einem Sinclair ZX Spectrum mit 16 KB RAM. Später dann auf einem ATARI ST in Assembler und GFA-BASIC, auf dem Mac dann in überwiegend Real Basic, das heute Xojo heißt. Seitdem habe ich immer wieder kleine Tools und Utilities programmiert, aber überwiegend nur für mich selbst, weil ich die Software haben wollte, sie es aber auf dem Markt so nicht gab.

Und heute programmierst du also mit Swift 4. Wo sind da die grundlegenden Unterschiede?

Die Swift-Syntax kommt meinem Programmierstil sehr entgegen, ich fühlte mich gleich zuhause, anders als bei Objective-C, damit konnte ich mich nie richtig anfreunden. Vor allem die rasant gestiegene Verbreitung der Sprache Swift sorgt inzwischen dafür, dass man auf so ziemlich jede Frage im Netz eine Antwort findet, die man schnell für die eigene Zwecke anpassen kann. Das ist großartig!
Du hast aber auch schon mit Objective-C Erfahrungen gesammelt?

Den Einstieg in Objective-C habe ich mal gewagt, aber die Lernkurve war mir besonders ganz am Anfang zu steil. Swift ist viel leichter lesbar.
Wie lange hat es für dich gedauert, bis du in Swift genau so coden konntest wie zuvor in Real Basic, respektive Xojo?

Nicht lange, die Sprachen sind sich ziemlich ähnlich. Lediglich an die Eigenheiten der IDE (Xcode) musste ich mich gewöhnen.

Einsteigern rät Apple zu Swift Playgrounds , wie weit kommt man damit?

Ich habe damit mal rumgespielt, bin aber ehrlich gesagt dann immer ganz schnell zu „echten“ Xcode-Projekten übergegangen, weil ich die Ergebnisse dann direkt auf dem iPhone sehen wollte.

Und welche Lehrbücher oder Kurse kannst du dann empfehlen?

Keine! „Learning By Doing“ ist meine Devise. Ausprobieren und im Netz nach Lösungen suchen, wenn es mal hakt. Eine unerschöpfliche Quelle ist stackoverflow.com . Da findet man fast immer Lösungen.
Apple preist ja Swift als die Zukunft der Programmierung an, verständlich und einfach soll die Sprache sein. Wie viel stimmt davon?

Gegenüber Objective-C ist Swift ein riesiger Schritt nach vorn. Vor allem, weil die Lernkurve am Anfang wesentlich flacher verläuft, ist sie für Einsteiger besser geeignet, man kommt viel schneller zu ersten Erfolgserlebnissen. Und: Es gibt keine Beschränkungen nach oben. Bei der Entwicklung von OLED Uhr bin nicht ein einziges Mal auf Probleme von Swift gestoßen, die ich nur mit Objective-C hätte lösen können.  

Was schätzt du: Wie lange wird ein kompletter Laie gebrauchen, um sich selber Swift beizubringen? Also bei perfekten Bedingungen: Ohne Netflix und beim schlechten Wetter?

Das hängt immer vom Vorwissen ab. Wer schon mal programmiert hat, ist da sicher in ein paar Stunden drin. Wer noch nie Programme geschrieben hat, muss sich erst einmal die Grundlagen drauf schaffen. Also Xcode, Interface-Builder, Datenstrukturen etc. Das dauert sicher ein paar Wochen. Wenn man das aber aktiv mit spannenden Beispielen begleitet, kann das sicher Spaß machen.

Nun ist ja damit zu rechnen, dass Apple in zwei Wochen auf der WWDC die nächste Fassung seiner Programmiersprache vorstellt, Swift 5. Welche Erwartungen hast du daran?

Was mit ziemlicher Sicherheit in Swift 5 kommen dürfte, ist die ABI-Stabilität. Als Programmierer hat man davon nicht unmittelbar einen Nutzen, als Anwender jedoch schon. ABI-Stabilität heißt, dass die Art und Weise, wie Datenstrukturen im fertig kompilierten Code (Binärcode) von Variablen und Arrays und beispielsweise die Übergabe von Parametern an Funktionen ein für allemal festgelegt werden. Nach der Erklärung der ABI-Stabilität dürfen sie sich nicht mehr ändern – oder nur mit großem Aufwand.

Warum ist das so wichtig?

Im Moment ist es so, dass jede in Swift programmierte App die grundlegenden Swift-Funktionsbilbliotheken im eigenen App-Bundle mitbringt. Das hat den Vorteil, dass man gleichzeitig Apps, die in verschiedenen Swift-Versionen programmiert wurden, auf seinem iPhone benutzen kann.

Und der Nachteil?

Es nimmt enorm viel Speicherplatz in Anspruch, wenn die Bibliotheken für jede einzelne App redundant vorhanden sein müssen.

Aha, wird dann die ABI-Stabilität erklärt …

 … dann könnte Apple die Swift-Bibliotheken fest ins iOS integrieren und jede App kann auf diese Bibliotheken aufsetzen, ohne das sie sie selbst mitbringen müsste. So könnte Apple auch neue Funktionen einbauen, beispielsweise rechenintensive Funktionen auf Coprozessoren auslagern. Wenn die neue Funktion in der Bibliothek ausgetauscht wird, aber genauso angesprochen und benutzt wird, wie die alte Funktion, profitieren alle Apps davon, ohne dass die Entwickler die App anpassen und neu kompilieren müssen.

Was wünscht du dir persönlich an neuen Funktionen in Swift 5?

Meine persönlichen Wünsche gehen eigentlich mehr in praktische Erweiterungen, die nicht mit der Sprache Swift zusammenhängen. „Core Animation“ beispielsweise ist eine tolle Möglichkeit für den Programmierer, flott mal „Bewegung“ auf den Bildschirm zu bringen, die natürlich und organisch wirkt, so wie man das von viele iPhone-Apps her gut kennt. Meine App "OLED-Uhr" benutzt Core Animation, um die Ziffern der Uhr über den Bildschirm zu bewegen. Das waren nur drei Zeilen Code, großartig!

Aber dann ist ja alles in Butter?

Nein, denn leider ist Core Animation bislang nicht ganz zu Ende gedacht. Ich würde mir wünschen, dass sich Parameter, wie beispielsweise die Schriftgröße eines Zeichensatzes ebenfalls per Core Animation animieren ließen. Auch in punkto Farbanimation gäbe es noch Verbesserungsbedarf. Zwar kann man die Hintergrundfarbe eines „Views“ (rechteckiger Bereich auf dem Bildschirm) per Core Animation verändern, nicht jedoch die Schriftfarbe eines Labels (Text-Objekt). Das Color-Cycling der Ziffern in OLED Uhr musste ich also „zu Fuß“ mühsam über einen Timer programmieren.

Welch Aufwand! Aber welche weiteren Verbesserungen siehst du für Entwickler?

Was Apple unbedingt verbessern muss, ist die Asset-Verwaltung in Xcode.

Das bedarf einer genaueren Erklärung!

Mit Assets sind ganz allgemein Dateien gemeint, die man in die App integrieren will, vor allem Grafikelemente, die in der App auftauchen sollen. Die muss man inzwischen in drei verschiedenen Auflösungen ins Projekt integrieren und Xcode ist da leider nur wenig hilfreich. Für das App-Icon ist es beispielsweise richtig schlimm: Nicht weniger als 18 (!) verschiedene Versionen des App-Icons muss man ins Projekt integrieren, wobei Xcode jedes Icon ablehnt, wenn es nicht pixelgenau die korrekte Auflösung aufweist. Die ist aber in Xcode gar nicht ersichtlich. Man muss sich das mühsam von Hand aus den Dokumentationen zusammensuchen und dann 18 Mal in Photoshop auf „Speichern unter“ klicken.

Das ist echt mühsam!

Aber wirklich! Xcode könnte hier als ersten Schritt einfach selber aus der höchsten Auflösung die anderen Icons generieren. Von Hand austauschen könnte man sie dann ja immer noch, wenn man beispielsweise für geringe Auflösungen ein ganz anderes Bild hernehmen möchte.

Klingt danach, als ob noch viel Arbeit bevorsteht.

Ja, denn solche und ähnliche Baustellen gibt es in Xcode jede Menge. Aber ich bin zuversichtlich, dass Apple die Themen Stück für Stück angehen wird.