iOS 10 – Das ist neu in Xcode 8

Dieser Artikel beschäftigt sich nicht mit der Frage, welche Bibliotheken sich durch iOS 10 neu ergeben haben. Vielmehr stehen grundlegende Themen im Vordergrund, mit denen sich Entwickler und Unternehmen jetzt beschäftigen müssen, um für das Release von iOS 10 gewappnet zu sein.

Das iOS-Entwicklerprogramm für Unternehmen bietet mit Xcode das Werkzeug, um die Entwicklung von iOS-Apps zu ermöglichen. Das Entwicklerprogramm bei Apple unterscheidet dabei seit letztem Jahr nicht mehr zwischen OSX- und iOS-Entwicklern (inklusive WatchOS, tvOS).

Die aktuelle Beta von Xcode (Version 8) zeigt bereits bei den “Deployment Targets” die erste Änderung. iOS-7-Support ist damit nicht mehr möglich.

Unter der Haube analysiert Xcode 8 mit dem sogenannten Thread Sanitizer die gerade entwickelte App auf “versteckte” Bugs. Ein neu implementierter Memory Debugger prüft den Sourcecode bei der Eingabe auf Speicherlecks und stellt die Speicherprobleme grafisch dar. Damit bekommt der Entwickler schnell eine Übersicht, welche Objekte und Speicherbereiche wie genutzt werden. Der Interface Builder ist schneller und erlaubt es, zwischen verschiedenen Gerätegrößen direkt umzuschalten. Entwickler erhalten so schnell einen Überblick, wie die grafische Oberfläche auf unterschiedlichen iOS-Geräten erscheint.

Das Verhalten und Unterstützen des Entwicklers bei den Tests seiner App wurde mit Xcode 8 ebenfalls adressiert. So hat Xcode bisher keine Crashlogs aufgezeichnet, wenn es zu einem Absturz der App während eines Tests kam. Unter Xcode 8 werden diese automatisch bei einem Absturz während des Tests abgelegt, und Entwickler müssen sich nicht mit Breakpoints & Co. dem Problem nähern.

Mit Xcode 8 ist es möglich, vorgefertigte Tests (Pre-Built Tests) durchzuführen, außerdem verspricht Apple 50 Prozent mehr Performance durch das Indizieren von Tests. Noch ist aber nicht alles perfekt, so hat Xcode etwa noch Lücken im Vergleich zu anderen IDEs (beispielsweise Refactoring).

Plug-in-Konzept für Xcode

©Apple

In Xcode gab es bisher ein nicht offiziell unterstütztes, nicht dokumentiertes System zum Laden von Plug-in-Bundles. Diese basierten auf “Hacks”, da diese sich zur Laufzeit in Xcode reinhängen konnten. Dies wird mit Xcode 8 aus Sicherheitsgründen (Stichwort: Xcode Ghost) abgeschaltet und teilweise durch die sogenannten Editor Extensions ersetzt. Damit bringt Xcode 8 erstmals ein ähnliches Plug-in-Konzept wie Visual Studio, Eclipse oder IntelliJ IDEA.

Die Editor-Plug-ins erlauben eine individuelle Erweiterung der Entwicklungsumgebung, die über den Mac-App Store vertrieben werden. Damit diese die Stabilität und Integrität von Xcode nicht beeinflussen, laufen die Plug-ins in einem separaten Prozess.

Swift 3 wirft seine Schatten voraus

Seit Swift ein Open-Source-Projekt ist, verläuft die Entwicklung transparent. Mit der Keynote auf der WWDC wurde auch Swift 3 in Xcode 8 aufgenommen. Mitglieder des Apple Developer Program können bereits jetzt zusammen mit der Xcode-8-Beta ihren Code auf Swift 3 optimieren.

Es muss jedem Entwickler bewusst sein, dass ständige Änderungen in Swift für all jene, die schon produktiv mit Swift arbeiten, mühsam sind. Apple hat sich zum Ziel gesetzt, möglichst viele Strukturen so weit wie möglich zu fixieren. Änderungen an der Syntax werden aber auch weiterhin passieren, die Sprache ist im Vergleich zu Objective-C immer noch sehr jung.

Xcode 8 unterstützt Entwickler mit einem Konverter von Swift 2.x zu Swift 3. Dieser hilft, mit einiger manueller Nacharbeit, den eigenen Code umzustellen. Der Konverter ist nicht nur bei den vielen bereits implementierten Swift-Syntax-Änderungen hilfreich, sondern passt auch die Namen von Methoden und Parameter diverser Bibliotheken an.

Beachten Sie, dass eine Umstellung auf Swift 3 nur komplett erfolgen kann. Verwenden Sie Bibliotheken mit Swift 2.x Code, müssen diese ebenfalls migriert werden. Verwenden Sie eine Bibliothek mit Swift-3-Code, muss Ihr komplettes Projekt in Swift 3 vorliegen.

Validieren und Vertrauen von Apps

Enterprise- oder Inhouse-Apps haben einige besondere Eigenschaften im Vergleich zu App-Store-Apps. Die Verteilung einer App erfolgt immer über einen Inhouse-App-Store. Dieser App-Store ist dabei immer ein Webserver, der die IPA-Datei (= File mit der App) samt PLIST-File vorhält. Dazu waren Signierungen der App- und Provisions-Profile notwendig.

Hier hat Apple einen weiteren Schmerz der Entwicklergemeinde adressiert. Mit Xcode 8 wird die Code-Signierung samt Provisions-Profilen automatisch erzeugt.

Damit eine solche App auf dem Zielgerät ausgeführt werden darf, bedarf es einer Bestätigung des Vertrauensverhältnisses zum Entwickler. Enterprise-Apps, die über MDM installiert werden, vertraut das Gerät (genauer gesagt: dem “Developer”) automatisch. Enterprise-Apps, die nicht über MDM installiert werden, muss der Anwender explizit vertrauen, sofern dies für den jeweiligen Developer noch nicht erfolgte.

Neben diesem anwendergetriebenen Vertrauensverhältnis gibt es auch eine Prüfung bei Apple selbst. Hierzu muss bei der Installation einer Enterprise-App das Zielgerät in allen Fällen eine Verbindung zu Apple-Servern herstellen können, um die Gültigkeit des Profiles überprüfen zu können.

Diese Prüfung wird in regelmäßigen Abständen wiederholt. Bisher konnte dieser Zeitpunkt weder durch die App, den Anwender oder das MDM vorgegeben werden. Dies hatte zur Folge, dass es theoretisch passieren kann, dass eine App beispielsweise im tiefsten Schwarzwald – ohne Internet-Verbindung – die Validierung vollziehen will und fehlschlägt.

Damit dies nicht passiert, hat Apple ein MDM-Kommando in iOS 10 aufgenommen, um die Validierungsprüfung sofort zu erzwingen.