Kostenloser Konfigurations-Check

Kostenloser Expo App Store Checker

Prüfe app.json und package.json auf einige häufige App-Store-Risikosignale. Lokal im Browser, ohne Login und ohne Code-Ausführung.

Deine eingefügten Dateien bleiben im Browser und werden nicht gespeichert.Dieser Schnelltest sieht nur zwei Konfigurationsdateien. Er erzeugt keinen Bereitschaftswert und ersetzt keine vollständige App-Prüfung.

app.json einfügen

package.json (optional)

Lokal im Browser · keine Speicherung

Kostenloser Schnelltest

Was erkennt der kostenlose Expo-Check?

Der Expo-Check liest eingefügte `app.json`- und `package.json`-Inhalte lokal im Browser und zeigt höchstens drei auffällige Signale zu Berechtigungen, Authentifizierung, Käufen oder Tracking. Er führt keinen Code aus und behauptet nicht, das vollständige native Release-Artefakt zu kennen.

Warum zwei Dateien bereits nützlich sind

In `app.json` beziehungsweise der aufgelösten Expo-Konfiguration stehen App-Identität, Plugins, iOS-Nutzungsbeschreibungen und Android-Berechtigungen. `package.json` zeigt direkte Abhängigkeiten, die zusätzliche Datenflüsse oder Store-Pflichten auslösen können. Zusammen liefern beide Dateien einen schnellen ersten Blick auf typische Einreichungsrisiken.

Ein erkannter Auth-, Purchase- oder Analytics-Baustein ist noch kein Fehler. Er ist ein Anlass zu prüfen, ob Login-Alternativen, Kontolöschung, In-App-Käufe, App Privacy und Google Play Data Safety zum tatsächlichen Produkt passen.

So bereitest du die Eingabe vor

Verwende die Konfiguration des geplanten Produktions-Releases, nicht ein altes Beispielprojekt. Entferne Geheimnisse, private Endpunkte und personenbezogene Testdaten. Wenn `app.config.ts` Werte dynamisch erzeugt, exportiere eine redigierte, aufgelöste Konfiguration oder nutze später den vollständigen Repo-Check.

Achte auf Build-Varianten. Development, Preview und Production können verschiedene Bundle IDs, Package Names, Plugins und Berechtigungen enthalten. Ein sauberer Entwicklungsstand beweist deshalb nicht, dass der signierte Store-Build dieselben Werte erhält.

Was ein Signal bedeutet

Der Schnelltest zeigt bewusst nur wenige priorisierte Hinweise. Eine Kameraberechtigung ohne konkrete Nutzungsbeschreibung ist direkter als ein SDK, das je nach Einrichtung Daten übertragen kann. LaunchLint trennt deshalb erkannte Konfiguration von Fragen, die nur durch Store-Konsole, Backend oder Gerätetest beantwortet werden können.

Prüfe jeden Hinweis an der Quelldatei und an der aufgelösten nativen Konfiguration. Plugins können Werte ergänzen oder überschreiben. Bei Bare- oder Prebuild-Projekten gehören auch `Info.plist`, Entitlements, AndroidManifest und Network Security Config in die technische Prüfung.

Warum der Full Repo Scanner mehr sieht

Der vollständige statische Check berücksichtigt unterstützte Projektdateien, Manifeste, Quellcode-Signale, Store-Angaben und direkte Abhängigkeiten gemeinsam. Dadurch kann er Widersprüche erkennen, betroffene Dateien benennen und konkrete Aufgaben für Codex, Cursor oder Claude Code erzeugen.

Die kostenlose Vorschau soll einen echten Aha-Moment liefern, aber keine bezahlte Prüfung ersetzen. Readiness Score, vollständige Evidence, alle Findings, Re-Scans und Launch Pack bleiben deshalb dem vollständigen Projektcheck vorbehalten.

Beispiel für ein Expo-Signal

Eingabe: `expo-camera` ist installiert, aber `NSCameraUsageDescription` fehlt oder enthält nur einen generischen Platzhalter.
Ergebnis: Der Check weist auf die fehlende oder unklare Begründung hin. Ob die Kamera wirklich im Release verwendet wird und wie der Text im nativen Build ankommt, muss anschließend im vollständigen Projekt und auf einem Gerät geprüft werden.