Mobile-App-Audit: Checkliste vor Redesign, Übernahme oder Neubau

Die Entscheidungsfrage kommt vor dem Quellcode

Formulieren Sie zuerst, was nach dem Audit entschieden werden soll. Hält die Plattform die geplante Expansion aus? Warum brechen Nutzer im Buchungsprozess ab? Kann ein neues Team übernehmen? Ist eine Reparatur wirtschaftlicher als ein Neubau? Legen Sie außerdem den Zeitraum fest. Eine Rettungsversion für die kommenden sechs Wochen verlangt andere Tiefe als eine Übernahmeprüfung für mehrere Jahre.

Zum Umfang gehören konkrete Apps, Betriebssysteme, Märkte, Rollen, Backend-Dienste, Schnittstellen und Versionen. Ohne diese Grenze wächst die Prüfung beliebig. Mit ihr lässt sich jeder Arbeitsschritt auf eine Entscheidung zurückführen.

Belege, Zugänge und Eigentum erfassen

Beginnen Sie mit Produktzielen, Umsatzlogik, Nutzerwegen, Store-Bewertungen, Supportfällen, Kündigungsgründen, Analytics, Absturzberichten, Release Notes und Designs. Danach folgen Repositories, API-Beschreibungen, Testumgebung und Drittanbieter.

Ein Zugangsregister zeigt, wem Apple- und Google-Konten, Cloud, Domains, Quellcode, Analytics, Push-Dienst, Zahlungsanbieter und Signaturschlüssel gehören. Ein fehlender Zugang kann eine Veröffentlichung blockieren und ist daher ein Produktrisiko. Welche Unterlagen ein übernehmendes Team benötigt, beschreibt unser Leitfaden zur App-Dokumentation und Übergabe.

Kritische Abläufe wirklich durchspielen

Lassen Sie den Produktverantwortlichen in einem Satz erklären, wer die wichtigste Zielgruppe ist und welches Ergebnis sie in der ersten Sitzung erreicht. Prüfen Sie diese Aussage anhand echter Abläufe. Bei einem Marktplatz kann die Händlerabwicklung entscheidender sein als das Käufer-Onboarding. Bei einer Lern-App ist möglicherweise nicht der Katalog, sondern die fehlerhafte Fortschrittsspeicherung das Problem.

Ordnen Sie Supportfälle, Interviews und Bewertungen nach Ablauf und Folge. Häufigkeit allein bestimmt nicht die Priorität. Zwei verlorene Zahlungen wiegen schwerer als viele Wünsche nach einer anderen Farbe. Fehlende Belege werden als Unsicherheit dokumentiert und nicht durch Vermutungen ersetzt.

Wählen Sie fünf bis acht Kernaufgaben. Testen Sie Neuinstallation, Rückkehr, schwaches Netz, verweigerte Berechtigungen, abgelaufene Anmeldung, unterbrochene Zahlung und Wiederaufnahme nach einem Fehler auf realen Geräten. Pro Test gehören Ausgangslage, Handlung, Erwartung, tatsächliches Ergebnis und ein Beleg ins Protokoll.

Analytics vor der Trichteranalyse prüfen

Ein zu früh ausgelöstes Kaufereignis kann einen fehlgeschlagenen Bezahlvorgang als Umsatz melden. Ein doppeltes Ereignis lässt die Conversion besser aussehen, als sie ist. Vergleichen Sie das Ereignisverzeichnis mit der Implementierung und führen Sie ein bekanntes Testkonto durch Anmeldung, Buchung oder Kauf. Namen, Zeitpunkt und Parameter müssen stimmen; abgeschlossene Vorgänge werden mit Backend oder Zahlungsanbieter abgeglichen.

Entwicklungs- und Produktionsdaten sollten getrennt, App-Versionen erkennbar und Begriffe auf iOS und Android identisch sein. Wenn die Messung unzuverlässig ist, sind Aussagen zum Trichter vorläufig. Die Einrichtung von Analytics in einer Mobile App erläutert eine brauchbare Ausgangsbasis.

Stabilität und Geschwindigkeit im Zusammenhang bewerten

Eine Gesamtzahl der Abstürze reicht nicht. Segmentieren Sie nach Version, Betriebssystem, Gerät, Markt und Nutzerweg. Android Vitals berichtet nutzerwahrgenommene Abstürze und ANR; die Dokumentation zu Android Vitals beschreibt Kernmetriken und Auffälligkeiten einzelner Gerätemodelle. Für Apple-Produkte liefert App Store Connect App Analytics Signale zu Akquise, Nutzung und Leistung.

Messen Sie Start, Anmeldung, Suche, Bezahlung, Upload und Synchronisierung bei gutem und schlechtem Netz. Der Mittelwert kann eine wertvolle Nutzergruppe verbergen, die regelmäßig zehn Sekunden wartet. Bei Crash-Werkzeugen ist auch die Abdeckung wichtig. Firebase erklärt in der Crashlytics-Metrikbeschreibung, warum absturzfreie Nutzer und Sitzungen verschiedene Fragen beantworten.

