Keine Code-Ausführung
Wir installieren keine Pakete, bauen keine App und starten keine Skripte aus deinen Projektdateien.
So prüft LaunchLint
LaunchLint Methodik
LaunchLint verbindet eindeutig erkennbare Signale in deinen Projektdateien mit geprüften Store-Regeln. Ein Signal wird nie automatisch zu einer Freigabegarantie.
Zuletzt fachlich geprüft: 19. Juli 2026
Nachweis vor Schlussfolgerung
Jedes erkannte Risiko braucht ein konkretes Signal in einer Datei, Konfiguration oder Store-Angabe sowie eine nachvollziehbare Einschätzung der Erkennungssicherheit.
Offizielle Quellen
Verweise auf Store-Regeln führen zur Dokumentation von Apple, Google oder Expo und werden bei Änderungen geprüft.
Klare Prüfgrenzen
Nutzerfreundlichkeit, echtes Verhalten der laufenden App und die fertige Installationsdatei können eine menschliche oder zusätzliche technische Prüfung erfordern.
Von der Datei zum Finding
Der Scanner erkennt zuerst Framework, Plattformen und relevante Konfigurationsquellen. Regeln arbeiten anschließend auf normalisierten Fakten, etwa einer Android-Berechtigung, einem iOS Purpose String, einer Abhängigkeit oder einer Store-Aussage. Ein Finding entsteht nur, wenn eine definierte Regel auf diese Nachweise passt.
Jeder Treffer soll die betroffene Datei, den erkannten Wert, die fachliche Begründung und eine priorisierte nächste Handlung enthalten. Nicht auflösbare Variablen oder generierte native Werte werden als Unsicherheit markiert und nicht als bewiesener Fehler dargestellt.
Schweregrad, Konfidenz und Release-Entscheidung
Schweregrad beschreibt die mögliche Auswirkung auf Review, Sicherheit oder Veröffentlichung. Konfidenz beschreibt, wie eindeutig die vorhandenen Dateien den Sachverhalt belegen. Ein hochkritisches Signal mit niedriger Konfidenz braucht deshalb zuerst Verifikation; ein eindeutig fehlendes Pflichtfeld kann dagegen direkt bearbeitet werden.
LaunchLint erteilt keine Store-Freigabe. Das Ergebnis ist eine priorisierte Risikoliste. Der Release-Verantwortliche verbindet sie mit Gerätetests, Backend-Zustand, Store-Konsole und dem signierten Produktionsartefakt.
Regelquellen und Aktualisierung
Store-Regeln werden bevorzugt aus offizieller Apple-, Google-, Expo-, Flutter- und Capacitor-Dokumentation abgeleitet. Quellen, Prüfdatum und betroffene Regelbereiche werden redaktionell gepflegt. Eine Policy-Änderung führt nicht automatisch zu einer pauschalen Behauptung für jedes Projekt.
Korrekturen und wesentliche Aktualisierungen erhalten ein neues fachliches Prüfdatum. Der redaktionelle Prozess ist auf der Seite zur Editorial Policy dokumentiert.
Bewusste Grenzen der statischen Analyse
LaunchLint installiert keine Dependencies, startet keinen Build und führt keinen Nutzer-Code aus. Dadurch bleibt die Prüfung sicher und reproduzierbar, kann aber dynamisch erzeugte Konfiguration, Serververhalten, Laufzeitberechtigungen, echte Käufe oder den Zustand eines Store-Kontos nicht vollständig beweisen.
Diese Grenze wird nicht durch frei erfundene KI-Einschätzungen verdeckt. KI darf strukturierte, maskierte Scanner- und Policy-Daten erklären oder in Aufgaben übersetzen. Sie erzeugt keine Findings ohne zugrunde liegenden Nachweis.
Unterstützte App-Technologien
Was LaunchLint vollständig prüfen kann
Vollständig bedeutet: Projektstruktur, ausgelieferte Abhängigkeiten, Berechtigungen, Store-Konfiguration und statisch belegbare Sicherheitsmuster werden gemeinsam geprüft.
ExpoVollständige statische Prüfung
VollständigReact NativeVollständige statische Prüfung
VollständigIonic / CapacitorVollständige statische Prüfung
VollständigFlutter / FlutterFlowVollständige statische Prüfung
VollständigNative iOS / AndroidStore- und Plattformkonfiguration
KonfigurationKMP, .NET MAUI, Unity, UnrealKeine verlässliche Quellcodeprüfung
Noch nichtOffizielle Regelquellen
LaunchLint Academy