Auf dem Laufenden bleiben: Folgen Sie uns auf Twitter (@grandcentrix) und werden Sie grandcentrix Fan auf Facebook!

Wegfall der UDID unter iOS 7, was nun?

Wegfall der UDID unter iOS 7, was nun?

Apple stellte seit der ersten iOS Version Entwicklern den Zugriff auf einen Unique Device Identifier (UDID) zur Verfügung. Diese auf dem UUID Standard basierende Kennung hatte einige besondere, für App Herausgeber interessante Merkmale:

  • Die UDID ist an das Gerät gebunden.
  • Sie ist für jede installierte App auf dem Gerät identisch.
  • Der Entwickler muss sich nicht um das Speichern und Verwalten kümmern.
  • Die UDID war nicht änderbar.
  • Auch nach dem Löschen einer App und der erneuten Installation ist die UDID die gleiche.

Diese Eigenschaften machten die UDID zu einem idealen Instrument für das zuverlässige Tracking von Benutzern, sogar App übergreifend.

Häufig wurde die UDID auch verwendet, um Anwendungen zu realisieren, in denen einzelne Benutzer zwar gezielt angesprochen werden, auf einen expliziten Benutzername / Passwort Prozess aber verzichtet werden sollte. (Streng genommen war die Verwendung der UDID in einem solchen Fall keine kluge Idee, denn die UDID identifiziert ein Gerät, keinen Benutzer.)

Wegfall der UDID

Bereits mit iOS 5 angekündigt, informierte Apple im März 2013 die Entwickler darüber, dass ab 1. Mai 2013 Anwendungen, welche auf die UDID zugreifen, endgültig für den App Store nicht mehr zugelassen werden.

Dieser “Breaking Change” stellt Herausgeber und Entwickler vor die Herausforderung, nach einer Alternative zu suchen.

Umgehungslösungen? Keine gute Idee!

Umgehungslösungen, bei denen zum Beispiel auf Basis der eindeutigen Netzwerkadresse des iOS Gerätes – der sogenannten MAC-Adresse – eigene UDIDs berechnet wurden, schob Apple einen Riegel vor, in dem ab iOS 7 für jedes Gerät die gleiche, Pseudo-MAC-Adresse geliefert wird. Wer zurzeit eine solche Lösung verwendet, läuft mit Erscheinen von iOS 7 potentiell in einen Super-GAU: Die so generierte ID ist nämlich ab dann für alle Apps auf allen Geräten identisch.

Selbst die Autoren der relativ häufig verwendeten, auf einem cleveren technischen “Trick” beruhenden Open Source Umgehungslösung OpenUDID raten inzwischen offiziell von der Verwendung ihrer Lösung ab. Grund dafür: Es ist davon auszugehen, dass Apple das App übergreifende, vom Benutzer nicht beeinflussbare Tracking mittelfristig einfach nicht mehr will – und im Zweifelsfall Apps mit Umgehungsansätzen schlicht nicht mehr in den App Store lassen wird.

Alternative Ansätze

Als Ersatz für den Wegfall der UDID bietet Apple einige Alternativen, teilweise gibt es diese sogar bereits seit der ersten iOS Version. Keine dieser Lösungen liefert allerdings alle Eigenschaften der nicht mehr verfügbaren UDID.

CFUUID

Die CFUUID gibt es als Bestandteil des CoreFoundation Paketes bereits seit iOS 2.0. Über einen Funktionsaufruf kann der Entwickler eine eindeutige CFUUID erzeugen. Dieser hat jedoch gegenüber der UDID folgende Eigenschaften:

  • Die CFUUID ist nicht an das Gerät gebunden. Sie wird als Zufalls-ID generiert.
  • Sie ist für jede installierte App auf dem Gerät unterschiedlich. App-übergreifendes Tracking geht damit nicht.
  • Der Entwickler muss sich selbst um das Speichern und Wiederherstellen kümmern.
  • Nach De-Installation und Neu-Installation einer App, kann die alte CFUUID auf dem Gerät nicht mehr hergestellt werden.

NSUUID

Bei der seit iOS 6 verfügbaren NSUUID handelt es sich um die modernere Schwester der CFUUID. Ihre Eigenschaften sind mit denen der CFUUID identisch.

Advertising Identifier

Mit iOS 6 hat Apple den Advertising Identifier eingeführt.

Hierbei handelt es sich um eine ebenfalls auf dem UUID Standard basierende Kennung, die vom Betriebssystem generiert wird. Sie hat folgende Eigenschaften:

  • Der Advertising Identifier ist für alle Apps auf dem Gerät identisch.
  • Der Entwickler muss sich nicht um das Speichern und Verwalten kümmern.
  • Sie ist auch nach dem Löschen und erneuten Installieren einer App verfügbar und bleibt gleich.
  • Aber: Sie kann vom Benutzer “geändert” werden!
  • Der Benutzer kann die Verwendung des Advertising Identifiers global untersagen. (Technisch verhindert wird dadurch der Zugriff auf diesen für den Entwickler jedoch nicht.)