Barrierefreiheit gehört in dieselben Abläufe. Prüfen Sie Textvergrößerung, Kontrast, Fokusreihenfolge, Screenreader-Beschriftung, Zielgrößen, Bewegung und Fehlermeldungen. Automatische Prüfungen helfen, ersetzen aber keine Tests mit Bedienungshilfen. Accessible.org beschreibt den Umfang eines nativen mobilen Audits.

Code, Backend und Daten gemeinsam untersuchen

Bei der technischen Prüfung zählt Änderungsrisiko, nicht die Beliebtheit eines Frameworks. Untersucht werden Modulgrenzen, doppelte Geschäftsregeln, veraltete Abhängigkeiten, Tests, Fehlerbehandlung, Geheimnisse, Konfiguration und reproduzierbare Builds. Wenn die App nur auf einem alten Entwicklerrechner gebaut werden kann, ist der Betrieb gefährdet.

Verfolgen Sie zwei wichtige Vorgänge von der Oberfläche über API und Datenbank bis zum Drittanbieter. Wo wird validiert? Wie funktionieren Wiederholungen und Mehrfachaufrufe? Welche Daten werden zwischengespeichert? Wie werden Schemaänderungen veröffentlicht und zurückgerollt? So wird sichtbar, ob etwa ein Verbindungsabbruch unbemerkt zwei Bestellungen erzeugt.

Zur Datenprüfung gehören Erhebung, Speicherort, Aufbewahrung, Export, Löschung und Migration. Bei Gesundheits-, Kinder-, Finanz- oder Standortdaten müssen geeignete Datenschutz- und Sicherheitsexperten beteiligt werden. Das allgemeine Audit benennt diesen Bedarf, ersetzt aber keine Fachprüfung.

Release-Prozess und Rechte praktisch nachweisen

Bitten Sie das Team, eine signierte Version zu erzeugen, Tests auszuführen, Backend-Änderungen auszurollen und einen Rückweg zu erklären. Vergleichen Sie die Demonstration mit der Dokumentation. Prüfen Sie Umgebungen, Automatisierung, Feature-Schalter, Geheimniswechsel, Alarme und Zuständigkeiten bei Störungen.

Code, Designs, Schriften, Medien und kostenpflichtige Bibliotheken brauchen geklärte Nutzungsrechte. Hauptkonten gehören dem Unternehmen; Personen erhalten rollenbezogene Zugänge. Ein gemeinsam genutztes privates Passwort ist keine belastbare Übergabe.

Von Befunden zu fünf klaren Maßnahmen

Bewerten Sie Auswirkung und Beweissicherheit getrennt. Ein möglicher, aber noch nicht reproduzierter Zahlungsfehler verdient schnelle Untersuchung. Er rechtfertigt noch keine voreilige Neubauentscheidung.

Die Empfehlungen werden pro Baustein formuliert:

• Beibehalten: funktioniert, ist im Besitz des Unternehmens und trägt die Roadmap.
• Reparieren: ein klar begrenzter Fehler lässt sich direkt beheben.
• Refaktorieren: das Verhalten bleibt, die innere Struktur muss für sichere Änderungen verbessert werden.
• Neu gestalten: Technik funktioniert, doch der Ablauf scheitert für Nutzer.
• Ersetzen: eine schrittweise Änderung kostet mehr oder lässt wesentliche Risiken bestehen.

Für einen Neubau braucht es nachvollziehbare Gründe, etwa nicht mehr unterstützte Technik, unsichere Datenverarbeitung, nicht reproduzierbare Releases oder strukturell hohe Änderungskosten. Alter Code allein ist kein Grund. Hilfreich sind außerdem unser Vergleich von Redesign und Modernisierung sowie die Einordnung der Kosten eines App-Redesigns.

So sieht ein handlungsfähiger Bericht aus

Der Abschluss enthält Umfang, Belegverzeichnis, Architektur, getestete Abläufe, Vertrauen in die Messung, Stabilitätsbasis, Eigentumslücken, priorisierte Befunde und einen Plan in Etappen. Zu jedem wesentlichen Punkt gehören Folge, Beleg, Empfehlung, Abhängigkeit, verantwortliche Rolle und grobe Größenordnung.

Trennen Sie die Stabilisierung der nächsten 30 Tage von der mittelfristigen Entwicklung. Dadurch verschwinden dringende Zugangs-, Absturz- oder Zahlungsprobleme nicht in einem großen Designprojekt. Gleichzeitig wird eine Kostenschätzung genauer, weil belegte Arbeit statt pauschaler Unsicherheit kalkuliert wird.

Appfyl nutzt das Audit, um brauchbare Bestandteile zu erhalten. Manchmal genügt ein gezieltes Reparatur-Release, manchmal bleiben Oberfläche und Datenmodell bestehen, während der Backend-Prozess erneuert wird. Ein kompletter Neubau ist nur sinnvoll, wenn die Befunde zeigen, dass schrittweise Änderungen teurer oder dauerhaft riskant wären. Im Appfyl-Projektbrief können Sie Ausgangslage und benötigte Funktionen beschreiben.

Häufige Fragen