App Store Review Guidelines

Was haben eine frisch entwickelte iOS App und ein 11 Jahre altes Auto gemeinsam? Mehr als man denkt, denn beide haben eine Prüfung vor sich, der die Eigentümer meist mit äüßerst gemischten Gefühlen entgegen sehen.

Von Matthias Proske

Tatsächlich gibt es viele Ähnlichkeiten zwischen der App Store Review und der 2-jährigen TÜV-Untersuchung eines alten Autos. In beiden Fällen liefert der Eigentümer den Prüfling ab und wartet dann ungeduldig - im einen Fall 30 min, im anderen mal gerne 1-2 Wochen – um dann zu erfahren ob bestanden oder nicht.

In beiden Fällen ist das Ergebnis unumstößlich, es besteht keine Chance zu diskutieren und nicht selten hat der Besitzer ein wenig den Eindruck, die Entscheidungskriterien seien nicht immer rein objektiv sondern auch vom persönlichen Geschmack des jeweiligen Prüfers beeinflusst. Gelegentlich freut sich der Besitzer auch, dass der Prüfer nicht den einen Fehler gefunden hat, der ihm die größten Sorgen bereitet hat und den er einfach nicht mehr reparieren konnte.

Der Freigabeprozess des App Stores hat für viele Entwickler, und gerade den Neulingen unter ihnen, immer noch etwas Mysteriöses an sich. Es gibt viele Geschichten von den unterschiedlichsten und absurdesten Ablehnungsgründen und lange Zeit konnten die Entwickler nur raten, nach welchen Kriterien wirklich geprüft wird. Mitte September veröffentlichte Apple nun die „App Store Review Guidelines“ um den Prozess transparenter zu gestalten und den Entwicklern zu helfen, ihre Apps besser für den Review vorzubereiten. Diese Guidelines sollten selbstverständlich Pflichtlektüre für jeden Entwickler sein; für viele werden sie jedoch nur das wieder geben was der gesunde Menschenverstand schon vermuten ließ und die oft sehr kurze Formulierung lässt an vielen Stellen nach wie vor viel Spielraum für die Entscheidungsfreiheit.

Die möglichen Gründe und Stolperstellen, die zur Ablehnung einer App im App Store führen können, sind zahlreich und lassen sich gar nicht alle innerhalb eines Artikels beschreiben. Wir beschränken uns hier also nur auf die gängigsten und zeigen dazu ein paar prominente Beispiele, die durch diese Regeln betroffen sind oder für die sie ignoriert wurden.

Keine privaten APIs

Neben den dokumentierten APIs gibt es eine Reihe von undokumentierten, die nicht genutzt werden dürfen. Prominentestes Beispiel hierfür ist der UICoverFlowLayer, der von Apple für die Cover Flow Darstellung in der iPod App genutzt wird. Diese API ist inzwischen in der Literatur gut beschrieben und führt dadurch immer wieder zu der Frage, ob sie denn eingesetzt werden darf. Es gibt einige frei verfügbare Nachbauten dieser Funktionalität, doch gerade in der Anfangszeit wurden solche Apps mehrfach abgelehnt und die Entwickler mussten erst nachweisen, dass sie eine eigene Implementation verwenden.

Der UIFlowCoverLayer ist nun kein wirklicher Stolperstein, sehr häufig gibt es aber Fälle in denen der lesende Zugriff auf Variablen dokumentiert ist, der schreibende aber nicht, obwohl er undokumentiert möglich ist. Beispiel ist etwa das Setzen der Displayausrichtung [[UIDevice ] setOrientation: ]. An dieser Stelle sollten gerade etwas routiniertere Entwickler, die nicht mehr jede Kleinigkeit in der Dokumentation nachschlagen, ein wenig vorsichtig sein.
Für Probleme mit undokumentierten APIs gibt es zahlreiche Beispiele. Das bekannteste dürfte an dieser Stelle das Unity3D Framework sein, das immer mal wieder zur Ablehnung führt.

Sieht aus wie das Original, ist es aber nicht.

Apps dürfen keine Beta, Demo, Trial oder Test-Versionen sein

