App-Store-Review und Datenschutzangaben

Das Problem: Der letzte Schritt

Deine App ist fertig, getestet, in TestFlight ausprobiert (Lektion 4.21). Jetzt soll sie in den App Store. Dafür musst du zwei Dinge schaffen:

1. Einen Store-Eintrag, der Menschen überzeugt, deine App zu laden.
2. Die App-Prüfung (App Review): Jede App und jedes Update wird von Apple geprüft, bevor es erscheint.

Die Prüfung hat einen strengen Ruf. In Wirklichkeit werden die meisten Apps beim ersten oder zweiten Versuch angenommen, und fast alle Ablehnungen haben dieselben wenigen Ursachen. Wer sie kennt, kommt meist ohne Umwege durch.

Der Store-Eintrag

In App Store Connect wählst du deine App und links die Version, etwa 1.0 Vorbereitung für Übermittlung. Dort füllst du alles aus, was im App Store erscheint.

Name und Untertitel

• Name (bis 30 Zeichen): Der Name im Store. Er muss nicht exakt der Name unter dem Symbol sein. „Ausgaben – Haushaltsbuch“ ist erlaubt.
• Untertitel (bis 30 Zeichen): Eine kurze Zeile darunter, etwa „Wohin dein Geld fließt“.

Beides fließt in die Suche ein. Wähle Wörter, nach denen Menschen suchen würden.

Beschreibung

• Werbetext (bis 170 Zeichen): Erscheint ganz oben in der Beschreibung und kann ohne neue Prüfung geändert werden. Gut für Neuigkeiten.
• Beschreibung (bis 4.000 Zeichen): Was die App kann. Die ersten zwei, drei Zeilen sind am wichtigsten, denn danach muss man auf „Mehr“ tippen.

Ein bewährter Aufbau:

1. Ein Satz, der das Problem und die Lösung nennt.
2. Die wichtigsten Funktionen als kurze Liste.
3. Was die App besonders macht, etwa „Alle Daten bleiben auf deinem Gerät“.

Schlüsselwörter

Keywords (bis 100 Zeichen, mit Kommas getrennt): Begriffe, unter denen die App gefunden werden soll, die nicht schon im Namen oder Untertitel stehen. Zum Beispiel: budget,finanzen,sparen,kosten,haushalt,geld,diagramm.

Screenshots

Screenshots sind oft das Erste, worauf Menschen schauen, noch vor der Beschreibung. Pflicht ist mindestens ein Satz für das größte iPhone-Format. App Store Connect skaliert ihn für kleinere Geräte. Unterstützt deine App das iPad, brauchst du auch iPad-Screenshots.

Tipps:

• Bis zu zehn Screenshots pro Gerät. Die ersten drei sind die wichtigsten, weil sie in den Suchergebnissen erscheinen.
• Zeig die App in Benutzung, mit realistischen Daten, nicht leer.
• Eine kurze Überschrift über jedem Bild hilft: „Ausgaben in Sekunden erfassen“.
• Automatisch erstellen kannst du sie mit UI-Tests (Lektion 4.12, Übung 3).

Zusätzlich kannst du App-Vorschauvideos von bis zu 30 Sekunden hochladen.

Weitere Angaben

• Kategorie: Etwa „Finanzen“ als primäre und „Produktivität“ als sekundäre Kategorie.
• Altersfreigabe: Ein Fragebogen zu Inhalten wie Gewalt oder Glücksspiel. Daraus ergibt sich die Freigabe.
• Support-URL: Eine Webseite, auf der Nutzer Hilfe finden. Pflicht.
• Datenschutzrichtlinie (URL): Pflicht für alle Apps, auch für solche, die keine Daten sammeln.
• Copyright: Etwa „2026 Dein Name“.
• Preis und Verfügbarkeit: Kostenlos oder ein Preis, und in welchen Ländern.

Datenschutz: die drei Ebenen

Datenschutz ist bei Apple kein Nebenthema, sondern einer der häufigsten Gründe für Ablehnungen. Es gibt drei Ebenen, die alle stimmen müssen.

1. Begründungen für Berechtigungen

Für jede geschützte Funktion braucht die App einen Begründungstext in der Info. Er erscheint in der Abfrage, die iOS dem Nutzer zeigt:

Der Text muss konkret sagen, wofür. „Die App braucht Zugriff auf die Kamera“ wird abgelehnt. „Damit du Kassenbons fotografieren und an Ausgaben anhängen kannst“ ist richtig.

2. Das Privacy Manifest

Seit 2024 braucht jede App eine Datei PrivacyInfo.xcprivacy, das Privacy Manifest. Darin erklärst du, welche Daten deine App sammelt und welche bestimmten Systemschnittstellen sie aus welchem Grund verwendet.

