Pulsefield veröffentlichen: Der administrative Aufwand, den ich komplett unterschätzt habe

Ich habe das komplett unterschätzt

Als ich anfing, Pulsefield zu bauen, hatte ich ein grobes mentales Modell davon, was das Veröffentlichen bedeuten würde: App bauen, beim App Store einreichen, auf Review warten, fertig. Vielleicht eine Ablehnung oder zwei zu navigieren. Gut, machbar.

Was ich kein mentales Modell für hatte, war alles andere. Die Vereinbarungen, die Steuerformulare, die regulatorischen Einreichungen, das Banking-Setup — all das parallel zum eigentlichen Bauen der App, obendrauf auf einen Vollzeitjob. Niemand spricht wirklich über diese Seite des Indie-Daseins, und ich bin vollkommen blind darein gelaufen.

Die Vereinbarungen

Es beginnt einfach genug. Man unterschreibt das Free Apps Agreement. Leicht. Dann sieht man das Paid Apps Agreement und denkt, ja das erledige ich noch.

Zwei Wochen später hat man es immer noch nicht erledigt, weil man jedes Mal, wenn man es öffnet, internationale Steuerabkommen auf der IRS-Website liest und auf eine Erklärung mit einer Meineidsklausel starrt. Ich bin Entwickler in der Schweiz und möchte einfach ein Spiel veröffentlichen. Ich fülle meine Steuern seit ich sechzehn bin selbst aus und würde mich für halbwegs kompetent im Umgang mit Behörden halten. Das hat mich trotzdem kaltgestellt.

Als ich es schliesslich einreichte, wurde es praktisch sofort aktiv. Nichts-Burger. Das Formular dauerte vielleicht fünfzehn Minuten. Aber ich hatte zwei Wochen damit verbracht, es in meinem Kopf als etwas aufzubauen, das mich versehentlich zum Steuerkriminellen in einem Land machen könnte, in dem ich nicht lebe. Im Nachhinein ist es fast lustig. Damals war es das nicht.

Die Bankverbindung übrigens? Blieb die ganze Zeit inaktiv, solange ich das Paid Apps Agreement mied. Fast sicher davon abhängig. Zwei Wochen des Wunderns, warum Banking nicht aktiviert wird — selbst verursacht.

Der EU Digital Services Act

Das hat mich wirklich unvorbereitet erwischt.

Als App-Entwickler, der an EU-Kunden verkauft, bin ich rechtlich als Händler eingestuft. Der DSA verlangt, dass ich Kontaktinformationen veröffentliche — einschliesslich einer Telefonnummer — die potenziell 450 Millionen EU-Bürgern sichtbar ist. Ich sass eine Weile mit dieser Zahl. Vierhundertfünfzig Millionen Menschen, die mich theoretisch anrufen könnten, um nach meinem haptischen Minenfeld-Spiel zu fragen.

Ich kaufte letztendlich eine Prepaid-Business-eSIM genau dafür, etwas das ich abschalten kann, wenn es seltsam wird. Reichte das Formular ein und wartete dann zehn Tage auf die EU-Genehmigung — refreshte ständig meine E-Mails, überzeugt, irgendwo das falsche Kästchen angekreuzt zu haben und dass der Antrag still abgelehnt wurde. War er nicht. Lief gut durch.

Zehn Tage leise Hintergrundangst wegen eines Formulars, das am Ende auch — fine war. Es gibt hier ein Muster.

Der Marketing-Website-Seitenquest

Beim Einrichten von App Store Connect bemerkte ich, dass es eine Support-URL, eine Marketing-URL und eine Datenschutzrichtlinien-URL verlangte. Richtig. Also brauche ich auch noch eine ganze Website.

Ich kaufte die Domain pulsefield.app, nutzte v0 als Ausgangspunkt und baute sie von dort aus weiter. Keine Beschwerde — es ist gut, sie zu haben — aber es war ein Umweg, den ich nicht eingeplant hatte, genau zu dem Zeitpunkt, als ich schon im „Arbeiten, essen, an Pulsefield arbeiten, schlafen, wiederholen"-Modus war.

Der App-Review selbst

Mit all dem endlich an Ort und Stelle war der eigentliche Review-Prozess — im Vergleich — ziemlich überschaubar.

Meine Strategie von Anfang an: klein anfangen. Erst eine minimale Version einreichen, genehmigt bekommen, Vertrauen aufbauen. Dieselbe Methode, die ich für neue Features bei der Arbeit verwende. Ich implementierte das Kerngameplay, grundlegende Benutzeroberfläche, drückte auf Einreichen, wurde sofort mit einer Wand von Warnungen über nicht ausgefüllte Felder bombardiert, behob sie, reichte erneut ein.