Diese Angabe ist tatsächlich wörtlich zu nehmen. Die genannten Wörter sollten in keiner Beschreibung oder in keinem Kommentar verwendet werden, da sie sofort zur Ablehnung führen. Wichtig ist hier auch die Versionsnummer, die an allen Stellen übereinstimmen sollte. Eine Versionsnummer unter 1.0 ist sicher keine gute Wahl.

Für den Zugriff auf Webseiten muss das WebKit Framework verwendet werden

Dieser Satz bedeutet letztendlich: Du darfst keinen Browser neben Safari haben. Dass es dennoch anders geht hat die Firma Opera mit einer geschickten Marketing- Aktion bewiesen und so ihren Browser im App Store platziert.

Der Opera- Browser auf dem iPhone.

Apps die Systemicons inkorrekt verwenden, werden abgelehnt

Hier seien allen Entwicklern noch einmal die Human Interface Guidelines ans Herz gelegt. Apple legt viel Wert auf ein einheitliches User- Interface. Darum ist darauf zu achten, dass Buttons sich immer gleich und vor allem so verhalten, wie es der User gewohnt ist. Ein Button mit Pfeil nach links und Aufschrift „Back“ sollte auch zurück führen und keine andere Aktion auslösen.

Manchmal trägt diese Regel aber durchaus seltsame Früchte. So wurde die App „CalcBot“ abgelehnt, weil sie ein Uhr-Symbol verwendete das dem Apple-Symbol für das Anzeigen der Anrufliste entsprach... und wieder zugelassen als die Zeiger des Uhr Symbols einfach von drei auf neun Uhr umgestellt wurden.

Niemals ein Uhrsymbol mit 3 Uhr verwenden.

Fehlende Funktionalität

Ein Button muss eine Funktion haben. Hört sich erst mal nicht ungewöhnlich an - aber ein einfaches Beispiel hierfür wäre ein Schalter für einen Vibrationsalarm, der auf einem iPod nicht funktioniert. In dem Fall muss auch der komplette Schalter ausgeblendet werden. Häufig betroffen sind an dieser Stelle Light- Versionen (das Wort Demo ist ja nicht zulässig) die an einigen Stellen Funktionen zeigen, die nur in der Vollversion funktionsfähig sind.

Keine andere Plattform erwähnen

Wer eine andere mobile Plattform in der Beschreibung oder innerhalb seiner App erwähnt wird abgelehnt. Eine Beschreibung wie „versucht auch unsere Android App mit erweiterten Features“ sollte auf jeden Fall vermieden werden.

Falsch geschriebene Apple- Produkte

Korrekte Rechtschreibung in einer App ist wichtig, vor allem wenn es um Apple Produkte geht. Also nicht Iphone, sondern korrekt iPhone schreiben.

Kein Caching und Preloading von temporären Daten

Jedem iOS Entwickler ist das irgendwann schon einmal aufgefallen: Es gibt keinen Disk-Cache. Das Cachen von temporär aus dem Internet geladenen Daten ist nicht zulässig. Generell geht es Apple mit dieser Richtlinie in erster Linie um die Lebensdauer des verwendeten Flash- Speichers. Aus diesem Grund ist diese Regel auch nicht genau definiert und lässt einigen Spielraum. Die App „Guardian Eyewhitness“ speichert immer die letzten 100 Bilder, die meisten Comic- Reader bieten einen lokalen Cache. Eine App mit einem auf Safari basierendem Browser, die Flash- Speicher als Cache verwendet, wird aber sicherlich nicht zugelassen.

Ähnliches gilt für das Vorausladen von Dateien. Wer eine Bildstrecke aus 20 Bildern auf dem iPad zeigen will, darf nicht einfach alle Bilder voraus laden, sondern sollte sich nur auf die Bilder beschränken, die gerade angesehen werden. Das Preloading des nächsten Bildes scheint aber in den meisten Fällen akzeptiert zu werden.

Keine große Datenmenge über Mobilfunknetze

Dieser Punkt ist gerade für Anbieter von Audio- und Videostreams wichtig. Soll der Stream auch mobil funktionieren (siehe dazu Punkt „fehlende Funktionalität“), dann muss ein entsprechender Stream mit reduzierter Datenmenge angeboten werden. Hier helfen die App Store Review Guidelines tatsächlich zum ersten Mal sinnvoll weiter, in dem sie konkrete Zahlen nennen.

Inhalte, Nudity und Celebritys

