App-Store-Veröffentlichung: Hilfe bei Einreichung und Ablehnungen

Die App ist fertig, aber zwischen dem letzten Build und dem Download-Button liegen Entwicklerkonten, Zertifikate, Store-Texte, Datenschutzangaben und eine Prüfung durch Apple bzw. Google. Viele Teams, die ihre App mit KI-Werkzeugen wie Lovable, Base44, Claude Code oder Codex gebaut haben, stehen genau hier zum ersten Mal. Dieser Beitrag zeigt, welche Schritte Sie gut selbst erledigen können, wo sich Unterstützung lohnt und wie Sie auf eine Ablehnung reagieren.

Was Sie selbst erledigen können – und was oft hakt

Wer bereits ein Unternehmenskonto bei Apple hat und eine native App mit sauberem Build-Prozess, schafft die Einreichung meist allein. Schwierig wird es, wenn mehrere dieser Punkte gleichzeitig neu sind.

Drei Situationen, in denen sich Hilfe wirklich lohnt

1. Erste Veröffentlichung ohne mobile Erfahrung im Team. Signierung und Store-Konfiguration sind Einmalaufwand mit hoher Fehlerquote. Jeder Fehlversuch kostet einen kompletten Build-Upload-Prüf-Zyklus.
2. Wiederholte Ablehnungen. Wenn eine App zum zweiten oder dritten Mal mit derselben Richtlinie abgelehnt wird, fehlt meist nicht Fleiß, sondern Erfahrung, was die Prüfer konkret erwarten.
3. Regelmäßige Releases ohne DevOps-Kapazität. Wer alle paar Wochen ein Update ausliefern will, braucht eine automatisierte Pipeline. Hintergründe dazu im Beitrag CI/CD for AI-Generated Mobile Apps.

Welche Art von Unterstützung zu Ihnen passt

• Selbststudium mit Checklisten: günstig, gut für einfache Apps und Teams mit Zeit. Ein guter Startpunkt ist unsere App Store Submission Checklist.
• Freelancer: flexibel, Qualität stark personenabhängig. Klären Sie, ob die Person in Ihren Konten arbeitet und was nach dem Projekt dokumentiert übergeben wird.
• Spezialisierter Einreichungsservice: fokussiert auf Signierung, CI/CD, Upload und Begleitung der Prüfung. appsubmitter.io kombiniert dafür KI-gestützte Abläufe mit menschlicher Begleitung und arbeitet ausschließlich in Ihren eigenen Entwicklerkonten.
• Agentur oder Entwicklungspartner: sinnvoll, wenn die App selbst noch Arbeit braucht, etwa native Funktionen gegen eine 4.2-Ablehnung oder eine Überarbeitung von KI-generiertem Code.

Worauf Sie bei jedem Dienstleister bestehen sollten

• Konten in Ihrem Namen. Die App muss in Ihrem Apple- und Google-Konto veröffentlicht werden, nicht im Konto des Dienstleisters. Ein späterer Transfer ist möglich, aber aufwendig.
• Zugriff über Rollen, nicht über Passwörter. Laden Sie Helfer über App Store Connect und die Play Console mit passenden Rollen ein. Geben Sie keine Zugangsdaten Ihrer Apple-ID weiter.
• Zertifikate und Schlüssel bleiben bei Ihnen. Der Upload-Keystore für Android und das Distribution-Zertifikat für iOS gehören dokumentiert in Ihren Besitz.
• Transparente Kommunikation mit den Prüfern. Sie sollten jede Antwort im Resolution Center bzw. in der Play Console nachlesen können.
• Datenschutz geklärt. Wer in Ihre Konten schaut, sieht ggf. Nutzerdaten und Verkaufszahlen. Ein Auftragsverarbeitungsvertrag (AVV) und klare Zugriffsrechte gehören dazu.

Was Sie vor dem ersten Gespräch bereithalten sollten

Je vollständiger die Unterlagen, desto schneller und günstiger die Unterstützung. Diese Punkte sollten Sie klären, bevor Sie Hilfe anfragen:

• Zugang zum Quellcode bzw. zum Repository und die verwendete Technologie (nativ, React Native, Flutter, Web-App)
• Status der Entwicklerkonten: vorhanden, beantragt oder noch offen, inklusive D-U-N-S-Nummer
• Bundle-ID bzw. Paketname, App-Name und gewünschte Länder
• Liste der eingebundenen Dienste und SDKs (Analyse, Werbung, Login, Zahlungen) für die Datenschutzangaben
• Datenschutzerklärung und Support-Seite unter einer erreichbaren URL
• Bisherige Ablehnungsmitteilungen im Wortlaut, falls vorhanden

Wenn die Ablehnung kommt: ein Ablauf in fünf Schritten

1. Genau lesen. Notieren Sie die Richtliniennummer und jeden konkreten Hinweis der Prüfer, inklusive Screenshots.
2. Einordnen. Handelt es sich um einen Metadatenfehler (schnell behoben), fehlende Funktionen (Entwicklungsarbeit) oder ein Missverständnis (Antwort genügt)?
3. Beheben und belegen. Ändern Sie, was nötig ist, und dokumentieren Sie es: Demo-Zugang, kurze Bildschirmaufnahme, Hinweis auf die Stelle in der App.
4. Sachlich antworten. Kurz, höflich, konkret. Bei Apple über das Resolution Center; bei grundsätzlichen Unstimmigkeiten gibt es das Einspruchsverfahren beim App Review Board.
5. Lernen festhalten. Ergänzen Sie Ihre Release-Checkliste, damit derselbe Fehler beim nächsten Update nicht wieder auftritt.

Die häufigsten Gründe und passenden Lösungen haben wir in The Most Common App Store Rejection Reasons und für Android in Google Play Rejections and Policy Violations zusammengestellt.

Sonderfall: KI-gebaute Web-Apps

Viele Apps aus Lovable, Base44 oder Bolt sind technisch Web-Apps. Werden sie nur in eine WebView verpackt, droht bei Apple die Ablehnung nach Richtlinie 4.2 (Minimum Functionality). Prüfer erwarten echten Mehrwert gegenüber der Website: Push-Benachrichtigungen, Offline-Fähigkeit, native Navigation oder Gerätefunktionen. Wie das konkret aussieht, beschreibt unser Leitfaden Lovable-App in den App Store und Google Play Store bringen.

Bei Google Play die Wartezeit einplanen

Private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, müssen vor dem Produktionszugang einen geschlossenen Test mit mindestens 12 Testern über 14 aufeinanderfolgende Tage durchführen. Diese zwei Wochen lassen sich nicht abkürzen und gehören in jeden Zeitplan. Organisationskonten sind nach aktuellem Stand davon ausgenommen; prüfen Sie die geltenden Regeln in der Play Console.

Wenn Sie unsicher sind, welcher Weg für Ihre App der richtige ist, können Sie ein kostenloses Erstgespräch buchen und Ihre Situation kurz schildern.