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 (inkl. WatchOS, tvOS).
Die aktuelle Beta von Xcode (Version 8) zeigt bereits bei den "Deployment Targets" die erste Änderung. iOS7-Support ist damit nicht mehr möglich.
Unter der Haube analysiert Xcode 8 mit dem sogenannter 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 (z.B. Refactoring).
Plug-in-Konzept für Xcode
Foto: 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-AppStore 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 Programs können bereits jetzt zusammen mit der Xcode-8-Beta ihren Code auf Swift 3 optimieren.
Es muß 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 einigen 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 kann nur komplett erfolgen kann. Verwenden Sie Bibliotheken mit Swift 2.x Code, müssen diese ebenfalls migrieren werden. Verwenden Sie eine Bibliothek mit Swift 3 Code, muß Ihr komplettes Projekts in Swift 3 vorliegen.
Validieren und Vertrauen von Apps
Enterprise- oder Inhouse-Apps haben einige besondere Eigenschaften im Vergleich zu AppStore-Apps. Die Verteilung einer App erfolgt immer über einen Inhouse-AppStore. Dieser AppStore ist dabei immer ein Webserver, der die IPA-Datei (= File mit der App) samt PLIST File vorhält. Hierzu waren Signierungen der App- und Provisions-Profile notwendig. Hier hat Apple einen weiteren Schmerz der Entwicklergemeinde adressiert. Mit Xcode 8 werden die Code-Signierung samt Provisions Profile automatisch erzeugt.
Damit eine solche App auf dem Zielgerät ausgeführt werden darf, bedarf es einer Bestätigung des Vertrauensverhältnisses zu dem 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ältnisses gibt es auch eine Prüfung bei Apple selbst. Hierzu muß 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 asap zu erzwingen. (mb)