Windows 8 App erfolgreich in den Store – Step-by-step Tutorial

In diesem Tutorial möchte ich Schritt für Schritt zeigen, wie man eine Windows 8 App erfolgreich in den Store bekommt und auf einige typische Fallen hinweisen.

Um den gesamten Vorgang zu illustrieren, habe ich eine kleine App in XAML/C# programmiert, welche die aktuelle Uhrzeit des lokalen Rechners im Binärformat anzeigt. Also eine App von unglaublichem Nutzen, die auf keinem Windows 8 Tablet fehlen darf! Auf die Programmierung selbst gehe ich in diesem Blog Post nicht ein. Außerdem setze ich bereits das Vorhandensein eines Accounts für das Dev Center voraus.

Nach dem Einloggen im Dev Center findet sich im Dashboard der Eintrag “submit an app”. 

Dieser bringt uns zu einer Checklist, deren erster Schritt die Auswahl eines geeigneten Namens für die Applikation ist.

Der Versuch mit dem naheliegenden Namen “Binary Clock” schlägt fehl – da war jemand anderer bereits schneller.

Ganz kreativ und selbstbewusst versuche ich es nochmal mit “The Binary Clock” und diesmal klappt es – der Name ist nun für meine App reserviert.

Nun kann man mit den Schritten 2 bis 5 fortfahren.

Die Dateneingabe im Store kann aber auch unterbrochen werden und zu einem späteren Zeitpunkt fortgesetzt werden. Der Name für unsere App bleibt reserviert! Das sieht im Dashboard ungefähr so aus:

Kommen wir nun zum nächsten Schritt und legen die Verkaufsdetails fest. Altruistisch wie ich nun mal bin, habe ich mich entschlossen, diese App kostenlos zur Verfügung zu stellen und wähle daher beim Preis “free”. Außerdem möchte ich, dass sämtliche Windows 8 User Zugang zu meiner App haben, weshalb ich alle Märkte selektiere. Außerdem soll meine App sofort nach erfolgreicher Zertifizierung im Store freigegeben werden. Es läßt sich hier aber wahlweise auch ein explizites Veröffentlichungsdatum auswählen.

Gedanken machen sollte man sich natürlich über die Kategorie, in welcher die App aufgelistet werden soll. Ich wähle für unsere Uhr die Kategorie “Tools”.

Diese App verwendet weder DirectX-Features noch ist sie besonders speicherhungrig; daher darf ich unbesorgt die Standardeinstellung “Available to all systems” verwenden.

Hätte ich darauf geachtet, dass meine App auch barrierefrei ist, so könnte ich dies unter “Accessibility” vermerken. Die App würde dann Personen angezeigt werden, die gezielt nach barrierefreien Apps suchen.

Da diese App keines der erweiterten Features nutzt, ist die Konfiguration der „Advanced Features“ recht unspektakulär: Öffnen und auf “Save” klicken. Fertig!

Beim “Age rating” gibt es eine ganze Menge zu beachten!

Selbst wenn die App absolut kindgerecht ist, so müssen noch weitere Aspekte berücksichtigt werden, damit eine Angabe von 3+ bzw. 7+ erfolgen darf!

Sobald die Anwendung Zugriff auf SMS, Mikrophon, Webcam, Positionsbestimmung oder die Documents Library hat, darf keine Altersfreigabe für Kinder unter 12 Jahren erfolgen. Das gleiche gilt für Applikationen die irgendwelche Daten sammeln oder übermitteln – und sei es auch nur die E-Mail Adresse.

Internetzugang an sich ist noch kein Ausschließungsgrund für kindgerechte Apps, allerdings darf für eine etwaige Anmeldung weder eine E-Mail-Adresse noch der Realname des Benutzers erforderlich sein. Außerdem muss der Content zu 100% in der eigenen Hand sein. Werden fremde Quellen verwendet – und sei es lediglich die Einbindung eines harmlosen RSS-Feeds, der nicht der eigenen Kontrolle unterliegt – so darf die App erst mit einem Rating ab 12+ (oder noch höher) eingestuft werden.

Da ich meinen TED Client zunächst als kindgerecht erachtete (hey, mein 4 Jähriger zieht sich täglich vor dem Kindergarten zwei bis drei TED Talks rein), bin ich auch bei meinem ersten Zertifizierungsversuch gescheitert. Denn schließlich kann ich nicht garantieren, ob der Inhalt der externen Videos auf TED auch wirklich immer kindgerecht ist.

