Sentry React Native: 2026 Integration Guide

Sie haben eine React Native-Anwendung, die lokal läuft, QA hat zugestimmt und die Produktion ist nahe. Dann landet die offensichtliche Frage: Was passiert, wenn sie auf einem Gerät des Benutzers zusammenbricht?

Ohne Sentry ist die Antwort normalerweise schlecht. Sie erhalten ein Support-Ticket, ein vages Screenshot, vielleicht ein Konsolen-Log aus einem Entwickler-Builder, das sich nicht mit der Produktion übereinstimmt. Mit Sentry React Native eingerichtet, erhalten Sie den Fehler, die Stack, die Release, die es verschickt hat, und genug Kontext, um es ohne Vermutungen zu beheben. Der Haken ist, dass Die grundlegende Installation ist das leichteste Teil.. Die schmerzhaften Teile kommen später: native Integration, Symbolisierung, Quellkarten, Versionsbezeichnungen und das Aufrechterhalten aller dieser Aspekte, wenn Ihr Liefermodell Live-Updates beinhaltet.

Die meisten Anleitungen enden zu früh. Eine echte Konfiguration muss CI, App Store Builds, Android-Veröffentlichungen und JavaScript-Bundles überstehen, die nicht immer aus dem Original-Code stammen.

Tabelle des Inhalts

• Zum Starten mit Sentry SDK
  • Was Sie vor der Installation benötigen
  • Das Wizard ausführen und das Ergebnis überprüfen
• Die Native iOS- und Android-Projekte konfigurieren
  • Was sich auf iOS geändert hat
  • Was sich auf Android geändert hat
  • Native-Einstellungen, die später Zeit sparen
• Automatisierung von Veröffentlichungen und Quellkarten
  • Why manuelle Uploads im Alltag scheitern
  • Eine Veröffentlichungsprozess, der tatsächlich funktioniert
  • Ein praktisches CI-Skriptmuster
• Leistungsmessungen und benutzerdefinierte Ereignisse erfassen
  • Stattdessen eine langsame Anzeige nachverfolgen
  • Fehler mit nützlichem Kontext hinzufügen
• Integrationsüberprüfung und Fehlerbehebung
  • Sicherheitstests auslösen
  • Was im Sentry-UI überprüfen
  • Common Sentry React Native Fehlerbehebung
• Integrieren mit Live-Update-Workflows wie Capgo
  • Release-Identifikatoren mit Live-Bundles abgleichen

Mit Capgo SDK loslegen

Die schnellste Möglichkeit, Sentry React Native in eine neue App zu integrieren, ist immer noch der Installations-Assistent. Er übernimmt den größten Teil der wiederholten Einstellungen und bringt Sie schnell zu einem funktionierenden Grundlayout. Das ist wichtig, weil die Handhabung der ersten Installation normalerweise zu kleinen Abweichungen führt, die Sie erst bei der ersten Produktionspanne bemerken.

Was Sie vor der Installation benötigen

Zuerst benötigen Sie ein normales React Native-Entwicklungsumfeld. Node, ein Paketmanager, Plattform-Tools für iOS und Android sowie Watchman auf macOS, wenn das bereits Teil Ihres Workflows ist. Sie benötigen auch ein Capgo-Konto und ein Projekt, das für React Native erstellt wurde.

Wenn Sie noch evaluiere, ob React Native die richtige Betriebswahl für Ihr Team ist, dann Ein Leitfaden für Unternehmen zu React Native bietet nützliche, nicht-marketingbezogene Kontextinformationen zu Plattform-Abwägungen, Personalplanung und Wartungserwartungen. Es lohnt sich, ihn vor der Verpflichtung Ihres Überwachungs- und Releaseprozesses zu einem gemeinsamen Codebase zu lesen.

Installieren Sie SDK mit dem Assistenten vom Projektroot:

npx @sentry/wizard@latest -i reactNative