Anlegen: Datei → Neu → Datei aus Vorlage → App Privacy.

Besonders wichtig sind die „Required Reason APIs“: Schnittstellen, die theoretisch zum Erkennen von Geräten missbraucht werden könnten. Verwendest du sie, musst du einen erlaubten Grund angeben. Die häufigste davon in normalen Apps ist UserDefaults, das du mit @AppStorage (Lektion 3.13) fast sicher verwendest:

• Privacy Accessed API Types → User Defaults → Grund CA92.1 („Zugriff auf Informationen, die von der App selbst geschrieben wurden“).

Auch die Paketbibliotheken, die du verwendest (Lektion 4.14), müssen eigene Privacy Manifests mitbringen. Bekannte Bibliotheken tun das bereits.

3. Die Datenschutzangaben im App Store

In App Store Connect unter App-Datenschutz beantwortest du einen Fragebogen: Welche Daten sammelt die App, wofür, sind sie mit der Person verknüpft, werden sie zum Tracking verwendet? Daraus entstehen die Datenschutz-Etiketten, die im App Store wie Nährwertangaben auf einer Packung angezeigt werden.

Für den Ausgaben-Tracker ist das einfach: Alle Daten bleiben auf dem Gerät, nichts wird an einen Server geschickt. Die Antwort lautet: „Es werden keine Daten erfasst.“ Das ist ein echtes Verkaufsargument.

Sobald du aber einen Analysedienst, ein Absturzwerkzeug, Werbung oder ein Backend mit Konten einbaust, musst du die entsprechenden Datenarten angeben. Die Angaben müssen ehrlich und vollständig sein. Falsche Angaben sind ein Grund, die App zu entfernen.

Die häufigsten Gründe für Ablehnungen

Apples App Review Guidelines sind lang, aber die meisten Ablehnungen fallen in wenige Gruppen.

Abstürze und offensichtliche Fehler (Richtlinie 2.1)

Die App stürzt ab oder ein Button tut nichts. Teste die App vor dem Einreichen gründlich auf einem echten Gerät, auch mit leeren Daten, ohne Internet und mit großer Schrift.

Unvollständige Informationen (2.1)

Braucht die App eine Anmeldung, muss das Prüfteam sich anmelden können. Gib unter App-Prüfungsinformationen einen Demo-Zugang an. Erkläre in den Notizen alles, was nicht offensichtlich ist, etwa wie man eine bestimmte Funktion erreicht.

Platzhalter und Unfertiges (2.3)

„Lorem ipsum“, „Kommt bald“, leere Bildschirme, Test-Daten. Alles, was sichtbar ist, muss fertig sein. Was nicht fertig ist, kommt nicht hinein.

Irreführende Metadaten (2.3)

Screenshots, die Funktionen zeigen, die es nicht gibt. Beschreibungen, die mehr versprechen, als die App hält. Namen anderer Apps in den Schlüsselwörtern.

Zu wenig Inhalt (4.2)

Eine App, die nur eine Website anzeigt, oder die so wenig kann, dass sie keine eigene App rechtfertigt. Dein Ausgaben-Tracker ist davon weit entfernt.

Nachahmung (4.1)

Apps, die eine bekannte App kopieren, mit ähnlichem Namen, Symbol oder Aussehen. Eigene Ideen, eigene Gestaltung.

Datenschutz (5.1)

Fehlende oder unklare Begründungen für Berechtigungen, eine fehlende Datenschutzrichtlinie, Datenschutzangaben, die nicht zum Verhalten der App passen. Und: Bietet die App das Anlegen eines Kontos an, muss sie auch das Löschen des Kontos in der App anbieten.

Bezahlung (3.1)

Digitale Inhalte und Funktionen innerhalb der App, etwa Premium-Funktionen oder ein Abo, müssen über Apples In-App-Käufe verkauft werden. Für physische Waren und Dienstleistungen außerhalb der App, etwa eine Essenslieferung, gilt das nicht. Die genauen Regeln unterscheiden sich je nach Land und ändern sich gelegentlich. Lies vor dem Einbau von Bezahlfunktionen die aktuelle Fassung der Richtlinien.

Einreichen

1. In der Version unter Build auf + klicken und den TestFlight-Build wählen, der veröffentlicht werden soll.
2. App-Prüfungsinformationen ausfüllen: Kontaktdaten, eventuell Demo-Zugang und Notizen.
3. Version veröffentlichen: Wähle, was nach der Annahme passieren soll:
   • Automatisch veröffentlichen, sobald die App angenommen ist.
   • Manuell veröffentlichen: Du drückst selbst auf den Knopf, etwa zu einem geplanten Termin.
   • Automatisch nach Datum: frühestens zu einem bestimmten Zeitpunkt.
4. Zur Prüfung hinzufügen und dann An App-Prüfung senden.

