Eine fertige App ist nur die halbe Miete. Zwischen der letzten Codezeile und dem Moment, in dem ein Fremder deine App im App Store herunterlädt, liegt ein Prozess, den viele unterschätzen: Apples App Review. Dieser Exkurs zeigt den kompletten Weg von der Idee bis zur Veröffentlichung, nicht in der Theorie, sondern genau so, wie wir ihn mit Waidly durchlaufen haben. Inklusive der Ablehnungen, die dazugehören.
Der Überblick: ein Kreislauf, kein gerader Weg
Viele stellen sich die Veröffentlichung als Einbahnstraße vor: programmieren, hochladen, fertig. In Wirklichkeit ist es ein Kreislauf, und gleich auf zwei Ebenen. Während der Entwicklung dreht sich alles um Entwickeln → Testen → Feedback → wieder Entwickeln. Und beim Einreichen wiederholt sich das Spiel: Hochladen → Ablehnung → Korrigieren → erneut hochladen. Bei Waidly hat es mehrere Runden gebraucht, bis die App live war. Das ist nicht das Zeichen einer schlechten App, das ist der Normalfall.
Die Stationen, die wir uns gleich im Detail ansehen:
- Entwickeln, aus der Idee wird ein lauffähiger Kern
- Apple Developer Account, die Eintrittskarte
- App Store Connect, die Schaltzentrale
- Beta-Test mit TestFlight, echte Nutzer, echtes Feedback
- Der Feedback-Loop, testen, lernen, nachbessern
- Voraussetzungen für die Einreichung, Texte, Screenshots, Datenschutz
- Erklärungen, Screenshots und Videos für den Prüfer
- Hochladen und zur Prüfung einreichen
- Die Ablehnung, und wie man darauf reagiert
- Korrigieren, testen, neu hochladen
- Freigegeben und veröffentlichen
1. Entwickeln
Am Anfang steht die Idee. Bei Waidly war das ein digitales Jagdtagebuch, das offline funktioniert und ohne Abo auskommt, gebaut mit SwiftUI für iPhone, iPad und Apple Watch. Der wichtigste Rat für diese Phase: klein anfangen. Lieber ein kleiner, runder Funktionsumfang, der wirklich funktioniert, als hundert halbfertige Features.
Das ist nicht nur eine Stil-Frage, sondern auch eine Apple-Regel. Die Richtlinie 2.1 (App Completeness) verlangt, dass eine eingereichte App fertig ist: keine Platzhalter, keine "Coming soon"-Buttons, keine Demo-Inhalte, keine offensichtlichen Bugs. Wer eine halbfertige App einreicht, kassiert die erste Ablehnung, bevor der Prüfer überhaupt richtig hinschaut.
Definiere die kleinste Version, die für echte Nutzer einen Wert hat (das "Minimum Viable Product"). Bei Waidly war das: Einträge erfassen, Revier mit Einrichtungen anlegen, Jagdzeiten nachschlagen. Alles andere, Statistiken, Kassenbuch, Apple Watch, NFC, kam in späteren Updates dazu.
2. Der Apple Developer Account
Ohne Mitgliedschaft im Apple Developer Program kommt nichts in den Store. Sie kostet 99 Euro pro Jahr. Dabei gibt es zwei Arten von Accounts:
- Einzelperson: Schnell eingerichtet, im Store erscheint dein bürgerlicher Name als Anbieter.
- Organisation: Im Store erscheint der Firmenname. Dafür braucht es eine D-U-N-S-Nummer, eine kostenlose, weltweit eindeutige Firmenkennung. Die Beantragung dauert ein paar Tage.
Waidly wird über die RIPPCON GmbH vertrieben, also ein Organisations-Account mit D-U-N-S-Nummer. Wer plant, später ernsthaft etwas zu verkaufen, fährt mit dem Firmen-Account besser.
Bevor du eine bezahlte App oder In-App-Käufe anbieten kannst, musst du in App Store Connect den "Paid Apps"-Vertrag akzeptieren und deine Bank- und Steuerdaten hinterlegen. Vergisst man das, funktionieren nicht einmal Test-Käufe in der Sandbox, ein Klassiker unter den selbst gemachten Stolpersteinen.
3. App Store Connect
App Store Connect ist die Web-Schaltzentrale für alles rund um deine App: Hier legst du den App-Eintrag an, lädst Builds hoch, pflegst Texte und Screenshots, verwaltest TestFlight und reichst zur Prüfung ein.
Der App-Eintrag bekommt einen Namen, eine eindeutige Bundle-ID (bei Waidly z. B. de.rippcon.waidly), eine Kategorie und die unterstützten Sprachen. Dazu kommen technische Dinge wie Signing-Zertifikate und Provisioning Profiles, die nimmt dir Xcode heute mit "Automatically manage signing" weitgehend ab.
4. Beta-Test mit TestFlight
Bevor die Öffentlichkeit die App sieht, sollten echte Menschen sie ausprobieren. Genau dafür gibt es TestFlight, Apples Beta-System. Du lädst aus Xcode einen Build hoch (Product → Archive → Distribute), und der landet in TestFlight. Dort gibt es zwei Gruppen:
- Interne Tester (Mitglieder deines Teams, bis zu 100): bekommen den Build sofort.
- Externe Tester (bis zu 10.000, per E-Mail oder öffentlichem Link): hier prüft Apple den ersten Build kurz ("Beta App Review"), danach geht es schnell.
Bei Waidly haben echte Jäger getestet, und genau das ist Gold wert. Ein Tester, Nils, stieß auf einen fiesen Foto-Bug: Fotos im Querformat (16:9) schnitten in der Detailansicht Text und Icons am Rand ab. Uns selbst war das nie aufgefallen, weil unsere Testfotos zufällig alle im Hochformat waren. Solche Dinge findet man nicht am Schreibtisch.
Du kennst deine App zu gut. Du tippst die "richtigen" Knöpfe, machst die "richtigen" Fotos, gehst den Weg, den du vorgesehen hast. Tester tun all das nicht, und genau deshalb finden sie die Fehler, die später sonst echte Nutzer (oder der Apple-Prüfer) finden würden.
5. Der Feedback-Loop
Jetzt beginnt der eigentliche Rhythmus der Entwicklung: Entwickeln → Beta → Feedback → wieder Entwickeln. Aus dem Tester-Feedback werden konkrete Aufgaben. Bei Waidly waren das zum Beispiel der erwähnte Foto-Fix, ein eigenes Fadenkreuz-Icon für Erlegungen in der Streckenliste und diverse Anpassungen am Kartenlayout.
Wichtig ist, nicht jede Anregung blind umzusetzen. Feedback ist Rohstoff, kein Befehl. Die Kunst besteht darin, die Wünsche herauszufiltern, die zur Vision der App passen, und den Rest höflich auf später zu verschieben. Sonst verliert die App ihren roten Faden.
6. Voraussetzungen für die Einreichung
Bevor du auf "Zur Prüfung einreichen" klicken kannst, will App Store Connect erstaunlich viel von dir wissen. Das alles gehört zum sogenannten "Metadaten"-Teil:
- Texte: App-Name, Untertitel, Beschreibung, Werbetext, Keywords (nur 100 Zeichen, jedes zählt), Support-URL und Marketing-URL.
- Screenshots in exakt vorgegebenen Größen (mindestens für ein großes iPhone, bei iPad-Unterstützung zusätzlich fürs iPad). Sie müssen die echte App zeigen, reine Marketing-Grafik ohne App-Inhalt wird abgelehnt.
- App-Datenschutz (die "Privacy Nutrition Labels"): Du deklarierst, welche Daten du erhebst und wofür. Bei Waidly ist das wenig, die Daten bleiben auf dem Gerät bzw. in der privaten iCloud des Nutzers. Trotzdem muss man jede Datenart sauber angeben.
- Altersfreigabe über einen Fragebogen, Export-Compliance (Stichwort Verschlüsselung) und die Bestätigung, dass du die Inhaltsrechte hast.
Falsche oder fehlende Screenshots und ein unvollständiges Datenschutz-Label sind zwei der häufigsten Gründe für eine sofortige Ablehnung, noch bevor der eigentliche Funktionstest beginnt. Hier lohnt sich Sorgfalt mehr als irgendwo sonst.
Apple verlangt Screenshots in exakten Pixelgrößen je Geräteklasse (mehrere iPhone- und iPad-Größen). Damit man die nicht mühsam von Hand zuschneidet, habe ich ein kleines, quelloffenes Tool geschrieben, das App-Screenshots automatisch für alle Apple-Geräte in den passenden Größen rendert: DevScreenshot auf GitHub.
7. Erklärungen, Screenshots und Videos für den Prüfer
Hinter dem App Review steht ein Mensch mit wenig Zeit und vielen Apps. Ihm die Arbeit zu erleichtern, ist im eigenen Interesse, gerade bei Funktionen, die nicht selbsterklärend sind oder die er im Simulator gar nicht testen kann.
- Review-Notizen: Ein Freitextfeld, in dem du dem Prüfer Funktionen erklärst. Falls ein Login nötig ist, gehören hier Demo-Zugangsdaten hinein.
- Demo-Video oder genaue Beschreibung: Für Hardware-Funktionen wie NFC, Kamera oder Standort-Nutzung im Hintergrund kann der Prüfer einen Nachweis verlangen, weil er sie auf seinem Testgerät nicht ohne Weiteres nachstellen kann. Bei Waidly mussten wir z. B. erklären, wofür wir NFC verwenden (Hochsitze, Waffen und Hunde markieren) und warum die App auf den Standort zugreift.
Je klarer du erklärst, was eine ungewöhnliche Funktion tut und warum sie eine bestimmte Berechtigung braucht, desto reibungsloser läuft das Review. Ein gut geschriebener Review-Hinweis erspart oft eine komplette Ablehnungsrunde.
8. Hochladen und zur Prüfung einreichen
Ist alles vorbereitet, geht es ans Einreichen. In Xcode zählst du die Build-Nummer hoch (jeder Upload braucht eine neue), erstellst ein Archive, lädst es hoch und ordnest es in App Store Connect der Version zu. Dann ein Klick auf "Zur Prüfung einreichen", und es heißt: warten. Die Review-Zeit liegt heute meist bei 24 bis 48 Stunden.
9. Die Ablehnung (gehört dazu!)
Jetzt kommt der Teil, den niemand gern hört, der aber fast immer passiert: die Ablehnung. Apple schickt eine Nachricht mit der verletzten Richtlinie, einer Nummer aus den "App Review Guidelines". Bei Waidly hatten wir gleich mehrere Runden. Ein ehrlicher Auszug:
- Guideline 2.5.1 (HealthKit): Wir lasen Schritte und Distanz über HealthKit ein, ohne diese Funktion klar in der Oberfläche auszuweisen. Apples Hinweis: Wenn nur Bewegungsdaten gebraucht werden, nimm Core Motion. → Wir haben HealthKit komplett aus der App entfernt und auf Core Motion umgestellt. Funktion blieb, Beanstandung weg.
- Guideline 5.2.5 (Apple-Dienste): Hier ging es um die korrekte Nutzung von Apple WeatherKit. → Wir haben WeatherKit entfernt; die Wetterdaten kommen jetzt von Bright Sky und Open-Meteo.
- Guideline 2.1 (In-App-Käufe): Unser Premium-Kauf war nicht zusammen mit dem Build zur Prüfung eingereicht, deshalb zeigte die Paywall einen Fehler. → IAP korrekt eingereicht und die Paywall so abgesichert, dass sie auch ohne geladenes Produkt sauber bleibt.
- Standort und NFC: Nachfragen, warum die App den Standort bzw. NFC nutzt, hier reichte eine genaue Erklärung im Resolution Center.
Wichtig ist die Haltung dazu: Eine Ablehnung ist kein "Nein", sondern ein "So nicht". Über "Auf die Prüfung antworten" landest du im Resolution Center und kannst direkt mit dem Prüfer schreiben, entweder sachlich erklären (wenn ein Missverständnis vorliegt) oder ankündigen, dass du nachbesserst.
Apple nennt dir in der Ablehnung exakt die Richtlinie und meist auch den konkreten Punkt. Diese Nummer ist Gold wert: Die "App Review Guidelines" sind öffentlich, und mit der Nummer findest du sofort, was genau erwartet wird. Nicht raten, nachlesen.
10. Korrigieren, testen, neu hochladen
Jetzt schließt sich der zweite Loop. Du baust den Fix ein, testest ihn lokal, im Simulator und auf einem echten Gerät, zählst die Build-Nummer hoch, lädst neu hoch und reichst erneut ein, am besten mit einer kurzen Antwort an den Prüfer, was sich geändert hat.
Und ja: Manchmal folgt die nächste Ablehnung mit einem anderen Punkt, den die erste noch gar nicht erwähnt hatte. Auch das ist normal, jeder Build wird frisch geprüft. Bei Waidly hat es mehrere solcher Runden gebraucht. Die einzige falsche Reaktion ist, aufzugeben.
11. Freigegeben und veröffentlichen
Irgendwann steht im Status endlich: "Bereit für Vertrieb". Jetzt entscheidet deine Einstellung, was passiert:
- Automatisch veröffentlichen: Die App geht sofort nach der Freigabe live.
- Manuell veröffentlichen: Du drückst selbst den Knopf, praktisch, wenn der Launch mit einer Ankündigung oder einem bestimmten Datum zusammenfallen soll.
Danach dauert es meist noch ein paar Stunden, bis die App weltweit (oder in den von dir gewählten Ländern) im Store auftaucht und über die Suche auffindbar ist. Genau dieser Moment, die erste fremde Person lädt deine App, ist die Belohnung für den ganzen Kreislauf.
Und dann? Der Loop beginnt von vorn
Die Veröffentlichung ist kein Ziel, sondern ein neuer Startpunkt. Jedes Update durchläuft denselben Prozess, Build hochladen, prüfen lassen, freigeben. Die Beta-Phase ist bei Updates meist kürzer, aber das Review bleibt. Waidly ist seit dem Launch schon mehrfach aktualisiert worden, jedes Mal wieder durch Beta, Review und Freigabe. Genau dieser Kreislauf hält eine App lebendig, und macht sie mit jeder Runde ein Stück besser.
Eine App im Store zu haben heißt nicht, fertig zu sein. Es heißt, ab jetzt sichtbar weiterzuentwickeln.
Das Ergebnis dieses Wegs: Waidly
Entwickelt, getestet, mehrfach abgelehnt, nachgebessert, und schließlich freigegeben. Schau dir an, was am Ende des Kreislaufs herausgekommen ist: das digitale Jagdtagebuch fürs Revier. Ohne Cloud-Zwang, ohne Abo.
Waidly im App Store laden Waidly bei Google Play laden