LaunchLint Academy
Die kurze Antwort
- App-Store-Metadaten bestehen aus appweiten Angaben und versionsbezogenen Feldern. Einige lassen sich jederzeit bearbeiten, andere nur in bestimmten Zuständen oder zusammen mit einer neuen Version.
- Prüfe Name, Untertitel, Keywords, Beschreibung, Screenshots, Support- und Datenschutz-URL, Altersfreigabe, Review-Informationen und What's New gegen den tatsächlich eingereichten Build.
- Lokalisierung bedeutet mehr als Übersetzung. Suchsprache, Nutzenversprechen, Screenshots, URLs und rechtliche Angaben müssen für jedes aktive Store-Land zusammenpassen.
1. Zuerst alle Metadaten-Ebenen inventarisieren
App Store Connect trennt Angaben, die für die gesamte App gelten, von Informationen einer konkreten Plattformversion. Name, Untertitel, primäre Sprache, Kategorie oder Bundle ID leben nicht im selben Lebenszyklus wie Screenshots, Beschreibung, Support-URL, What's New und Hinweise für das Prüfteam. Wer alles als ein einziges Formular behandelt, übersieht Sperrzustände und reicht widersprüchliche Versionen ein.
Erstelle vor dem Copywriting eine Feldmatrix. Sie enthält Eigentümer, Sprache, Quelle, letztes Änderungsdatum, Freigabestatus und den Build, zu dem die Aussage gehört. Markiere zusätzlich, ob das Feld öffentlich erscheint, nur für Review bestimmt ist oder technisch aus dem Binary stammt. Diese Trennung verhindert, dass ein Marketing-Update versehentlich eine Angabe zu Store-Regeln oder ein Review-Testkonto veraltet.
Feldmatrix erfassen:
- Appweite und versionsbezogene Angaben
- Öffentliche und private Review-Felder
- Lokalisierbare und nicht lokalisierbare Werte
- Editierbarkeit je App-Status
- Verantwortliche Person und Freigabe
- Bezug zu Version und Build
2. Name, Untertitel und Kategorie präzise wählen
Der App-Name darf laut aktueller Apple-Referenz höchstens 30 Zeichen haben; auch der Untertitel ist auf 30 Zeichen begrenzt. Verwende diese Flächen nicht für eine Kette aus Keywords. Name und Untertitel sollen das Produkt eindeutig identifizieren, den wichtigsten Nutzen erklären und weder fremde Marken noch Funktionen beanspruchen, die im Build nicht vorhanden sind.
Die primäre Kategorie muss die Hauptfunktion widerspiegeln. Eine taktische Kategorie mit scheinbar geringerem Wettbewerb hilft nicht, wenn Produkt, Beschreibung und Funktionsumfang etwas anderes zeigen. Prüfe zudem, ob der Name auf dem Home Screen, in der App, auf der Support-Seite und im Datenschutztext konsistent ist. Abweichungen erschweren Nutzern und Reviewern die Zuordnung.
Name und Einordnung prüfen:
- Zeichenlimits mit echten Unicode-Zeichen messen
- Wichtigsten Nutzen ohne Superlative formulieren
- Keine fremden Marken oder Plattformnamen missbrauchen
- Kategorie nach Kernfunktion wählen
- Anzeigename und Store-Name abgleichen
- Lokalisierte Namen auf Missverständnisse prüfen
3. Keywords und Suchintention ohne Spam abdecken
Apple berücksichtigt unter anderem App-Name, Untertitel, Keyword-Feld und Entwicklername für die Suche. Das Keyword-Feld ist kein Ort für vollständige Sätze. Priorisiere Begriffe, die reale Nutzer für Problem, Aufgabe und Zielgruppe verwenden. Wiederhole nicht mechanisch Wörter, die bereits stark in Name oder Untertitel vertreten sind, und verwende keine geschützten Namen von Wettbewerbern.
Erstelle pro Sprache ein eigenes Keyword-Set. Eine direkte Übersetzung trifft häufig nicht die lokale Suchphrase und kann Zeichenraum verschwenden. Ordne jedem Begriff eine passende Produktfunktion und eine Stelle auf der Produktseite zu. Keywords ohne belegbaren Bezug locken zwar möglicherweise Impressionen an, verschlechtern aber Conversion und erhöhen das Risiko einer irreführenden Darstellung.
Keyword-Review:
- Primäre Aufgabe und Problembegriffe
- Zielgruppe und technischer Kontext
- Lokale statt wörtlich übersetzte Suchsprache
- Keine unnötigen Wiederholungen
- Keine Wettbewerber- oder Markenbegriffe
- Jeder Begriff durch reale Funktion belegbar
4. Beschreibung und Promotional Text am Build ausrichten
Die Beschreibung erklärt Nutzen, Kernfunktionen und Voraussetzungen. Schreibe zuerst für einen Nutzer, der das Produkt nicht kennt, und ordne Features nach Bedeutung statt nach interner Roadmap. Vermeide Aussagen wie vollständig anonym, funktioniert immer offline oder ohne Tracking, solange SDKs, Backend und reale Nutzung diese Absolutheit nicht belegen.
Promotional Text kann unabhängig von einer neuen Version aktualisiert werden, darf aber keine Funktion vorwegnehmen, die der veröffentlichte Build noch nicht enthält. Trenne dauerhaft gültige Produktbeschreibung von zeitlich begrenzter Kampagne. Prüfe Links, Formatierung, Abomodell und Hardware-Voraussetzungen. Ein Screenshot oder Absatz aus einem neueren Branch darf nicht die Fähigkeiten des eingereichten Artefakts beschreiben.
Copy-Freigabe:
- Nutzen vor Feature-Liste
- Voraussetzungen und Einschränkungen nennen
- Absolute Privacy- und Offline-Claims belegen
- Premium-Funktionen klar markieren
- Keine zukünftigen Features versprechen
- Copy gegen Release-Build testen
5. Support-, Marketing- und Privacy-URLs als Produktteile behandeln
Die Datenschutz-URL ist für iOS-Apps erforderlich und muss eine aktive, öffentlich erreichbare Erklärung öffnen. Auch die Support-URL soll nicht auf eine leere Startseite führen, sondern Nutzern echten Kontakt oder Hilfe bieten. Teste alle Links ohne Login, in einem privaten Browserfenster, auf Mobilgeräten und aus einem externen Netz. Weiterleitungsschleifen, Cookie-Walls oder Geoblocking können Testzugang für das Prüfteam verhindern.
Die verlinkten Seiten müssen App-Name, verantwortliche Stelle und reale Datenpraxis widerspiegeln. Aktualisiere sie gemeinsam mit Store-Angaben, wenn neue SDKs, Kontotypen oder Löschprozesse hinzukommen. Lege fest, wer Erreichbarkeit überwacht und wie schnell defekte Links korrigiert werden. Ein funktionierender Link beim Copy-Paste reicht nicht als Dokumentation zur Veröffentlichung.
URL-Preflight:
- HTTPS ohne Zertifikatsfehler
- Ohne Login und interne VPN erreichbar
- App und Anbieter eindeutig genannt
- Supportkontakt tatsächlich überwacht
- Privacy-Inhalt zur aktuellen Datenpraxis
- Redirects, Locale und Mobilansicht getestet
6. Altersfreigabe, Content Rights und regionale Angaben korrekt beantworten
Die Altersfreigabe gilt appweit und soll den tatsächlich zugänglichen Inhalt abbilden: Nutzerbeiträge, WebViews, Werbung, medizinische Themen, Gewalt, Glücksspielbezug oder uneingeschränkten Webzugriff. Bewerte nicht nur eigene Demo-Daten. Dynamische Inhalte und Community-Funktionen können die Einstufung bestimmen, auch wenn der erste Screen harmlos wirkt.
Bestätige außerdem Rechte an Drittinhalten, Marken, Musik, Bildern und Feeds. Regionale Verfügbarkeit kann zusätzliche Angaben verlangen. Dokumentiere, welche Produktentscheidung hinter jeder Antwort steht, und prüfe Änderungen an Moderation, Zielgruppe oder Content-Quellen erneut. Ein einmal ausgefülltes Formular bleibt nicht automatisch für kommende Releases korrekt.
Angaben zu Store-Regeln prüfen:
- UGC und Moderation berücksichtigt
- WebViews und externe Inhalte erfasst
- Werbung und regulierte Themen bewertet
- Rechte und Lizenzen dokumentiert
- Kinder-/Zielgruppenentscheidung konsistent
- Regionale Pflichten vor Verfügbarkeit geprüft
7. Versionsfelder und What's New konkret halten
Versionsnummer, Copyright, Release-Einstellungen, Screenshots, Beschreibung und What's New gehören zum Release-Prozess. Für Updates sollte What's New konkrete sichtbare Änderungen nennen statt nur Fehlerbehebungen und Verbesserungen zu wiederholen. Vermeide Details, die nicht in allen lokalisierten Builds verfügbar sind, und trenne serverseitige Experimente von garantiert ausgelieferter Funktionalität.
Review-Informationen sind nicht öffentlich, aber entscheidend für den Prüfpfad. Hinterlege ein dauerhaftes Testkonto, funktionierende Kontaktangaben und knappe Hinweise zu nicht offensichtlichen Funktionen. Wenn ein Feature nur in einer Region, für eine Rolle oder hinter einer Subscription erscheint, muss genau diese Bedingung reproduzierbar beschrieben sein.
Versions-Handoff:
- Marketingversion und Build eindeutig
- What's New mit sichtbaren Änderungen
- Release-Modus bewusst ausgewählt
- Review-Kontakt erreichbar
- Testkonto unmittelbar vor Submit geprüft
- Regionen, Rollen und Feature Flags erklärt
8. Eine zweite Person führt den abschließende Prüfung der Store-Angaben aus
Die wirksamste Abschlusskontrolle ist ein unabhängiger Durchlauf. Eine Person, die den Release nicht geschrieben hat, öffnet jede Lokalisierung, folgt Support- und Privacy-Links, vergleicht Screenshots und Beschreibung mit dem Build und prüft Hinweise für das Prüfteam auf einem frischen Gerät. So werden blinde Flecken sichtbar, die reine Zeichenlimit-Validatoren nicht finden.
Speichere anschließend einen Snapshot der eingereichten Metadaten mit Version, Build, Datum und Verantwortlichen. Bei einer Ablehnung lässt sich dadurch unterscheiden, welche Aussage Apple tatsächlich gesehen hat. LaunchLint kann Hinweise in den Projektdateien und bekannte Metadatenlücken verbinden, aber es kann ohne Store-Zugriff nicht behaupten, den finalen App-Store-Connect-Zustand geprüft zu haben.
Abschluss-Nachweis:
- Alle Sprachen vollständig geöffnet
- Links extern getestet
- Build und Claims verglichen
- Screenshots in richtiger Reihenfolge
- Testzugang für das Prüfteam unabhängig geprüft
- Snapshot mit Freigabe archiviert
Häufige Fragen
Wie lang dürfen App-Name und Untertitel sein?
Apple nennt aktuell maximal 30 Zeichen für den Namen und 30 Zeichen für den Untertitel. Prüfe die aktuelle Referenz vor jeder Einreichung, weil Limits und Felder geändert werden können.
Kann ich Screenshots und Beschreibung nach der Freigabe ändern?
Die Editierbarkeit hängt vom Feld und App-Status ab. Für Screenshots einer freigegebenen Version ist typischerweise eine neue Version erforderlich; einige andere Metadaten lassen sich flexibler ändern.
Soll ich dieselben Keywords in jede Sprache übersetzen?
Nein. Recherchiere die tatsächliche Suchsprache des Zielmarkts. Direkte Übersetzungen verschwenden Zeichen und treffen oft eine andere Suchintention.
Kann LaunchLint die Store-Metadaten vollständig verifizieren?
Nur wenn die relevanten Werte als Input oder Integration verfügbar sind. Der Prüfung der Projektdateien kann technische Nachweis liefern, ersetzt aber keinen abschließenden Blick in App Store Connect.