Der Assistent fragt einige Dinge, die Entwickler oft zu schnell durchklicken:

• ProjektwahlWählen Sie das tatsächliche Capgo-Projekt, das Sie in der Produktion verwenden möchten, und nicht ein temporäres Sandbox, das Sie später vergessen werden.
• Nativänderungen. Sag ja. JavaScript-only-Fehlerfassung reicht für mobile Apps nicht aus.
• Optionale Funktionen. Schalten Sie ein, was Sie wissen, dass Sie verwenden werden, aber aktivieren Sie nicht alles blind auf den ersten Tag, wenn Ihr Team die resultierenden Daten nicht überprüfen wird.

Das Wizard ausführen und das Ergebnis überprüfen

Nachdem das Wizard abgeschlossen ist, überprüfen Sie die Änderungen anstatt ihnen ohne Überprüfung zu vertrauen. Sie sollten ein Sentry-Paket in package.json, native Änderungen unter ios , und eine Initialisierungsoption in Ihrem Anwendungsstartdatei sehen. androidEin typischer Initialisierungsaufruf sieht wie folgt aus:

Die

import * as Sentry from '@sentry/react-native';

Sentry.init({
  dsn: 'YOUR_DSN',
});

DSN sagt dem __CAPGO_KEEP_0__ , wohin Ereignisse gesendet werden sollen. Behandeln Sie es als Konfiguration, nicht als ein Geheimnis, das niemals sichtbar sein darf. Es ist nicht dasselbe wie ein Authentifizierungstoken. Halten Sie jedoch Ihre Umgebungsvariablen sauber und konsistent, damit Ihre App auf die richtige Sentry-Projekt in jeder Umgebung zeigt. tells the SDK where to send events. Treat it as configuration, not as a secret vault item that must never be visible. It isn’t the same as an auth token. Still, keep your environment setup clean and consistent so your app points to the right Sentry project in each environment.

A praktische Muster ist, die DSN aus der Umgebungs- spezifischen Konfiguration zu laden und Sentry vor dem Rest Ihres Anwendungsbaums zu initialisieren. Wenn Sie auch durch die Optimierung des Startvorgangs arbeiten, ist diese Anleitung zu React Native Splash Bildschirm einrichten wichtig, weil der Startvorgang code oft mit dem Platz, an dem Teams Sentry-Initialisierung einrichten, überschneidet.

Praktische Regel: Initialisieren Sie Sentry so früh wie möglich im Anwendungsstart. Wenn Sie bis zum Navigieren, Authentifizierung oder Remote-Konfiguration warten, werden Sie Startfehler verpassen.

An diesem Punkt sollten Sie sich nicht auf Perfektion konzentrieren. Das sofortige Ziel ist einfach: Das App-Programm starten, später einen JavaScript-Fehler auslösen und bestätigen, dass Ereignisse bei Sentry ankommen. Sobald das funktioniert, werden die native und die Release-Schichten viel einfacher zu verstehen.

Konfigurieren von Native iOS- und Android-Projekten

An diesem Punkt erhalten viele React Native-Teams einen falschen Eindruck der Vollständigkeit. Das JavaScript-SDK ist installiert, Ereignisse erscheinen und jeder denkt, dass Crash-Reporting abgeschlossen ist. Es ist nicht der Fall. Wenn die native Integration ausgeschaltet ist, werden einige der Crashes, die Sie am meisten interessieren, nie bei Sentry in einer verwertbaren Form ankommen.

Was hat sich auf iOS geändert

Öffnen Sie das iOS-Projekt und überprüfen Sie, was der Zauberer geändert hat. In einem leeren React Native-App bedeutet das Updates um den Anwendungsstart und die Buildphasen. Sie suchen nach Sentry-Initialisierungshooks und Uploadschritten, die mit Ihrem Build-Prozess verbunden sind.

In Xcode überprüfen Sie diese Orte:

