Auf der WWDC hat Apple das so genannte App Thinning vorstellt. Dieses beinhaltet drei Verfahren, um App Codes effizienter zu verteilen. Lädt der Anwender eine App auf sein iOS Endgerät, wird diese aktuell mit allen Code-Bestandteilen und Ressourcen, wie zum Beispiel Grafiken, geladen und installiert. Egal welches Endgerät den Download anstößt, jedes bekommt die gleiche App in der gleichen Art und Weise.

Durch das App Slicing stellt der AppStore dem iOS Endgerät nur die Teile einer App zum Download bereit, die auf dem jeweiligen Endgerät benötigt werden. So erhält ein iPhone 5c nur den 32-Bit- und den OpenGL-Code, sowie die Retina Grafiken. Ein iPhone 6 Plus erhält dagegen nur den 64-Bit- und den Metal-Code, sowie die 3xRetina Grafiken.

Die zweite Neuerung im App Thinning Umfeld stellt das so genannten On-Demand Resources Verfahren dar. Baut der Entwickler dieses in seine XCode Entwicklungsumgebung für Mac- und iOS-Projekte ein, werden ausgewählte Ressourcen, zum Beispiel die Level eines Spiels, erst bei Bedarf nachgeladen. Auch nicht mehr benötigte Ressourcen werden wieder gelöscht und freigegeben. Der Memory-Footprint, also der Speicherbedarf einer App bei Download, Installation und zur Laufzeit wird so nachhaltig reduziert.

Als dritte Neuerung führt Apple die Bitcode Unterstützung ein. Der AppStore stellt bei diesem Verfahren nicht mehr die vollständig kompilierte App zum Download bereit. Viel mehr wird die App zum Zeitpunkt des Downloads, durch den Appstore, kompiliert. Dies erlaubt es Apple, für jedes Endgerät optimierte Compilereinstellungen zu verwenden. Derart bereitgestellte Apps werden auch in zwei Jahren für eine dann verfügbare Plattform mit den richtigen optimierten Compiler Settings bereitgestellt.

Das App Thinning vermittelt auf den ersten Blick einen Gewinn für den Speicherverbrauch, das benötigte Datenvolumen und die Performance auf dem Endgerät. Ein Blick unter die Haube zeigt jedoch das zukünftige Potential dieser Verfahren.

Als erstes Beispiel möchte ich auf den Bitcode eingehen. Dieser Bitcode stellt einen Zwischenschritt des LLVM Compilers dar. Theoretisch ist es für Apple, dank dieses Zwischenschrittes, ein leichtes, die nächste CPU oder gar Plattform Transition durchzuführen, da dies - soweit die Theorie - in diesem Status der Kompilierung noch möglich ist.

Mehr Sicherheit bei der App-Entwicklung

Eine weitere Eigenschaft, der vorgestellten Methoden, zahlt direkt auf die Sicherheit der App ein. Durch die stetige Veränderung der ausgelieferten Apps an die Endgeräte werden die Anbieter von dynamischen Wrapping Werkzeugen vor eine Herausforderung gestellt.
Wrapping bezeichnet die Kapselung von Apps in einen sicheren Container. Dabei setzt dies meistens eine sehr gute Kenntnis über die Code-Integrationen voraus. Dies ist bei einer stetigen Veränderung der Apps beziehungsweise dem dynamischen Nachladen mit erhöhten Aufwänden verbunden. Hier kann ich mir vorstellen, dass einige Hersteller derartiger Lösungen in Teilen betroffen sind und nun nach Auswegen für diese Herausforderung suchen.

Aber auch für die Raubkopier-Szene stellen diese Methoden eine nicht zu unterschätzende Hürde dar. Auch wenn nicht alle Jailbreaker auch Raubkopien einsetzen, ist das Jailbreaken in der Mehrheit der Fälle die Voraussetzung um unsignierten kopierten Code ausführen zu können. Bisher konnten einschlägige Quellen die Apps aus dem AppStore extrahieren, das DRM und die Signierung entfernen um das Ergebnis illegal auf Tauschbörsen weiter verbreiten. Individuell ausgelieferte, unvollständige und speziell kompilierte Apps erhöhen nun die Aufwände zur Zweckentfremdung dieser Apps. Die Bereitstellung von kopierter Software wird so nur mit einem enormen Aufwand möglich.

Haben sich bereits vor Jahren die Entwickler beschwert, dass der Anteil der raubkopierten Installationen zwischen 75 und 95 Prozent liegen, würde ich persönlich davon ausgehen, dass Apps mit diesen neuen Features frühzeitig umgesetzt werden.

