Mit React Native und Expo Apps im App Store und bei Google Play veröffentlichen

Der schwierige Teil der mobilen App-Entwicklung ist nicht, wie oft angenommen, der Code. Aus einer einzigen Codebasis zwei Plattformen zu bedienen, ist mit React Native und Expo heute ziemlich unkompliziert. Die eigentliche Überraschung sind die Stores: Konten, Datenschutzformulare, Testanforderungen und Ablehnungsgründe.

Dieser Beitrag behandelt genau diesen Teil – was du brauchst, damit deine App nach dem Programmieren wirklich veröffentlicht wird.

Zuerst die Kosten

Der Unterschied ist wichtig: Bei Apple ist es ein Abonnement. Du kannst eine App nicht veröffentlichen und vergessen, sondern musst jedes Jahr verlängern.

Googles Regel mit den 12 Testern

Das bringt den Zeitplan derer, die nicht darauf vorbereitet sind, am meisten durcheinander, und in türkischsprachigen Quellen kommt es kaum vor.

Die Details haben es in sich:

• Die 14 Tage müssen ununterbrochen sein. Steigt ein Tester ein und wieder aus, zählt er nicht; steigt er erneut ein, beginnt der Zähler von vorn.
• 12 Tester müssen gleichzeitig angemeldet sein. Es reicht nicht, dass zu verschiedenen Zeitpunkten insgesamt 12 Personen getestet haben.
• Diese Zeit kommt zusätzlich zur Entwicklungszeit dazu. Wenn die App fertig ist, vergehen also mindestens zwei weitere Wochen.

Apples Datenschutzerklärung

Seit dem 1. Mai 2024 müssen alle neuen Apps und Updates, die im App Store eingereicht werden, für Drittanbieter-SDKs, die „Required Reason APIs“ nutzen, eine Datenschutzerklärung (PrivacyInfo.xcprivacy) enthalten. Das ist eine Plist-Datei, in der deklariert wird, welche Datenarten die App erhebt und aus welchem Grund sie bestimmte APIs verwendet.

Apps mit fehlender Erklärung werden im Review abgelehnt.

Auf der Expo-Seite ist das gut handhabbar: Die meisten Bibliotheken bringen ihre eigene Erklärung mit, und was du selbst ergänzen musst, definierst du in der Konfiguration. Aber an dem Tag, an dem du sagst „Der Code ist fertig, schicken wir ihn los“, kann das das Erste sein, worüber du stolperst.

Formulare: deklarieren, was du erhebst

Beide Stores verlangen eine Erklärung zur Datenerhebung:

• Apple – App Privacy: Welche Daten erhebst du, wofür nutzt du sie, werden sie mit dem Nutzer verknüpft? Die „Datenschutz-Labels“ auf der Store-Seite werden daraus erzeugt.
• Google – Data Safety: Das Pendant bei Google mit denselben Fragen, dazu die Angabe, ob die Daten verschlüsselt werden und ob Nutzer eine Löschung beantragen können.

Die Angaben müssen mit dem tatsächlichen Verhalten der App übereinstimmen. Wird eine Abweichung festgestellt, kann die App entfernt werden.

Die Datenschutzerklärung muss eine URL sein

Beide Stores verlangen, dass die Datenschutzerklärung unter einer erreichbaren Adresse veröffentlicht ist. Ein Text innerhalb der App reicht nicht; im Eintrag musst du einen Link angeben.

Hat die App keine eigene Website, ist der praktischste Weg, auf einer bestehenden Website eine Unterseite anzulegen. Auf dieser Website liegt sie unter /privacy-policy/breakchain – auf diese Adresse zeigt der Store-Eintrag.

Build und Upload mit EAS

Wenn du Expo nutzt, brauchst du für den Build keinen lokalen Mac; EAS Build verwaltet auch die Signaturzertifikate.

# Kurulum
npm install -g eas-cli
eas login
eas build:configure
 
# Mağaza için derleme
eas build --platform ios
eas build --platform android
 
# Mağazaya gönderme
eas submit --platform ios
eas submit --platform android

Die Verwaltung von Zertifikaten und Profilen ist hier die größte Erleichterung: Das iOS-Signing war traditionell der nervigste Teil des Prozesses, und EAS nimmt es dir ab.

Store-Eintrag

Das musst du vorbereiten, nachdem der Code fertig ist:

• App-Icon – die Ecken rundest nicht du ab, der Store wendet seine eigene Maske an. Reiche es quadratisch und vollflächig ein.
• Screenshots – in bestimmten Gerätegrößen und in bestimmter Anzahl. Das ist die Arbeit, die die meisten auf den letzten Tag verschieben und die am meisten Zeit kostet.
• Beschreibungstext – wird auch für die Suche im Store verwendet.
• Kategorie, Altersfreigabe, Kontaktdaten.
• Testkonto – wenn die App einen Login hat, musst du dem Reviewer ein funktionierendes Konto zur Verfügung stellen. Tust du das nicht, wird die App abgelehnt.

Häufige Ablehnungsgründe

Die Veröffentlichung ist nicht das Ende

Auch nach dem Livegang braucht die App Pflege: Plattformversionen ändern sich, Apple und Google führen von Zeit zu Zeit neue Deklarationspflichten ein, Bibliotheken veralten. „Einmal schreiben und vergessen“ gilt bei einer mobilen App weniger als im Web – denn die beiden Plattformen darunter folgen jeweils ihrem eigenen Zeitplan.

Deshalb spreche ich bei Mobile-Projekten das Thema Versions-Updates von Anfang an an: Wer aktualisiert die App, und wie oft?