Das Thema Inhalte ist sicherlich das meist diskutierte. Gerade weil sich hier häufig die Vorstellungen der europäischen Entwickler und der amerikanischen Kontrolleure stark unterscheiden, aber auch weil hier viel mehr die subjektive Entscheidung des Testers auf der anderen Seite eine Rolle spielt. So wurde die App einer großen deutschen Zeitung aufgrund der freizügigen Bilder aus dem App Store entfernt, die App „Adolf Hitler SE“ mit dem Hakenkreuz im Icon jedoch zumindest kurzzeitig zugelassen. Die App FarmVillain wurde wiederum abgelehnt, weil sie Chuck Norris erwähnt.

Fehlende Abfrage einer bestehenden Netzverbindung

Dies ist die Nr.1 der Ablehnungsgründe. Greift eine App auf Ressourcen aus dem Netz zu, muss auf jeden Fall geprüft werden ob ein Zugang besteht. Apple liefert hier selbst ein rudimentäres Code-Beispiel das entsprechend erweitert werden kann. Wer eine App mit Webzugriff entwickelt, sollte sich darum besonders kümmern - es wird auf jeden Fall geprüft.

Apps dürfen den User nicht auffordern, sein Gerät zu beschädigen

Als Bonus aus der Kategorie „Lustiges, Seltsames und typisch amerikanisch“: Während eine Wasserwage zulässig ist, wird eine App, die den Benutzer auffordert, sein iPhone als Hammer zu verwenden mit Sicherheit abgelehnt werden.

Diese Liste lässt sich nach Belieben fortsetzen und es finden sich unzählige Beispiele für mehr oder weniger skurrile Ablehnungsgründe. Und einige davon sind so seltsam, dass sie einfach nicht voraussehbar sind. Viele der Ablehnungsgründe lassen sich aber durch das genaue Studium der vorhandenen Review Guidelines sowie der Human Interface Guidelines von vorne herein ausschließen. Für den Entwickler bedeutet das letztendlich:

1. Testen, testen, testen.
   Apps werden immer noch hauptsächlich abgelehnt, weil sie abstürzen. Es genügt also nicht, die App mal auf einem iPhone 3Gs zu testen und dann einzureichen... Wenn sie für als „für alle Geräte geeignet“ gekennzeichnet ist, dann sollte sie auch auf allen gängigen getestet werden, Apple wird es auf jeden Fall tun.
2. Human Interface Guidelines vor Entwicklungsbeginn lesen und beachten
   Apple ist hier sehr restriktiv und die meisten Fehler schleichen sich ein, wenn Funktionen nicht so genutzt werden, wie es von Apple vorgesehen ist.
3. App Store Review Guidelines Lesen
   Die Guidelines stellen das Minimum an Anforderungen dar, die eingehalten werden müssen.
4. Andere Ablehnungsgründe lesen
   Eine einfache Suche nach „App Store Rejection“ wird eine Reihe von Websites liefern, die Beispiele von abgelehnten Apps und die Ablehnungsgründe nennen. Hier kann man aus den Erlebnissen und Erfahrugnen anderer Entwickler lernen.

Was machen wenn die eigene App abgelehnt wurde?

Vielleicht wieder an die Hauptuntersuchung des Autos denken: Es gibt Dinge die müssen einfach stimmen (kein Auto wird mit defekten Bremsen eine neue Plakette bekommen und keine instabile App wird zugelassen), es gibt aber auch andere Dinge, die Ansichtssache sind, und zum Schluss sind da immer noch diese Dinge an die man nicht denken kann (wie das eine Ventil das nur der VW Golf mit Baujahr 5/95 bis 8/96 hatte oder die Uhr auf 9, die aber absolut entscheidend sind für das Bestehen der Prüfung).

Egal ob es nun die Bremsen oder das kleine Ventil sind, wenn die App aus bestimmten Gründen abgelehnt wurde gibt es für den Entwickler wie bei dem Auto nur eine Möglichkeit: Wenn möglich die Kritikpunkte korrigieren und dann die App neu submitten. Und dabei sollte man sich nicht unnötig aufregen sondern immer daran denken, dass auf der anderen Seite auch nur ein Mensch sitzt, der jeden Tag dutzende von Apps prüfen muss und sicherlich auch schon eine Menge miterleben musste.