• App Delegate-Startcode. Die App benötigt eine native Sentry-Initialisierung frühzeitig bei der Startphase.
• Build Phasen. Suche nach jeder Sentry-Upload-Script-Beziehung, die mit Debugsymbolen oder Sourcemap-Verwaltung zusammenhängt.
• Build-Einstellungen und Archivverhalten. Symboldateien müssen generiert und während Archivbuilds verfügbar sein.

Wenn Ihre App AppDelegate.mmverwendet, sitzt die Initialisierung oft in der Nähe der React Native-Bridge-Bootstrapping.

Die genaue Dateiinhalt kann sich je nach React Native-Version, Vorlage und Verwendung der neuen Architektur ändern, daher sollten Sie keine Snippets aus zufälligen Repositories kopieren, es sei denn, sie passen Ihrem Projektformat.

Was zählt ist der Zweck: iOS-native Crashs benötigen Symboldaten, und die App muss Sentry vor dem Crash zuverlässig beobachten können.

Wenn iOS-Crashs in Sentry mit nicht lesbaren native Frames erscheinen, ist das Problem meist nicht "Sentry ist kaputt." Es ist die Symbol-Upload- oder Release-Übereinstimmung.

Was hat sich auf Android geändert android/build.gradle, android/app/build.gradleAndroid fügt normalerweise Änderungen in Gradle-Dateien und manchmal Manifest-Ebene-Konfiguration hinzu. Überprüfe die und jede Sentry-zugehörige Plugin- oder Task-Verkabelung.

Dinge zu überprüfen:

1. Der Sentry Gradle-Plugin wird angewendet, damit Release-Artikel während der Buildzeit verarbeitet werden können.
2. Die Variante-Verwaltung ist sinnvoll wenn Sie Produktflavors oder mehrere Buildtypen verwenden.
3. ProGuard- oder R8-Ausgaben werden berücksichtigt wenn Ihre Release-Builds schrumpfen oder verschleieren code.

Eine häufige Android-Fehlannahme ist, dass ein erfolgreicher lokaler Debug-Lauf beweist, dass die Release-Konfiguration korrekt ist. Das tut sie nicht. Der Release-Weg ist anders, insbesondere wenn Minifizierung und CI-Signierung im Spiel sind. Wenn Ihr Team separate Debug-, Staging-, QA- und Store-Builds unterhält, ist dieser Abgleich der Mobile-Buildtypen eine nützliche Referenz für die Anpassung der Überwachungsverhalten an jeden Build-Varianten.

Native-Einstellungen, die Zeit sparen

Halten Sie sich nicht bei „Der Zauberer hat Dateien geändert.“ auf. Überprüfen Sie das Verhalten direkt.

Verwenden Sie diese Liste:

• Archivieren Sie eine iOS-Build lokal und bestätigen Sie, dass die Verarbeitung von Symbolen während der Buildzeit nicht fehlschlägt.
• Erstellen Sie eine Release-Android-Build und überprüfen Sie die CI-Protokolle auf Aufgaben, die mit Sentry zusammenhängen.
• Überprüfen Sie die Paketnamen- und Bundle-Identifier-Kartierung in Sentry, wenn Sie mehrere Apps unter einer Organisation verwalten.
• Bestätigen Sie die Konventionen für die Versionsnummerierung jetzt, bevor CI Artefakte unter inkonsistenten Namen hochlädt.

Hier ist, was normalerweise nicht gut funktioniert:

Die beste Einrichtung ist langweilig. Die native Start-Hooks sind im Einsatz, die Build-Skripte laufen jeden Tag und die Release-Namen sind deterministisch über iOS, Android und JavaScript-Bundles.

Automatisierung von Releases und Source Maps

Wenn es ein Ort gibt, an dem die Sentry-React-Native-Einrichtungen auseinanderfallen, ist es hier. Teams installieren den SDK, sehen Ereignisse und verschieben die Automatisierung der Releases. Dann kommt das erste ernsthafte Produktionsproblem herein und die Stack-Spur ist minimiert, der Release fehlt oder die Upload der Source-Map gehörte zu einem anderen Bundle.

