Crash-Reporting & App-Monitoring

TL;DR: Anders als bei einer Website merken Sie einen Absturz in Ihrer App nicht selbst, er passiert auf fremden Geräten, weit weg von Ihnen. Ohne Crash-Reporting erfahren Sie davon zuletzt, nämlich aus einer Ein-Stern-Bewertung. Werkzeuge wie Sentry oder Firebase Crashlytics melden jeden Absturz automatisch, mit Stacktrace, Gerät und Version, sodass Sie das Problem sehen und beheben können, bevor es viele Nutzer trifft. Crash-Reporting ist keine Kür, sondern die Grundausstattung jeder App, die im Store steht.

---

Für Entscheider: Worum es geht

Eine App lebt auf Geräten, die Ihnen nicht gehören: verschiedene Hersteller, Betriebssystem-Versionen, Speicherstände, Netzqualitäten. Was im Test auf zwei Geräten lief, kann auf dem dritten abstürzen. Das ist normal und kein Zeichen schlechter Arbeit. Entscheidend ist nur eines: Erfahren Sie davon, oder nicht?

Ohne Monitoring sieht die Kette so aus: Die App stürzt beim Nutzer ab, der Nutzer ärgert sich, der Nutzer schreibt eine schlechte Bewertung oder, schlimmer, löscht die App wortlos. Sie merken es Wochen später an sinkenden Zahlen und raten, woran es liegt. Mit Crash-Reporting bekommen Sie stattdessen Minuten nach dem ersten Absturz eine Meldung, die genau sagt, was passiert ist.

Warum Apps anders sind als Webseiten

Bei einer Webanwendung läuft der Code auf Ihrem Server. Geht etwas schief, steht es in Ihrem Logfile, in Ihrer Reichweite. Bei einer mobilen App ist das fundamental anders: Der Code läuft auf dem Telefon des Nutzers. Wenn er dort abstürzt, bleibt die Information zunächst genau dort, unsichtbar für Sie.

Dazu kommt die enorme Vielfalt. Eine App muss über hunderte Gerätemodelle, mehrere OS-Versionen und unterschiedlichste Bedingungen hinweg funktionieren. Ein Fehler tritt vielleicht nur auf einem bestimmten Android-Hersteller bei wenig Speicher auf. So etwas finden Sie im eigenen Test fast nie, im echten Einsatz dafür sofort. Genau diese Lücke schließt Crash-Reporting: Es holt die Fehlerinformation vom fremden Gerät zu Ihnen.

Crash-Reporting: Was es genau tut

Ein Crash-Reporting-SDK wird einmal in die App eingebaut und läuft dann unsichtbar mit. Stürzt die App ab, passiert automatisch Folgendes: Im Moment des Absturzes wird ein Bericht erstellt, beim nächsten Start verschlüsselt an einen Dienst gesendet und dort ausgewertet. Sie sehen anschließend in einem Dashboard, was los ist. Ein guter Bericht enthält:

• Stacktrace: die genaue Code-Stelle und der Weg dorthin, also die Antwort auf „wo ist es passiert".
• Gerät und OS: Modell, Betriebssystem-Version, freier Speicher, Sprache. Oft liegt hier das Muster.
• App-Version: trat der Fehler erst nach dem letzten Update auf? Sehr häufig die entscheidende Frage.
• Breadcrumbs: die letzten Schritte des Nutzers vor dem Absturz, ohne sensible Inhalte, nur der Weg.
• Häufigkeit: einmal oder bei tausend Nutzern? Das entscheidet, wie dringend Sie reagieren müssen.

Der große Gewinn ist die Gruppierung. Stürzen tausend Nutzer am selben Punkt ab, bekommen Sie nicht tausend Meldungen, sondern eine einzige mit der Zahl dahinter. So sehen Sie sofort, welcher Fehler wirklich wehtut und welcher ein Einzelfall ist.

Die Werkzeuge: Crashlytics, Sentry & Co.

Sie müssen nichts selbst bauen, der Markt ist ausgereift. Die gängigen Optionen:

In der Cross-Platform-Welt mit Flutter oder React Native binden sich diese Dienste sauber ein und fangen Abstürze sowohl im Dart- beziehungsweise JavaScript-Teil als auch im nativen Unterbau ab. Mein bevorzugter Weg ist oft Sentry, weil es Abstürze, normale Fehler und die Performance in einer Oberfläche bündelt und sich bei Bedarf auf eigenem Server betreiben lässt, sodass die Daten das Haus nicht verlassen. Crashlytics ist die naheliegende Wahl, wenn das Projekt ohnehin auf Firebase aufsetzt.

Mehr als Abstürze: App-Monitoring

Ein harter Absturz ist der offensichtliche Fall. Aber eine App kann auf viele Arten schlecht sein, ohne abzustürzen, und auch das lässt sich messen. Vier Kennzahlen lohnen den Blick:

• Absturzfreie Nutzer: der Anteil der Nutzer, die die App ohne einen einzigen Absturz verwenden. Das ist die wichtigste Stabilitätszahl überhaupt. Werte deutlich über 99 Prozent sind das Ziel.
• Startzeit: Wie lange dauert es vom Tippen aufs Icon bis zur nutzbaren App? Jede zusätzliche Sekunde kostet Nutzer, die genervt wieder abspringen.
• Hänger (ANR / Freezes): Die App stürzt nicht ab, friert aber kurz ein. Für den Nutzer fühlt sich das oft schlimmer an als ein klarer Absturz.
• Fehler ohne Absturz: Ein Bild lädt nicht, ein Kauf schlägt fehl, ein Speichern geht verloren. Solche stillen Fehler verärgern Nutzer und bleiben ohne Monitoring komplett unsichtbar.

