Liebe Forumsmitglieder,

ich habe einen Kunden, der sich eine App (bzw. mehrere Apps) vorstellt, die nur Videos (Tutorials) enthält. Was denkt ihr dazu? Die App soll entweder nur 12 Videos (bzw. in zwei Fällen Audiodateien) enthalten oder aus einem Kiosk bestehen, der seinerseits wiederum einzelne Kapitel mit je 12 Videos enthält.
Jetzt bin ich der Meinung, dass eine solche App, deren Funktionalität nur darin besteht, einen Container für Videos darzustellen, von Apple nicht genehmigt werden würde. An Apple habe ich schon eine Anfrage gestellt und bin dabei leider nur auf die App Store Review Guidelines und andere nutzlose Richtlinien verwiesen worden. Das ist wirklich ein Problem, denn wenn so etwas grundsätzlich nicht genehmigt wird, dann werden wir unserem Kunden natürlich eine Alternative vorschlagen (z.B. übers Web). Schon blöd, dass Apple hier keine Auskunft gibt!

Dann gäbe es da noch ein zweites Problem. Der Kunde würde wollen, dass man die Inhalte der App nur durch einen Code freischalten kann, der sich in einem Buch befindet, welches natürlich zuvor gekauft werden muss. So etwas genehmigt Apple doch auch nicht, oder?

Vielen Dank schon einmal für eure Meinungen!

Viele Grüße,
Nadine

Hi Nadine,

dazu kann dir nur Apple ein definitives Statement geben.

Ich habe schon all das gesehen, auch eine App, die nur mit Passwort gestartet werden kann. Und auch Apps, die gefühlt den Richtlinien entsprachen und abgelehnt wurden.

Dazu kommt, dass Apple über die Zeit "strenger" wird, klar, bei all den Apps, die mittlerweile existieren. Verständlich, vor drei Jahren war noch jede App interessant.

Zu deinem Kunden, es ist eine Risikoabschätzung. Apple kann das ablehen oder genehmigen, beides kann passieren. Die Chance ist größer durchzukommen, wenn die App cool oder interessant ist. Und garantieren könnte das nur Apple, was sie m.W. VORAB noch nie getan haben.

Wenn dir das Risiko zu groß ist, mach doch eine Web App.

Gruß
Matthias

Hallo Matthias,

vielen Dank für deine Meinung.

Du hast eine App aus dem Apple App Store gesehen, die nur mit einem Passwort gestartet werden konnte? Die war dann aber nicht kostenlos, oder? Ich hatte im Apple Developer Forum, die Rückmeldung bekommen, dass die App so wie mein Kunde sie vorhat, wohl nicht durchgehen würde. Und der Knackpunkt dabei wäre wohl der Code, den man über ein Buch bekommt.

Bei einer Web App wären die Inhalte aber nur online verfügbar, oder?

Grüße,
Nadine

Hallo Nadine,

gestartet werden können Apps ja immer, die App präsentierte sich sofort mit Passwort, anders kam man nicht weiter. Ja, kostenlos. Ist aber schon ein paar Jahre her und war von einer sehr großen Firma.

Web Apps können auch offline funktionieren, also Inhalte lokal ablegen, die einmal online geladen wurden (wie bei nativen Apps).

Gruß
Matthias

Hallo Nadine,

App Studio v4 bietet diese Funktion nun standardmäßig, du kannst Apps erstellen, die gleich mit Passwort-Screen hochstarten.

Gruß
Matthias

Hallo Matthias,

vielen Dank für diese Info :-)!

Grüße,
Nadine

Hallo Nadine,

wir haben jetzt unsere ersten beiden Demo-Kiosk-Apps in Apples Appstore unterbringen können und ich möchte kurz von den Erfahrungen während des Review-Prozesses berichten.

Wir haben zuerst eine öffentliche Kiosk-App (UST Infokiosk) und mit einigen Tagen Abstand eine Kiosk-App mit Zugangscode (UST Kundenkiosk, Entitlement-Support) eingereicht. Für die Kiosk-App mit Zugangscode muss beim Einreichen der App auch ein Code für die Review-Team von Apple angegeben werden, mit dem diese den Kiosk „betreten“ können.

Zunächst sind beide Kiosk-Apps abgelehnt worden, die öffentliche mit Status rejected, was bedeutet, dass man eine komplett neue App einreichen muss. Der Kiosk mit dem Zugangscode ist beim ersten Anlauf mit „Metadata rejected“ abgelehnt worden.
In diesem Fall muss keine komplett neue App eingereicht werden, sondern die Metadaten der App (Beschreibung, Screenshots der App selber sowie der initial enthaltenen Publikationen) sollten ergänzt werden.

Das haben wir dann auch gemacht und statt anfangs nur 1 Screenshot einzureichen, waren es in der neuen Fassung dann drei. Ausserdem haben wir die Beschreibung überarbeitet und sind noch detaillierter auf den Zweck des Kiosks eingegangen, nämlich zu demonstrieren, was man mit einer Kiosk-App mit Entitlement-Support alles machen kann.