Der grösste Unterschied des Advertising Identifier zur UDID ist, dass sich der Advertising Identifier ändern kann.

Dies passiert entweder dann, wenn der Benutzer das iOS Gerät über Einstellungen > Allgemein > Zurücksetzen > Inhalte & Einstellungen löschen vollständig zurücksetzt, oder über Einstellungen > Datenschutz > Werbung > Ad-ID zurücksetzen explizit anfordert, dass ein neuer Advertising Identifier generiert werden soll.

Zusätzlicher Stolperstein: Die App bekommt von einer Änderung des Advertising Identifiers nur etwas mit, wenn sie vollständig neu gestartet wird. Läuft die App im Hintergrund während der Benutzer das Zurücksetzen veranlasst, liefert iOS der App weiterhin den alten Advertising Identifier. Für die Konsistenz muss also gegebenenfalls einiges an Extraaufwand betrieben werden.

Identifier for Vendor (IDFV)

Diese mit iOS 6 eingeführte ID ist ebenfalls nach dem UUID Standard aufgebaut. Ihre Eigenschaften:

  • Der IDFV ist für alle Apps auf dem Gerät identisch, die vom gleichen Herausgeber stammen. Die Identität des Herausgebers wird dabei an den ersten beiden Segmenten des in jeder App fest kodierten Bundle Identifier festgemacht. Der Bundle Identifier für grandcentrix Apps zum Beispiel beginnt immer mit net.grandcentrix.*. Für net.grandcentrix.AppA und net.grandcentrix.AppB  erzeugt iOS also den identischen IDFV.
  • Der Entwickler muss sich nicht um das Speichern und Verwalten kümmern.
  • Der IDFV bleibt solange für alle Apps eines Herausgebers identisch, bis die letzte installierte App vom Gerät de-installiert wird. Wird dann erneut eine App des Herausgebers installiert, erhält diese einen neuen IDFV, alle weiteren Apps des Herausgebers erhalten ebenfalls diesen neuen IDFV.

Wie hoch ist der Änderungsaufwand? Welche Alternative ist für meine App die richtige?

Keine der genannten Alternativen besitzt sämtliche Eigenschaften der UDID.

Dass sehr einfach zu implementierende, 100% zuverlässige, nicht beeinflussbare, App übergreifende Tracking von Benutzern gehört damit also endgültig der Vergangenheit an.

Insbesondere gilt für alle Alternativen: Der Identifier kann sich jederzeit ändern. Die Verlässlichkeit der UDID gibt es nicht mehr.

Am nächsten an der UDID ist der Advertising Identifier, mit dem wichtigen Unterschied, dass dieser vom Benutzer geändert werden kann. Darüber hinaus sind Entwickler angehalten, zu respektieren, wenn der Benutzer der Verwendung auf Betriebssystem-Ebene über Einstellungen > Datenschutz > Werbung > Kein Ad-Tracking nicht zustimmt. Erzwungen wird dies vom Betriebssystem jedoch (noch!) nicht – dies kann sich jedoch jederzeit ändern. Apple weist außerdem in der Dokumentation ausdrücklich auf die Volatilität dieser Kennung hin.

Auch der Identifier for Vendor kann als guter UDID Ersatz genutzt werden, bleibt allerdings im Unterschied zum Advertising Identifier bei einer Neuinstallation der App nicht erhalten, wenn nicht mindestens eine weitere App des gleichen Herausgebers auf dem Gerät installiert ist.

Fazit

Apps, die noch immer auf den Zugriff auf die UDID angewiesen sind, müssen dringend überarbeitet werden.

Hat man sich erst einmal für eine der möglichen Alternativen entschieden, können die erforderlichen Code Änderungen an der Anwendung selbst in der Regel mit einem Aufwand von 1-2 Personentagen durchgeführt werden. Der Austausch des für die Lieferung der ID verantwortlichen Codes ist häufig sehr einfach und risikofrei.

Viel wichtiger und leider nicht pauschal zu beantworten sind jedoch mögliche Seiteneffekte und Änderungsanforderungen an Backend-Systeme und Diensten.

Im besten Fall müssen vorhandene, in Datenbanken gespeicherte UDIDs nach dem Update der App nur einmalig migriert werden. Im schlimmsten Fall muss dem Umstand, dass sich die Kennung jederzeit ändern kann, in der App und im Backend-System Rechnung getragen werden.

Teilen sich Apps eines Herausgebers Dienste – zum Beispiel eine Plattform für Push Nachrichten – führt die Verwendung des IDVF unter Umständen zu Inkonsistenzen, wenn die Apps im Backend nicht bereits als separate Mandanten geführt werden. Alle Apps des Herausgebers würden sich ja mit dem gleichen IDFV melden.

grandcentrix unterstützt Sie gerne bei der sorgfältigen Analyse möglicher Auswirkung und Seiteneffekte und erarbeitet gerne die exakt für Ihre App passende Strategie. Sprechen Sie uns dazu bitte jederzeit an!

Categorized: latest , news , technology
Tagged: ,