Die Prüfung dauert meist 24 bis 48 Stunden, oft weniger. Den Status siehst du in App Store Connect und in der App App Store Connect auf dem iPhone, die dich auch benachrichtigt.

Wenn die App abgelehnt wird

Eine Ablehnung ist kein Drama. Du bekommst im Resolution Center eine Nachricht mit der betroffenen Richtlinie, einer Erklärung und oft Screenshots.

• Verstehst du das Problem: Behebe es, erhöhe die Build-Nummer, lade einen neuen Build hoch und reiche erneut ein. Schreib im Resolution Center kurz, was du geändert hast.
• Liegt ein Missverständnis vor: Antworte freundlich und sachlich und erkläre, wie die Funktion gemeint ist. Oft reicht das, ohne neuen Build.
• Bist du anderer Meinung: Du kannst beim App Review Board Einspruch einlegen.

Ein freundlicher, klarer Ton hilft. Auf der anderen Seite sitzen Menschen.

Nach der Veröffentlichung

• Phasenweise Veröffentlichung: Bei Updates kannst du Phased Release aktivieren. Das Update wird über sieben Tage schrittweise an mehr Nutzer verteilt. Taucht ein schwerer Fehler auf, kannst du anhalten.
• Bewertungen: Mit @Environment(\.requestReview) kannst du zu einem passenden Moment, etwa nach dem zehnten erfassten Eintrag, um eine Bewertung bitten. Das System entscheidet, ob und wie oft die Abfrage wirklich erscheint.
• Auf Bewertungen antworten: In App Store Connect kannst du öffentlich auf Bewertungen antworten.
• Updates: Für jede neue Version erhöhst du die Version (etwa 1.1), lädst einen Build hoch und füllst „Neuerungen in dieser Version“ aus. Updates durchlaufen dieselbe Prüfung, meist schneller.

Typische Fehler

„Missing Purpose String in Info.plist“

Eine geschützte Funktion wird verwendet, aber die Begründung fehlt. Ergänze den passenden NS…UsageDescription-Eintrag mit einem konkreten Text.

E-Mail „ITMS-91053: Missing API declaration“

Das Privacy Manifest fehlt oder nennt eine verwendete Required Reason API nicht, meist UserDefaults. Ergänze sie mit dem passenden Grund.

Ablehnung wegen fehlendem Demo-Zugang

Die App verlangt eine Anmeldung, aber das Prüfteam hatte keine Zugangsdaten. Gib sie in den App-Prüfungsinformationen an.

Screenshots werden nicht akzeptiert

Falsches Format oder falsche Größe. App Store Connect zeigt die erlaubten Größen beim Hochladen an. Screenshots aus dem Simulator des passenden Geräts haben automatisch die richtige Größe.

FAQ

Übungen

Zusammenfassung

• Jede App und jedes Update durchläuft die App-Prüfung. Die meisten Ablehnungen haben wenige, vermeidbare Ursachen.
• Der Store-Eintrag besteht aus Name, Untertitel, Beschreibung, Schlüsselwörtern, Screenshots, Kategorie, Support-URL und Datenschutzrichtlinie.
• Datenschutz hat drei Ebenen: Begründungen für Berechtigungen, das Privacy Manifest (PrivacyInfo.xcprivacy, etwa UserDefaults mit CA92.1) und die Datenschutzangaben in App Store Connect.
• Häufige Ablehnungsgründe: Abstürze, fehlender Demo-Zugang, Platzhalter, irreführende Angaben, Nachahmung, Datenschutzmängel, Bezahlregeln.
• Einreichen: Build wählen, Prüfungsinformationen ausfüllen, Veröffentlichungsart festlegen, senden.
• Bei Ablehnung: im Resolution Center sachlich reagieren, beheben, neu einreichen.
• Nach dem Start: Phased Release, Bewertungsabfrage, Updates mit neuer Version.

Spickzettel

App Store Connect → App → Version
  Name (30) · Untertitel (30) · Werbetext (170) · Beschreibung (4000)
  Keywords (100, kommagetrennt, keine fremden Marken)
  Screenshots (größtes iPhone, bis 10) · Kategorie · Altersfreigabe
  Support-URL · Datenschutzrichtlinie-URL (Pflicht)
  App-Datenschutz: Fragebogen → Datenschutz-Etiketten

Info: NS…UsageDescription mit konkretem Zweck
PrivacyInfo.xcprivacy: User Defaults → CA92.1

Build wählen → App-Prüfungsinformationen (Demo-Zugang, Notizen)
→ Veröffentlichung: automatisch / manuell / nach Datum → An App-Prüfung senden

Abgelehnt? Resolution Center → beheben → Build-Nummer erhöhen → erneut senden

@Environment(\.requestReview) private var requestReview
requestReview()   // zu einem passenden Moment