Diese Werte machen den Unterschied zwischen „die App stürzt nicht ab" und „die App fühlt sich gut an". Beides zusammen ergibt eine App, die im Store gute Bewertungen bekommt, statt sie zu verlieren.

Wenn die App mit Ihnen spricht: Alerts

Ein Dashboard ist nur so gut wie die Häufigkeit, mit der jemand hineinschaut. Der eigentliche Hebel ist deshalb derselbe wie beim Server-Betrieb: Die App soll sich bei Ihnen melden, wenn etwas Ernstes passiert, statt darauf zu warten, dass Sie nachsehen.

In der Praxis richte ich das so ein, dass ein neuer, gehäuft auftretender Absturz oder ein plötzlicher Einbruch der Stabilität automatisch eine Meldung auslöst, idealerweise dorthin, wo Sie ohnehin hinschauen: in einen Chat-Kanal wie Mattermost oder per XMPP aufs Handy. Besonders wertvoll ist die Meldung „neuer Absturz seit der letzten Veröffentlichung". So erkennen Sie ein fehlerhaftes Update innerhalb von Stunden statt erst, wenn die schlechten Bewertungen eintrudeln.

Datenschutz: Was im Crash-Bericht stehen darf

Ein Crash-Bericht enthält technische Daten und manchmal mehr, als nötig ist. Hier gelten dieselben Grundsätze wie überall: nur erheben, was wirklich gebraucht wird. Konkret bedeutet das, Stacktrace, Gerät und App-Version sind in Ordnung, personenbezogene Inhalte wie Namen, E-Mail-Adressen oder Eingaben gehören dagegen nicht in den Bericht. Die eigentliche Falle ist dabei selten das Feld, das man absichtlich loggt, sondern was unbemerkt mitfließt: Ein Stacktrace zitiert einen Variablenwert, der zufällig eine E-Mail-Adresse enthält, ein Breadcrumb hält die aufgerufene Adresse /profil/max.mueller@firma.de fest, eine Exception-Message gibt die fehlgeschlagene Eingabe wörtlich wieder. Es ist dieselbe nicht-offensichtliche Leckage, die ich im Beitrag zum Server-Logging beschrieben habe, nur diesmal auf dem Gerät des Nutzers. Gute SDKs bieten dafür Scrubbing- und Filter-Regeln, mit denen sich solche Daten herausfiltern lassen, bevor der Bericht das Gerät verlässt, aber diese Regeln muss man aktiv setzen, von allein passiert das nicht. Wenn die Daten in der EU oder auf eigenem Server liegen, ist die DSGVO-Seite zusätzlich entspannter, ein weiterer Grund, warum die selbst hostbare Variante attraktiv ist. Und natürlich gehört der Hinweis auf das Crash-Reporting in die Datenschutzerklärung.

Wie ich das in Projekten umsetze

1. Von Anfang an einbauen: Crash-Reporting kommt in die App, bevor sie in den Store geht, nicht als Nachrüstung nach dem ersten Ärger.
2. Sinnvoll konfigurieren: personenbezogene Daten aussparen, Breadcrumbs aktivieren, Release-Versionen sauber kennzeichnen, damit Fehler eindeutig einer Version zuzuordnen sind.
3. Wenige, gezielte Alerts: nicht jeder Einzelfall, sondern neue oder stark gehäufte Abstürze und Einbrüche der Stabilität, gemeldet in den Kanal, den Sie ohnehin nutzen.
4. Nach jedem Release hinschauen: die ersten Stunden nach einer Veröffentlichung sind die kritischsten. Ein neuer Absturz zeigt sich hier zuerst.

Ich arbeite zu Festpreisen: Nach einem kurzen Konzept-Gespräch wissen Sie, was Ihr Vorhaben kostet, bevor es losgeht. Crash-Reporting und ein sinnvolles Monitoring sind dabei für mich Teil einer ordentlich gebauten App, kein teures Extra.

Checkliste: Ist Ihre App im Betrieb sichtbar?

• ☐ Ist ein Crash-Reporting-SDK eingebaut (Sentry, Crashlytics o. ä.)?
• ☐ Sehen Sie die Quote der absturzfreien Nutzer pro Version?
• ☐ Werden Abstürze gruppiert und nach Häufigkeit sortiert?
• ☐ Bekommen Sie nach einem Release automatisch eine Meldung bei neuen Abstürzen?
• ☐ Ist sichergestellt, dass keine personenbezogenen Daten im Bericht landen?
• ☐ Steht das Crash-Reporting in der Datenschutzerklärung?
• ☐ Erfahren Sie von Problemen zuerst vom Monitoring, nicht aus den Bewertungen?

Fazit: Sehen, bevor die Bewertung sinkt

Bei einer App ist Crash-Reporting kein Luxus, sondern die einzige Möglichkeit, überhaupt zu erfahren, wie sich Ihre App auf fremden Geräten verhält. Die Alternative ist nicht „weniger Aufwand", sondern „blind fliegen" und am Ende aus den Sternebewertungen lernen, was schiefläuft.

Der Gewinn ist handfest: Sie beheben Fehler, bevor sie viele Nutzer treffen, halten Ihre Bewertung stabil und wissen nach jedem Update innerhalb von Stunden, ob alles gut ist. Eine App, die mit Ihnen spricht, ist eine App, der Sie vertrauen können, und der Ihre Nutzer vertrauen.