Manuelle Source-Map-Uploads klingen akzeptabel, wenn Sie selten liefern. In der Praxis scheitern sie, weil Menschen schlecht bei wiederholten Release-Verwaltung sind.

Warum manuelle Uploads in der Praxis scheitern

Die Fehlerarten sind vorhersehbar:

• Jemand vergisst, Karten hochzuladen nach einer spätnächtlichen Hotfix.
• Die hochgeladenen Dateien gehören zu einem anderen Commit als die Binary- oder OTA-Bundle, die die Benutzer ausführen.
• Der Release-Name ändert sich leicht zwischen iOS, Android und CI-Schritten.
• Ein Neubau erfolgt nach der Karten-Hochladung und ungültigt, was Sentry gegenüber abgleichen sollte.

Deshalb empfehle ich nicht, die Schritte in Notion zu dokumentieren. Es funktioniert, bis ein dringender Release unter Druck herausgeht.

Eine Release-Prozess, der tatsächlich hält

Ein zuverlässiger Setup hat einige Eigenschaften:

• Release IDs werden einmal generiert und überall wiederverwendet. Build-, Bundle- und Upload-Schritte finden in derselben Pipeline statt.
• Quellkarten werden von CI hochgeladen, nicht von einem Entwickler-Notebook..
• Die App initialisiert Sentry mit demselben Release-String, den CI während des Uploads verwendet hat.Dieser letzte Punkt ist wichtiger als oft angenommen. Sie benötigen nicht nur Quellkarten in Sentry. Sie benötigen die richtigen Quellkarten, die an das genaue Release-Identifikator angehängt sind, das vom App am Laufzeitpunkt ausgegeben wird.
• Wenn Ihr Team bereits mobile Automatisierung standardisiert hat, passt sich diese Anleitung zu automatischen Build- und Release-Workflows mit __CAPGO_KEEP_0__ Actions gut in das gleiche Betriebsmodell. Wenn Ihr Team bereits mobile Automatisierung standardisiert hat, passt sich diese Anleitung zu automatischen Build- und Release-Workflows mit __CAPGO_KEEP_0__ Actions gut in das gleiche Betriebsmodell.

Release IDs werden einmal generiert und überall wiederverwendet. Build-, Bundle- und Upload-Schritte finden in derselben Pipeline statt..

Quellkarten werden von CI hochgeladen, nicht von einem Entwickler-Notebook. automatic build and release workflows with GitHub Actions Dieser letzte Punkt ist wichtiger als oft angenommen. Sie benötigen nicht nur Quellkarten in Sentry. Sie benötigen die richtigen Quellkarten, die an das genaue Release-Identifikator angehängt sind, das vom App am Laufzeitpunkt ausgegeben wird.

A praktische CI-Skriptmuster

Verwenden Sie ein Skript wie dieses in CI und füllen Sie Werte aus Ihrem Pipeline-Umgebung:

#!/usr/bin/env bash
set -euo pipefail

export SENTRY_AUTH_TOKEN="$SENTRY_AUTH_TOKEN"
export SENTRY_ORG="your-org"
export SENTRY_PROJECT="your-project"

RELEASE_NAME="${APP_VERSION}+${GIT_SHA}"

npx sentry-cli releases new "$RELEASE_NAME"

npx react-native bundle \
  --platform ios \
  --dev false \
  --entry-file index.js \
  --bundle-output ./dist/main.jsbundle \
  --sourcemap-output ./dist/main.jsbundle.map

npx sentry-cli releases files "$RELEASE_NAME" upload-sourcemaps ./dist \
  --rewrite \
  --strip-prefix "$(pwd)"

npx sentry-cli releases finalize "$RELEASE_NAME"