Marktmacht hilft für mehr Sicherheit im Internet

Die Cloud erlaubt es Anwendern, auch über verschiedene Geräte auf ihre Daten zuzugreifen, da diese stets synchronisiert vorliegen. Auf allen mobilen Plattformen attestieren Forscher der Technischen Universität Darmstatt und des Frauenhofers SIT jedoch eine unsichere Implementierung der Kommuinkationsverbindungen und Autorisierungen von Apps in diese Cloud Systeme.
Dabei wurden 750.000 Android- und iOS-Apps untersucht und die Anbindung an verschiedene Cloud-Dienste wie Amazon, Apple, Facebook und Google geprüft. Gemäß dieser Studie ignorieren viele Entwickler die Sicherheitsempfehlungen für eine abgesicherte Kommunikation.

Mit App Transport Security (ATS) fördert Apple eine Verbesserung dieser Situation. ATS unterbindet standardmäßig die komplette Kommunikation über das unverschlüsselte HTTP-Protokoll. Durch die Einführung von ATS hat Apple die Möglichkeit geschaffen die Art und Weise der Absicherung einer Kommunikationsverbindung mit Mindestanforderungen vorzuschreiben.
Aktuell setzen ATS für die Kommunikationen eine TLSv1.2-Verbindungen mit forward secrecy voraus. Auch die Mindestlänge des dabei zu nutzenden Schlüssels wird vorgegeben.

Gerade im mobilen Umfeld haben viele Anwender nur ein eingeschränktes Datenkontingent. Hier müssen Entwickler stellenweise umdenken, denn TLS kostet Datenvolumen. Die genutzten Zertifikate werden bei den meisten Kommunikationsanfragen mit übertragen. Viele Apps arbeiten heute jedoch noch nach dem klassischen HTTP 1.0 Prinzip: "TCP-Socket öffnen", "Request", "TCP-Socket schließen" und dann wieder von vorne. Für jede Iteration werden die Zertifikate entsprechend mit verwendet. Dies kostet sowohl Performance als auch Datenvolumen.
Entwickler sind (noch) in der Lage, über eine entsprechende Deklarierung ihrer Verbindung, auch ohne ATS zu erlauben. Es ist jedoch zu erwarten, dass Apple diese Möglichkeit nur noch mittelfristig zur Verfügung stellt. Eine offizielle Aussage hierzu gibt es jedoch nicht.

Es empfiehlt sich für Unternehmen bereits heute ihre Infrastruktur dahingehend zu überprüfen, ob die verschlüsselte Übertragung bereits überall eingesetzt wird. Der Erwerb eines SSL Zertifikats und die Umstellung können so frühzeitig und ohne Zeitdruck vollzogen werden.

Stärkung der Plattform durch Verabschiedung von IPv4

Am 02.02.2011 meldete die Internet Assigned Numbers Authority (IANA), Eine Abteilung der Internet Corporation for Assigned Names and Numbers (ICANN) und für die Vergabe der IP-Adressen zuständig ist, dass der IPv4-Adresspool ausgeschöpft ist. Für die verbleibenden Adressen ("Reserve-Blöcke") gelten seitdem gesonderte und verschärfte Vergabebedingungen.

Mit iPv6 steht bereits seit Dezember 1998 der offizielle Nachfolger mit einem stark erweiterten Adressraum und neuen Features zur Verfügung. IPv6 ist nicht abwärtskompatibel und stellt ein völlig neues Protokoll dar. Dies hat zur Folge, dass die gesamte Infrastruktur erneuert und angepasst werden muss. Diese Umstellung läuft, gefühlt, schleppend voran. Mit iOS 9 nimmt Apple diese Entwicklung in die Hand und verlangt, dass jede iOS9 App über IPv6 "only" funktionieren muss.

Dies bedingt, dass die Anbieter auch ihre Backend-Systeme entsprechend aktualisieren müssen. Die Durchdringung von IPv6 Systemen wird daher in den nächsten Wochen und Monaten zunehmen. Auch wenn es sich einfach anhört ist die Einführung von IPv6 nicht zu unterschätzen. Das einfache Aktivieren kann zu unübersehbare Sicherheitsrisiken führen, da alle Apps eines Servers weltweit routbar verfügbar sind. Daher sollten Unternehmen sich mit der Umstellung zwar beschäftigen aber dies mit entsprechender Expertise tun.
Dieser Schritt ist auch notwendig und die Position des iOS-Ökosystems auch in Märkten wie zum Beispiel China zu stärken, in denen IPv6 bereits verbreitet sind.