Dann das Warten. Es gibt eine spezifische Art von Angst beim App-Store-Review. Man stellt sich vor, wie jemand in Kalifornien die App öffnet, dreissig Sekunden damit verbringt, und lachend auf Ablehnen drückt. Wahrscheinlich nicht was passiert. Aber der Gedanke besucht einen trotzdem.

„In Review". Dann: „Pending Developer Release".

Erste Einreichung, erste Genehmigung. Ich werde nicht so tun, als wäre ich nicht unverhältnismässig stolz auf mich gewesen.

Vollständig von meiner eigenen Überheblichkeit zerstört werden

Nach dem Beta-Testing — einschliesslich der demütigenden Erfahrung, echten Nutzern zuzuschauen, wie sie beim Tutorial komplett scheiterten, während ich danebensass und nichts sagte — habe ich einige Dinge behoben und war bereit, 1.0.0 für den echten Release einzureichen.

Zwei Genehmigungen. Null Ablehnungen. Ich war, im Nachhinein betrachtet, gefährlich selbstsicher.

Ich erweiterte die Verfügbarkeit von der Schweiz auf zehn Länder — Deutschland, Österreich, Grossbritannien, USA, Australien, Singapur und mehr. Ich übersprang den TestFlight-Beta-Review-Schritt komplett. Screenshots aktualisiert, Build ausgewählt, auf Einreichen geklickt.

Keine Stunde später war meine App in Review. Und dann — eine Minute danach — abgelehnt.

Richtlinie 2.1 — Weitere Informationen erforderlich.

Apple wollte eine Screen-Recording, Klarstellungen zu externen Diensten und Informationen über regionale Unterschiede. Als ich es las, war ich zunächst wirklich verwirrt — was hatte sich geändert? Ich hatte keine neuen Features eingeführt. Aber dann verstand ich es: Ich hatte nie einmal das Review-Notizen-Feld ausgefüllt. Nie eine Screen-Recording eingereicht. Und ich hatte gerade von einem Land auf zehn Märkte inklusive USA expandiert. Natürlich hat das einen anderen Review-Ablauf ausgelöst.

Mein Gehirn ging auf Wanderschaft. Bestrafte Apple mich dafür, dass ich frühere Builds eingereicht, sie genehmigt, und dann den Release selbst abgelehnt hatte? Hat jemand meinen Account als Spam markiert? Hatte ich vorher Glück mit einem Reviewer, der in der Schweiz aufgewachsen war und aus Solidarität einfach alles abgestempelt hat? Wahrscheinlich nicht. Aber ich dachte darüber nach.

Die rationale Erklärung: Von der Schweiz auf zehn Länder inklusive USA zu erweitern eskaliert fast sicher die Prüfung. Das war's. Das war wahrscheinlich alles.

Erneute Einreichung

Ich nahm eine Bildschirmaufnahme des Gameplays auf, schrieb ordentliche Review-Notizen, die erklärten, dass die App keine externen Dienste, keine Anmeldung, keine Konten verwendet — nur Core Haptics, lokale Benachrichtigungen und optionales Game Center — und reichte erneut ein. 24–48 Stunden diesmal.

Mitten in der Nacht vibrierte mein Telefon.

Pending Developer Release.

Fertig.

Was ich gerne vorher gewusst hätte

Das Business-Setup ist ein eigenes Projekt. Steuerformulare, Bankverbindungen, regulatorische Einreichungen — nichts davon ist unmöglich, aber nichts davon ist sofort erledigt, und alles muss passieren, bevor man veröffentlichen kann. Behandle es von Anfang an als parallelen Workstream, nicht als Nachgedanken.

Fülle das Review-Informationsfeld jedes Mal aus. Egal wie einfach die App ist. Nimm an, der Reviewer weiss nichts. Schreib es so, als würdest du es jemandem erklären, der noch nie von deiner App gehört hat und fünf andere Apps durchzugehen hat.

Überspring den TestFlight-Beta-Review nicht. Es ist ein leichterer Review vor der vollständigen Distribution, der mein Guideline-2.1-Problem aufgedeckt hätte, bevor ich eine Einreichung dafür verschwendet hätte. Ich habe das auf die teure Weise gelernt.

Diese Genehmigungsbenachrichtigung fühlt sich unglaublich an. Selbst wenn man sie halb erwartet. Etwas daran, dass ein echter Mensch etwas anschaut, das man von Null an gebaut hat, und entscheidet, dass es in den App Store gehört, trifft anders als ein bestandener Test.

Der Code war der Teil, auf den ich mich vorbereitet fühlte. Alles drum herum — das hat mich wirklich überrascht.