Da aber keine dieser strengen Restriktionen auf unsere Uhr zutrifft, sollte es mit einem 7+ in diesem Fall auch keine Probleme geben.

Man sollte auch nie vergessen, dass bei sämtlichen Einschätzungen betreffend Gewalt bzw. “non-sexual nature” immer US-amerikanische Maßstäbe angewandt werden.

Der vorerst letzte Schritt ist wieder schnell erledigt, da die App keinerlei Verschlüsselung verwendet – auch wenn ein binäres Zeitformat den meisten Menschen wohl kryptisch erscheint.

Als nächstes müssen wir uns um die Erstellung des Packages kümmern. Und da ist einiges an Vorarbeit erforderlich…

Alle wesentlichen Einstellungen werden im App Manifest vorgenommen.

Für das Manifest gibt es in Visual Studio einen Designer, den man entweder durch Doppelklick auf das entsprechende File im Project Explorer…

…oder durch einen eigenen Menüpunkt im Menü “Store” öffnet.

Auf der Karteikarte “Application UI” des Designers wird zunächst der Display Name festgelegt. Dieser muss nicht zwingend mit dem zuvor festgelegten App Namen übereinstimmen.

Da die App weltweit verfügbar sein soll, belasse ich die Einstellung für die Standardsprache.

Für die Kacheln habe ich in Paint.NET ein paar PNG-Grafiken in den geforderten Größen erstellt und dem Assets Folder hinzugefügt. Wichtig: Die “Build Action” für jede Grafik muss auf “Content” gesetzt sein!

Diese Grafiken werden nun ebenfalls im Manifest eingetragen.

Unter “Show name” lässt sich festlegen, auf welcher Kachel der Anzeigename erscheinen soll. Da meine breite Kachel bereits einen Schriftzug mit dem Namen trägt, soll der Name nur auf der kleinen Standardkachel eingeblendet werden und zwar in weiß, was mit der Einstellung “Light” festgelegt wird.

Zuletzt fehlt noch die Angabe einer Hintergrundfarbe, welche an den transparenten Stellen 
sichtbar wird.

Das Endergebnis mit diesen Einstellungen für beide Varianten sieht dann wie in den folgenden Abbildungen aus.

Gleiches gilt noch für den SplashScreen: PNG-File mit Transparenz als Content zum Projekt hinzufügen und im Manifest noch die Hintergrundfarbe festlegen. Fertig!

Noch ein Hinweis auf ein Detail, das gerne übersehen wird: Die Schriftfarbe (“Light” oder “Dark”) wird nicht nur in den Tiles sondern auch im Banner des Stores verwendet, ebenso wie die Hintergrundfarbe.

Daher spielen diese Einstellungen auch dann eine Rolle, wenn auf den Kacheln ohnedies kein Name angezeigt werden soll (Einstellung “No Logos”) bzw. die Hintergrundfarbe bedeutungslos ist, weil die PNG Grafiken keine Transparenz enthalten.

Eine Einstellung von “Light” und “#FFFFFF” würde dazu führen, dass unsere App die Zertifizierung nicht schaffen würde, weil der Kontrast zu niedrig ist. In der Tat ist Weiß auf Weiß nicht wirklich gut lesbar…

Ganz wichtig ist die nächste Karteikarte: hier werden die von der Applikation verwendeten Features festgelegt. Standardmäßig ist “Internet” immer ausgewählt. Wenn dies nicht der Fall ist, so wie bei unserer Binary Clock, dann sollte man unbedingt das Häkchen entfernen. Dies hat nämlich Auswirkungen auf das Privacy Statement, doch dazu später mehr.

Nun ist alles bereit um das Package auch zu erzeugen.

Ein typischer Klick-Klick-Klick-Fertig Assistent führt durch den Prozess. Nach dem ersten Schritt muss man sich mit seinem Microsoft Account beim Dev Center authentifizieren. Dann bekommt man eine Auswahl seiner bereits angelegten Apps zu sehen. Nach Auswahl des richtigen Eintrages und einigen weiteren Klicks wird das Packet erzeugt.

Auf der letzten Seite erhält man die Möglichkeit, das neue Paket gleich mit dem Windows App Certification Kit (WACK tool) zu überprüfen.

