iOS 5: Bald kein Zugriff mehr auf UDID für App-Entwickler?

[Marc Freudenhammer]

Es gibt eine ganze Reihe an begehrenswerten Neuerungen, die uns im Herbst dieses Jahres mit iOS 5 erwarten und jede neue Beta hält weitere (kleine) Überraschungen bereit. Dieses mal dürften aber wohl nicht alle gleichermaßen begeistert sein. Es geht um die Handhabung der eindeutigen Identifizierung von iDevices wie iPhones und iPads, kurz UDID (unique device identifier) genannt. Mit Hilfe dieser Nummer ist es Entwicklern beispielsweise möglich, genau nachzuvollziehen auf welchem Gerät eine App installiert ist und wie sie genutzt wird. Das kann unter anderem interessant sein, wenn es um die Analyse von Nutzungsdaten geht, die für die Entwicklung wichtig sind, aber auch bei der Einblendung von Werbebannern.
[PRBREAK][/PRBREAK]
In der neuesten Beta-Version weist Apple die Entwickler darauf hin, anstatt der vorhandenen UDID eine eigene Identifizierung für die jeweilige App zu nutzen. Zwar ist der Zugriff auf die Gerätenummer nach wie vor vorhanden, aber wie es aussieht werden Entwickler über kurz oder lang darauf verzichten müssen. Im genauen Wortlaut klingt das dann so:

„unique Identifier: An alphanumeric string unique to each device based on various hardware details. (read-only) (Deprecated in iOS 5.0. Instead, create a unique identifier specific to your app.)“

Sehr unwahrscheinlich ist allerdings, dass Apple seinerseits auch auf die Verwendung der UDID verzichtet, zum Beispiel um die User im Game Center zu identifizieren oder um iAds zu platzieren.

 

[Apfelbitz]

Sehr gut. Keinem Entwickler steht es zu, ungefragt bestimmte Geräte zu identifizieren.

 

[Baumfeld]

Ist aufjedenfall interessant. Aber ich glaub es geht hier eher auch um das Problem Apple seites, das viele Entwickler die UDIDs gesammelt haben gegen Geld, damit auch Dritte iOS beta Versionen benutzen können und das will Apple natürlich verhindern.

 

[mad-boy]

Sehr gut. Keinem Entwickler steht es zu, ungefragt bestimmte Geräte zu identifizieren.

Schade, dass das von den Kunden immer so einseitig gesehen wird. Klar kann man damit Unfug machen, in erster Linie dient die UDID aber dazu: 1. Dich in deiner App einzuloggen ohne jedes Mal einen Benutzernamen und ein Passwort abzufragen und trotzdem eine eindeutige Zuordnung zu haben und 2. anonyme Statistiken darüber zu erheben wieviele User bspw. eine bestimmte Firmware zu haben um so zu schauen, ob man bspw. den Support für 3.x abstellen kann und dafür neue Features zu implementieren die nur mit 4.x funktionieren.

Ich für meinen Teil benutze die UDID wenn ich sie ins Internet schicke nur gehashed, damit auf keinen Fall die UDID irgendwo außerhalb des Gerätes abgespeichert ist, man aber trotzdem eine eindeutige Identifizierung hat. Da sehe ich nichts verwerfliches dran. Es bietet dem User einen Mehrwert, entweder direkt (siehe 1.) in der Usability, oder eben indirekt (siehe 2.) durch neue Features. Trotzdem habe ich keinerlei Ahnung, wer sich hinter der UDID verbirgt.

 

[Thaddäus]

Quatsch, die UDID kann man über den Organizer oder das iPhone Configuration Utility immer noch einsehen. Es geht hier nur darum, dass eine App das wohl künftig nicht mehr tun darf, bzw. die UDID nicht mehr genutzt werden darf...

 

[drzoidberg]

Gefällt mir.

 

[Ferdi.]

solange ich noch die betas mit dem hacktivation trick benutzen kann ist mir das schnuppe..

 

[Thaddäus]

Ganz toll...

 

[smoe]

Schade, dass das von den Kunden immer so einseitig gesehen wird. Klar kann man damit Unfug machen, in erster Linie dient die UDID aber dazu: 1. Dich in deiner App einzuloggen ohne jedes Mal einen Benutzernamen und ein Passwort abzufragen und trotzdem eine eindeutige Zuordnung zu haben und 2. anonyme Statistiken darüber zu erheben wieviele User bspw. eine bestimmte Firmware zu haben um so zu schauen, ob man bspw. den Support für 3.x abstellen kann und dafür neue Features zu implementieren die nur mit 4.x funktionieren.