Einige Tage noch erneutem Einreichen kam dann (die mittels Textbausteinen formulierte) Nachfrage, wie denn die Abrechnung funktionieren solle. Die Formulierung legte nahe, dass das Review-Team befürchtete, wir würden Einnahmen aus dem zugänglich Machen von Publikationen mittels des Entitlement-Supports an Apples Appstore vorbei schleusen.

In unserer Antwort auf diese Frage konnten wir klar machen, dass das nicht unsere Absicht war (und ist) und das scheinbar plausibel, denn einen knappen Tag später war die Kiosk-App online.

Kurioserweise war so die Kiosk-App mit Entitlement-Support, bei der wir sehr viel eher Probleme erwartet hätten als bei der öffentlichen App, früher in Apples Appstore verfügbar als die Öffentliche. Zudem enthält unsere Kiosk-App mit Entitlement-Support derzeit auch nur eine (öffentliche) Publikation.

Hier noch einmal im Überblick der Zeitlauf für den Review-Prozess der Kiosk-App mit Entitlement-Support:

• 01.11.2013: App hochgeladen, danach Status „Waiting for Review“
• 08.11.2013: App ist „In Review“
• 08.11.2013: „App Submission Feedback“ erhalten, Status „Metadata rejected“
• 18.11.2013: Metadaten überarbeitet, App erneut eingereicht. An der Zeitspanne vom 08. bis 18.11.2013 ist nicht Apple Schuld sondern wir, da gab es noch ein paar andere Baustellen
• 18.11.2013: App ist erneut „Waiting for Review“
• 18.11.2013: „App Submission Feedback“ erhalten, Frage nach der Abrechnung von Apple, s. o., beantwortet
• 19.11.2013: App ist wieder „In Review“
• 19.11.2013: App ist im Status „Processing for App Store“
• 19.11.2013: App ist im Status „Ready for Sale“ -> geschafft

Mehr oder weniger parallel haben wir auch die Einreichung für die öffentliche App wiederholt. Diese wurde mit zwei zusätzlichen Publikationen („echte“ Single-Issues) und einer PDF-Datei, dem Twixlmedia Whitepaper „Tablet-Publishing in a Nutshell“, versehen.

Außerdem haben wir auch hier die Beschreibung überarbeitet und aussagekräftiger gestaltet.

Der Zeitlauf für die öffentliche App sieht wie folgt aus:

• 03.11.2013: App hochgeladen, danach Status „Waiting for Review“
• 09.11.2013: App ist „In Review“
• 09.11.2013: „App Submission Feedback“ erhalten, Status „rejected“
• 18.11.2013: Überarbeitete App komplett neu hochgeladen, danach im Status „Waiting for Review“
• 21.11.2013: Wechsel in den Status „In Review“
• 21.11.2013: Wechsel in Status „Processing for App Store“
• 21.11.2013: App ist im Status „Ready for Sale“ -> auch geschafft

Nach dem Einreichen der Apps und den ersten Ablehnungen, weisst Apple immer wieder auf seine Guidelines hin, wie eine App aussehen sollte. Fast alle darin aufgeführten Vorgaben für „gute“ Apps sind, zumindest meiner Meinung nach, nicht objektiv messbar und unterliegen der subjektiven Interpretation durch das Review-Team von Apple.

Es besteht aber zu jedem Zeitpunkt die Möglichkeit, mit dem Review-Team über das Resolution-Center Kontakt aufzunehmen und zusätzliche Informationen zu einer App zu liefern oder Fragen in Bezug auf die Genehmigung zu stellen. Wie schnell diese beantwortet werden, kann ich allerdings nicht sagen.

Realisiert man Apps für Kunden, kann man (als Dienstleister) also keine Garantie dafür abgeben, dass eine App in Apples Appstore auch veröffentlicht wird. Zumal die Verantwortung für die Inhalte ja in der Regel beim Kunden liegt.

Aber zumindest besteht die Möglichkeit, die Chance auf eine Veröffentlichung durch gute Inhalte und Metadaten, sowie bei Vorbehalten durch das Review-Team, durch die Kommunikation von plausiblen Argumenten, zu erhöhen.

Auch sollte man auf eine mögliche Zeitverzögerung bei der Veröffentlichung in Apples Appstore hinweisen. Rechnet man die 10tägige Pause, die durch interne Verzögerungen bei uns entstanden ist, heraus, kommt man in unserem Beispiel auf eine Zeitspanne von 11 Tagen für die Veröffentlichung der öffentlichen App bzw. 10 Tagen für die App mit Entitlement-Support. Inwiefern diesen Zeitpannen repräsentativ sind, kann ich im Moment nicht sagen.

So, ist jetzt doch etwas länger geworden, als ich dachte, aber ich hoffe, es sind ein paar hilfreiche Infos dabei.

Viele Grüße
Ingo