Sie müssen die Bündelkommando für Android anpassen und viele Teams teilen Sie Plattform-spezifische Aufgaben anstatt eine Skript zu zwingen, beide zu tun. Das ist in Ordnung. Was zählt ist Konsistenz.

Die Veröffentlichungsdisziplin besiegt cleveres Scripting. Wählen Sie eine Namenskonvention, injizieren Sie sie in die App bei der Buildzeit und lassen Sie lokale Ad-hoc-Uploads nicht mit CI konkurrieren.

Für React Native bevorzuge ich die Speicherung der Veröffentlichungszeichenfolge in einer build-generierten Konfigurationslocation und die Lesung während Sentry.init():

Sentry.init({
  dsn: Config.SENTRY_DSN,
  release: Config.SENTRY_RELEASE,
  dist: Config.SENTRY_DIST,
});

Der Gewinn ist einfach. Wenn ein Ereignis eintritt, kann Sentry die minimierte Frame zurück auf den code mappen, den Sie verschickt haben, und nicht auf den code , den Sie glauben, verschickt zu haben.

Leistungsmessung und benutzerdefinierte Ereignisse erfassen

Crashes erzählen Ihnen, was gebrochen ist. Leistungstracing erzählt Ihnen, was die Benutzer vorher gefühlt haben, bevor sie aufgaben.

Ein gemeinsamer Bericht klingt wie folgt: „Die Dashboard ist langsam.“ Das ist nicht genug, um zu debuggen. Langsam wo? Bei der Navigation? Während der Datenabfrage? Während der Renderung eines schweren Charts? Sentry wird hier nützlich, wenn Sie aufhören, es wie einen Fehlerposteingang zu behandeln und anstatt dessen die App-Verhalten instrumentieren.

Ein langsames Bildschirm anstatt zu raten

Beginnen Sie damit, die Leistungstracing in Ihrer Initialisierung zu aktivieren. Die genaue Abtaststrategie hängt von Ihrer Umgebung und Ihrem Volumen-Toleranzniveau ab, aber die Struktur sieht wie folgt aus:

Sentry.init({
  dsn: Config.SENTRY_DSN,
  tracesSampleRate: 1.0,
});

Wenn Sie React Navigation verwenden, verbinden Sie die Integration so, dass Bildschirmübergänge Spuren erzeugen. Dann reproduzieren Sie den Vorwurf auf einem physischen Gerät und nicht nur auf einem Simulator. Simulatoren verbergen den Art der Schwierigkeit, die Benutzer wahrnehmen.

Ein praktisches Dashboard-Beispiel:

1. Ein Benutzer öffnet das Hauptdashboard nach dem Anmelden.
2. Die Navigation ist abgeschlossen, aber der Inhalt erscheint verspätet.
3. Die Spur zeigt, dass die Bildschirmtransaktion lang ist.
4. Kinder-Spuren offenbaren einen API-Anfrage und einen teuren Render-Path.
5. Sie optimieren den Render-Path, schicken ihn erneut und vergleichen die neue Spur-Form.

Das ist besser als aus dem Bauch zu fühlen.

Für Teams, die breit über Webview- oder Hybrid-App-Monitoring-Muster nachdenken, ist diese Schriftstück über Leistungsmessung in Capacitor-Projekten ausreichend wertvoll, weil der operative Denkansatz ähnlich ist, auch wenn die Stacks sich unterscheiden.

Bei Fehlern hilfreiche Kontext hinzufügen

Daten zur Leistung werden nützlicher, wenn Ereignisse geschäftlichen Kontext tragen. Nicht nur Schönheitsmetadata. Nur genug, um zu beantworten, wer betroffen war, auf welchem Bildschirm sie waren und was vor dem Scheitern passierte.

Verwenden Sie diese Werkzeuge gezielt:

• Benutzerkontext mit Sentry.setUser() so dass Supportberater Berichte an einen betroffenen Account ohne Durchforstung von Vermutungen korrelieren können.
• Brotkrumen für Aktionen wie das Anklicken von 'Absenden', das Öffnen eines Modals oder das Starten einer Synchronisierung.
• Benutzerdefinierte Tags für Dimensionen wie Tarifart, Flag für Features oder API Region.
• Fehler mit zusätzlichem Kontext wenn Sie Fehlersituationen fangen und wieder werfen oder kontrollierte Fehlersituationen aufdecken.

Beispiel:

Sentry.setUser({
  id: user.id,
  email: user.email,
});

Sentry.addBreadcrumb({
  category: 'navigation',
  message: 'Opened dashboard screen',
  level: 'info',
});

try {
  await loadDashboard();
} catch (error) {
  Sentry.captureException(error, {
    tags: { screen: 'dashboard' },
    extra: { widget: 'balance-summary' },
  });
}

Ein Brotkrumenpfad ist oft der Unterschied zwischen „Der Benutzer sagt, das App gefroren ist“ und „Die App ist nach dem Öffnen des Dashboards, dem Starten des Synchronisierens und dem erneuten Versuch eines veralteten Anforderung fehlgeschlagen.“

Wenn die benutzerdefinierte Instrumentierung schief geht, geht sie meistens schief, indem sie zu laut ist. Fassen Sie nicht jeden Tastendruck in der App für immer ein. Fassen Sie die Grenzen, Zustandsübergänge und Operationen ein, die beim Debuggen relevant sind. Genug Kontext, um das Ereignis zu erklären. Nicht genug, um es zu ersticken.

Ihre Integration überprüfen und Fehler beheben

Sie sollten Sentry vor der Veröffentlichung, nach Änderungen im Build-Pipeline und nach SDK-Upgrades überprüfen. „Es funktionierte Monate her“ ist kein bedeutender Test.

Der sauberste Weg ist, kontrollierte Fehler für beide JavaScript- und native Wege auszulösen und zu überprüfen, wie sie in Sentry landen.

Sicherheitsfunktionen für Testereignisse auslösen

Für einen JavaScript-Fehler fügen Sie einen temporären Button in einer nicht-produktiven Anzeige ein:

<Button
  title="Trigger JS Error"
  onPress={() => {
    throw new Error('Test JavaScript Sentry error');
  }}
/>

Für einen erfassten Ausnahmefall, der das App nicht abstürzen lässt:

<Button
  title="Capture Exception"
  onPress={() => {
    Sentry.captureException(new Error('Handled Sentry test error'));
  }}
/>

Native Crash-Testing sollte sorgfältig und nur in der Entwicklung oder in kontrollierten QA-Builds erfolgen. Die genauen Hilfsmethoden, die verfügbar sind, können je nach SDK-Version und Plattform-Verkabelung variieren, daher bevorzuge ich die Verwendung der SDK-dokumentierten native Crash-Test-Utility, wenn sie vorhanden ist, anstatt eigene Crash-Pfade zu erfinden.

Was Sie im Sentry-UI überprüfen sollten

Wenn das Ereignis erscheint, überprüfen Sie mehr als den Titel.

Überprüfen Sie diese Felder:

• Plattform und Mechanismus. Dies hilft, JS-Ausnahmen von nativen Crashs zu unterscheiden.
• Release und dist. Wenn sie leer oder falsch sind, werden Source Maps und Symbolikation aus dem Gleichgewicht geraten.
• Stack Frames. Lesbare Quellortung sollte für korrekt hochgeladene JavaScript-Maps erscheinen.
• Breadcrumbs und Tags. Bestätigen Sie, dass Ihr benutzerdefinierter Kontext eingetroffen ist.
• Umgebung. Stellen Sie sicher, dass sich Entwicklung- und Produktionsereignisse nicht in einem Stream vermischen.

If ein natives Ereignis eintritt, aber eine schlechte Symbolisierung hat, ändern Sie nicht weiterhin die Anwendung code. Das ist meistens ein Problem mit dem Build-Artifact.