Ich habe das mal bewusst mit den problematischen Einstellungen für Schriftfarbe und Hintergrundfarbe gemacht und das Ergebnis sieht dann so aus:

Im Report wird man darauf hingewiesen, wo das Problem liegt.

Ein Hochladen des Packages kann man sich getrost ersparen; die Zertifizierung würde auf jeden Fall fehlschlagen.
Der Fehler ist schnell behoben und anschließend wird das neue Package nochmal durch das WACK tool gejagt. Dann kann das Package auch schon hochgeladen werden.

Anschließend kann man sich an den Punkt “Description” heranwagen. Dieser entpuppt sich doch ein wenig aufwändiger als bloß die Verfassung einer kurzen Beschreibung der App.

Beschreibung und Copyright Info sind verpflichtend und ein paar Keywords erleichtern die Suche für potentielle Anwender ebenfalls.

Weiter unten kommt aber nochmal Arbeit auf uns zu. Zum einen werden noch Screenshots samt Beschreibung benötigt. Am einfachsten geht dies im Emulator von Visual Studio.

Zunächst wird eine Auflösung von 1366 x 768 gewählt und anschließend die gewünschten Screenshots erstellt.

Zumindest ein Screenshot muss hochgeladen werden.

Das Hochladen der promotional images ist nicht zwingend erforderlich. Ich stelle hier aber trotzdem zumindest das kleinste Format bereit. Vielleicht habe ich ja Glück und meine App wird im Store über einen gewissen Zeitraum mit diesem Banner beworben!

Verpflichtend ist dann noch die “Support contact info”; dies kann eine E-Mail Adresse sein oder ein Link zu einer Website.

Was jedoch gerne übersehen wird, ist das Feld für die “Privacy policy”. Weil der rote Stern fehlt, könnte man meinen, es handelt sich um eine optionale Angabe. Dies stimmt aber in den seltensten Fällen, denn sobald die Anwendung Internet Verbindung benötigt bzw. reklamiert (wir erinnern uns: dies ist die Standardeinstellung im Manifest!) ist eine Datenschutzerklärung zwingend erforderlich.

Dasselbe gilt, wenn die App auf SMS, Positionsbestimmung, Webcam, Mikrophone oder die Dokument Library zugreift oder irgendwelche Daten sammelt und übermittelt. In das betreffende Feld gehört dann ein Link auf eine Seite die beschreibt, wie mit den Daten umgegangen wird.

Es wird tatsächlich überprüft, ob dieser Link gültig ist und auch eine plausible Datenschutzerklärung enthält. Mir selbst ist bei einem Update (Release 1 war bereits erfolgreich im Store) passiert, dass während des Zertifizierungsprozesses die Website mit dem Privacy statement kurzzeitig down war – das Update wurde daher zurückgewiesen und das Spiel begann von vorne…

Übrigens ist nicht nur der Link zu einem online Privacy statement erforderlich; die App selbst benötigt dann in der Regel auch eine Datenschutzerklärung, welche über den Settings Charm erreichbar sein muss.

Aber nun haben wir es – fast – geschafft! Es fehlen nur noch etwaige Informationen für die Tester. Wenn die App beispielsweise ein Login erfordert, so sollten hier die erforderlichen Account Daten übermittelt werden.

Nun sind alle Punkte abgehakt und mit einem Klick auf “Submit” wird der eigentliche Zertifizierungsprozess angestoßen.

Die ersten Stufen des Prozesses sind nach wenigen Stunden erledigt. Beim “Content compliance”-Test muss man jedoch Geduld beweisen. Ungefähr eine Woche lebt man im Ungewissen, ob es die App in den Store schafft. Und da die Tester zumeist wirklich gründlich testen kann es sehr leicht passieren, dass die Zertifizierung negativ ausfällt; in diesem Fall beginnt der Prozess dann wieder von neuem.

Wenn es also gilt, eine wichtige Deadline einzuhalten, sollte ausreichend Puffer für den Zertifizierungsprozess eingeplant werden.

Im Dashboard kann der aktuelle Status der Zertifizierung übrigens jederzeit überprüft werden.

Zu guter Letzt hier noch eine Übersicht um herauszufinden, ob ein Privacy Statement erforderlich ist bzw ob die App ein geringeres Age Rating haben darf, als 12+.

Mit dieser Anleitung sollte es nun ein Leichtes sein, seine App in den Store zu bekommen.

Viel Erfolg!