Ich für meinen Teil benutze die UDID wenn ich sie ins Internet schicke nur gehashed, damit auf keinen Fall die UDID irgendwo außerhalb des Gerätes abgespeichert ist, man aber trotzdem eine eindeutige Identifizierung hat. Da sehe ich nichts verwerfliches dran. Es bietet dem User einen Mehrwert, entweder direkt (siehe 1.) in der Usability, oder eben indirekt (siehe 2.) durch neue Features. Trotzdem habe ich keinerlei Ahnung, wer sich hinter der UDID verbirgt.

Und warum nicht selbst mit deiner App eine eindeutige ID generieren? Bringt dir den gleichen Nutzen, sorgt aber dafür, dass ein bisschen weniger Schabernack getrieben wird...

Übrigens ist die UDID als Ersatz für Username und Passwort nur bedingt zu gebrauchen, warum merkst du immer dann wenn jemand sein Gerät gegen ein anderes ersetzt hat, oder gar gebraucht gekauft hat... Noch dazu lässt sich die UDID mit fragwürdigen Jailbreak-Tools auch beliebig fälschen...

 

[iMirco]

Gibt schlimmeres. Aber ich kann mir vorstellen, dass einige Entwickler das anders sehen.

 

[nitromethan]

Ich finds nicht so klasse! Eigene ID's führen bestimmt nur zu Fehlern... ohoh

 

[TroRon]

Man möge mich korrigieren, aber alle APNS nutzen ebenfalls die UDID um das Device eindeutig zu identifizieren....

Wenn Apple das durchsetzen will, werden Sie nicht darum herumkommen die ganze APNS Geschichte ebenfalls zu überdenken ......

Betroffen davon sind dann alle Entwickler die:

a) einen eigenen APNS Server betreiben ....
b) einen Dienst wie z.B. Urban-Airship nutzen

Ich bin gespannt .....

 

[Cocoonfreak]

Sehr gut. Keinem Entwickler steht es zu, ungefragt bestimmte Geräte zu identifizieren.

sehe ich genauso !!!

 

[Skyee]

Ist doch jetzt echt kein Weltuntergang.

 

[Thaddäus]

Man möge mich korrigieren, aber alle APNS nutzen ebenfalls die UDID um das Device eindeutig zu identifizieren....

Wenn Apple das durchsetzen will, werden Sie nicht darum herumkommen die ganze APNS Geschichte ebenfalls zu überdenken ......

Falsch: Bei APNS wird ein Device Token erstellt, der nichts mit der UDID zu tun hat. Mit diesem Token meldet sich das iDevice beim Pushserver und sagt "Hey, ich will deine Nachrichten auch erhalten".

Zusätzlich braucht es für jede App die Pushfähig ist ein SSL Zertifikat, welches auf dem Pushserver installier werden muss.

 

[Dackel Arnold]

Und warum nicht selbst mit deiner App eine eindeutige ID generieren? Bringt dir den gleichen Nutzen, sorgt aber dafür, dass ein bisschen weniger Schabernack getrieben wird...

Übrigens ist die UDID als Ersatz für Username und Passwort nur bedingt zu gebrauchen, warum merkst du immer dann wenn jemand sein Gerät gegen ein anderes ersetzt hat, oder gar gebraucht gekauft hat... Noch dazu lässt sich die UDID mit fragwürdigen Jailbreak-Tools auch beliebig fälschen...

Natürlich hat die Sache mit der UDID seine Nachteile, jedoch ist eine eigene ID auch nicht zu gebrauchen. Wenn man z.B. die InApp Käufe über die UDID wiederherstellen kann bzw. der Entwickler es so einbaut, dann wird man sowas nicht mit einer ID lösen können. Spätestens mit der Neuinstallation der App hätte man eine neue ID. Dann könnte man die Käufe auch nicht mehr über die ID zurücksetzen.

 

[smoe]

In-App-Käufe lassen sich an die AppleID binden und so auch nach einer Neuinstallation wieder kostenlos laden. Und wenn du irgendwelche Sonderfälle abdecken möchtest, dann muss der Kunde halt einen Account bei dir erstellen, was den großen Vorteil hat dass die Käufe nicht bei einem Gerätewechsel verloren gehen.

 

[Apfelbitz]

In-App-Käufe lassen sich an die AppleID binden und so auch nach einer Neuinstallation wieder kostenlos laden. Und wenn du irgendwelche Sonderfälle abdecken möchtest, dann muss der Kunde halt einen Account bei dir erstellen, was den großen Vorteil hat dass die Käufe nicht bei einem Gerätewechsel verloren gehen.

Werden die In-App-Käufe nicht automatisch an die Apple-ID gebunden?
Oder hat da der Entwickler die freie Wahl? Ich dachte das Apple auch bei den In-App-Käufen ihre 30% mitschneidet.

 

[smoe]

Der Entwickler hat die Wahl ob es kostenlos erneut geladen werden kann oder nicht...