Allgemeine React Native Sentry Fehlerbehebung

Ein letzter Gewohnheit, die sich auszahlt, ist das Halten eines kleinen "Überwachungs-Test"-Checklisten in Ihrem Release-Prozess. Triggeren Sie eine JS-Ereignis in der Staging-Umgebung, bestätigen Sie die Release-Werte und überprüfen Sie die Quellorte, bevor Sie ein Build voranbringen

Integrieren Sie mit Live-Update-Workflows wie Capgo

Live-Updates ändern das Release-Modell. Das Binärdatei im Store bleibt gleich, während die JavaScript-Bundle darunter sich ändern. Wenn Sentry immer noch nur an die ursprüngliche App-Version denkt, werden die Stapelspuren schnell irreführend

Die Lösung besteht darin, dass die Sentry-Release-Identität dem lebenden Bundle folgt, nicht nur der nativen Binärdatei Die Übereinstimmung von Release-Identifikatoren mit lebenden BundelnFür Live-Update-Workflows behandeln Sie __CAPGO_KEEP_0__ und __CAPGO_KEEP_1__ als Laufzeit-Identifikatoren, die an das gelieferte JavaScript-Paket gebunden sind. Die native App-Version ist immer noch wichtig, aber sie reicht nicht aus, sobald sich Bundeln unabhängig voneinander ändern können

Ein praktisches Muster sieht wie folgt aus:

__CAPGO_KEEP_0__ release __CAPGO_KEEP_1__ dist __CAPGO_KEEP_2__

__CAPGO_KEEP_3__

• Verwenden Sie die native App-Version als Teil des Basis-Release-Namens.
• Fügen Sie die Live-Update-Version oder den Paket-Identifikator hinzu.
• Verwenden Sie dist für die Kanal- oder Build-spezifische Differenzierung, wenn das zu Ihrem Modell passt.
• Hochladen Sie Quellkarten für jeden Live-Bundle unter genau diesem Release-Identifikator.

Beispiel: Wenn Ihre App bei der Startzeit Update-Metadaten lädt, initialisieren Sie Sentry mit Werten, die aus der derzeit aktiven Bundle abgeleitet werden und nicht nur aus der statischen Build-Konfiguration.

Sentry.init({
  dsn: Config.SENTRY_DSN,
  release: activeBundle.releaseName,
  dist: activeBundle.channel,
});

Dadurch wird, wenn ein Benutzer bei einem hotfixierten Bundle einen Fehler trifft, Sentry die Frames gegen die Quellkarte für diesen Hotfix anstatt gegen die ältere Store-Bundle auflöst.

Dies ist bei jedem OTA-Workflow relevant. Wenn Sie eine gute Einführung in die beweglichen Teile hinter diesem Liefermodell wünschen, ist diese Erklärung von wie Live-Updates in Capacitor-Apps funktionieren eine solide Referenz.

Hier ist der Art von Betriebsansicht, die Teams anstreben, wenn sie Update-Metadaten mit Release-Tracking kombinieren:

The Hauptfehler zu vermeiden ist die Wiederholung einer statischen Release-String für jeden post-Store-Update. Wenn mehrere Pakete die gleiche Sentry-Release teilen, wird das Debuggen wieder zu einem Raten.

Wenn Ihr Team außerhalb der App-Store-Bewertungszyklen Reparaturen ausfährt, Capgo ist eine Bewertung wert. Es gibt Capacitor-Teams eine strukturierte Möglichkeit, live Updates bereitzustellen, Zielkanäle anzusteuern, Rollouts zu steuern und sich schnell von schlechten Releases erholen. Paaren Sie das mit einer disziplinierten Namensgebung für Sentry-Release und Uploads von Source-Maps und Sie erhalten einen Workflow, bei dem Fehler immer noch auf die genauen code-Benutzer hinweisen, die code laufen.