App-Release-Automatisierung: Schneller liefern

Die meisten Ratschläge zur App-Release-Automatisierung App-Release-Automatisierung beginnen mit der gleichen Rezeptur: Fügen Sie mehr Werkzeuge hinzu, automatisieren Sie mehr Schritte und die Releases werden schneller. Diese Ratschläge vermissen jedoch den teuren Teil der mobilen Lieferung. Ein Pipeline kann eine Build kompilieren, testen, signieren und hochladen, während Ingenieure immer noch Stunden damit verbringen, Genehmigungen zu koordinieren, Dashboards zu überprüfen, Notizen vorzubereiten und zu entscheiden, ob ein Produktionsfix auf die Überprüfung durch den App-Store warten kann.

Ein 2025-Umfrage unter 300 mobilen Ingenieuren in den Vereinigten Staaten und dem Vereinigten Königreich ergab, dass Teams durchschnittlich 5 Stunden pro Release für sinnlose Arbeitentsprechen 130 verlorene Ingenieur-Stunden pro JahrDie gleiche Umfrage berichtete, dass 52% Ein Drittel der Zeit in jedem Release-Zyklus wird für nicht produktive Aufgaben verwendet.DevOps.com-Umfrage zu mobilen Release-Management) The practical lesson is uncomfortable but useful: automation only improves delivery when it removes handoffs and shortens the path from a verified change to measurable user impact.

Inhaltsverzeichnis

• Der Paradox in der Automatisierung von Mobilfunkanwendungen
  • Beginne mit dem Workflow, nicht mit dem Katalog der Werkzeuge
• Was App-Release-Automatisierung tatsächlich bedeutet
  • Die Mobilfunklieferung hat eine externe Schranke
  • Definiere den Zielort vor der Befehlsausführung
• Ein wiederholbarer Release-Pipeline erstellen
  • Eine praktische Sequenz
• App Store Releases gegenüber sofortigen Live Updates
  • Mache die Entscheidung bei der Erstellung
• Rollout- und Rollback-Muster, die Katastrophen verhindern
  • Bau den Sicherheitskreis
• Beobachtbarkeit und Compliance über Releasekanäle hinweg
  • Behandeln Sie Kanäle als Grenzen für Richtlinien
• Wo Capgo in Ihrem Automatisierungsstapel Platz findet
  • Connect deployment to user impact

Der Automatisierungsparadox in mobilen Releases

Mehr Automatisierung führt nicht automatisch zu schnelleren Mobilfunkveröffentlichungen. In einem Bericht über die Mobilfunkveröffentlichungsmanagement 2025, 75% der Teams sagten, sie hätten einen moderaten bis signifikanten Investition in die Automatisierung von Releases, trotzdem kämpften die meisten noch mit Release-Hemmungen. Teams, die 6 bis 10 Stunden pro Release auf niedrigwertige Arbeit verbrachten, waren oft die Teams mit der meisten Automatisierung, nicht die wenigsten. (2025 Bericht zur mobilen Release-Management-Lage)

Das Ergebnis ist logisch, sobald man sich über den CI-Server hinausblickt. Ein Build kann erfolgreich abschließen, aber jemand muss immer noch bestätigen, dass die richtige Zweig, eine Genehmigung anfordern, die Release-Notizen überprüfen, einen Verteilungs-Kanal wählen, einen Testfehler interpretieren und entscheiden, ob eine gestufte Rollout fortgesetzt werden soll. Jeder Übergabe schafft eine Warteschlange. Jede Warteschlange schafft Kontextwechsel. Ein Pipeline, der isolierte Aufgaben automatisiert, kann den tatsächlichen Release-Prozess genauso langsam lassen, nur mit mehr Dashboards zum Überwachen.

Praktische Regel: Automatisieren Sie den Entscheidungsweg, nicht nur die Befehle.

Die wertvollste Arbeit sitzt meist an den Grenzen. Ein signiertes Artefakt sollte seine Commit, Version, Umgebung und Release-Metadaten tragen. Ein Testfehler sollte die automatische Blockierung der Promotion verursachen, anstatt eine Nachricht in einem Chat zu erstellen, die jemand bemerken könnte. Eine Rollout sollte einen Besitzer, eine definierte Beobachtungszeit und ein objektivierbares Stop-Criterium haben. Ohne diese Kontrollen haben die Teams die automatisierte Ausführung, aber die manuelle Koordination behalten.

Beginnen Sie mit dem Workflow, nicht mit dem Katalog der Werkzeuge

Zeichnen Sie den Weg, den eine Änderung von der Merge bis zum Gerät des Benutzers nimmt. Markieren Sie jeden Genehmigungsprozess, jede Tabelle, jede Nachricht in einem Chat, jede manuelle Upload-Operation und jede wiederholte Überprüfungsstufe. Dann fragen Sie sich, ob jede Intervention die Benutzer schützt oder nur die fehlende Pipeline-Zustand kompensiert.

Continuous Integration bleibt wertvoll, weil es Teams eine wiederholbare Möglichkeit gibt, Änderungen frühzeitig zu validieren. Vorteile der kontinuierlichen Integration für mobile Teams become much clearer when the practice is connected to release ownership, artifact traceability, and production feedback rather than treated as a collection of automated checks.

Ein einfacherer Pipeline mit klaren Promotion-Regeln kann oft einen komplexen Stapel mit überlappenden Werkzeugen besiegen. Halten Sie Menschen an Orten, an denen Urteilsvermögen erforderlich ist, wie z.B. die Genehmigung eines risikoreichen nativen Migrationsvorgangs. Entfernen Sie sie aus wiederholter Arbeit, wie z.B. der Wiederherstellung des gleichen Artefakts, der Kopie von Release-Notizen oder der manuellen Upload eines bereits durch die Pipeline validierten Pakets.

Was bedeutet App Release Automation wirklich?

App Release Automation Die App Release Automation ist das vollständige Lieferungssystem, das eine Änderung von einem code Commit zu einer kontrollierten Benutzerfreigabe bewegt. Sie umfasst die Kompilierung, automatisierte Tests, Erstellung von Artefakten, Signierung, Verifizierung, Upload, Verteilung, geplante Exposition, Überwachung und Rollover. Ein grünes Build ist nur ein Checkpoint in dieser Kette.

Denken Sie an die Pipeline als eine Reihe von Toren. Der erste Tor bestätigt, dass das code gebaut werden kann. Der nächste überprüft das Verhalten durch Einheitstests, Integrations- und Plattformtests. Ein weiterer erstellt ein reproduzierbares Artefakt, signiert es mit den richtigen Zugriffsberechtigungen und überprüft die Signatur. Die letzten Tore entscheiden, wohin das Artefakt geht, wer es erhält und was passiert, wenn das Laufzeitverhalten schlechter ist als erwartet.

Mobile Lieferungen haben einen externen Tor

Web-Deployments können oft direkt von einer Produktionspipeline in einen Browser übergehen. Native mobile Releases haben jedoch einen anderen Behörden in der Pfad, den App Store. Apples historische Überprüfungsprozess illustriert, warum die Release-Engineering um externe Genehmigung entwickelt wurde. Im Juli 2009 konnten Genehmigungen Wochen dauern. Apple berichtete später, dass 95% der Apps innerhalb von sieben Geschäftstagen bearbeitet wurden im Juni 2010 und seine Entwickler-Portal berichtete 98% der neuen und aktualisierten Apps innerhalb von fünf Geschäftstagen bearbeitet wurden by July 3, 2014. A 2024 summary noted an average review time of less than 12 Stundenmit 90% innerhalb von weniger als 24 Stunden. (Die Geschichte der iOS-App-Zulassungen)

Ein schnellerer Review-Prozess entfernt das operative Problem nicht. Teams müssen immer noch die Koordination von Submission, staged Release, Notfallreaktion und Rollbackentscheidungen um einen Kanal herum treffen, über den sie nicht vollständig kontrollieren. Deshalb muss die App-Release-Automatisierung auch eine Verteilungsstrategie und eine Beobachtung umfassen und nicht nur CI/CD.

Definieren Sie den Zielort, bevor Sie den Befehl geben

Eine nützliche Release-Übersicht beantwortet vier Fragen:

• Was hat sich geändert: Identify the commit, artifact, version, and native or web scope.
• Wer erhält es: Angabe von Beta, Staging, Produktions- oder einer engeren Zielgruppe.
• Wie es überprüft wird: Benennen Sie die erforderlichen Tests, Signaturprüfungen und Laufzeitzeichen für die Förderung.
• Wie es rückgängig gemacht wird: Beschreiben Sie das Rollback- oder Deaktivierungsmechanismus vor der Veröffentlichung.

Dieses Modell funktioniert über native iOS-, Android- und hybride Capacitor-Anwendungen hinweg. Es offenbart auch den Punkt, an dem die manuelle Arbeit zurückkehrt: Teams automatisieren oft die Paketierung, lassen aber die Kanalwahl und die Produktionsförderung einer informellen Unterhaltung überlassen.

Ein wiederholbares Release-Workflow

Ein zuverlässiger mobiler Workflow sollte denselben Änderungen denselben Artefakt, mit denselben Überprüfungen, unabhängig davon, welcher Ingenieur ihn initiiert hat, produzieren. Die praktische Sequenz ist einfach: Commit, Validierung, Build, Signieren, Verteilen, Beobachten und Förderung.

Beginnen Sie damit, die Arbeit zu automatisieren, die am meisten Variabilität erzeugt. Tests, Linting, statische Analyse, signierte Build-Erstellung, Release-Note-Erstellung und Uploads sollten aus derselben Pipeline-Definition ausgeführt werden. Diese Schritte retten nicht nur Tastatureingaben. Sie verhindern, dass sich die Umgebung eines Ingenieurs, ein vergessenes Kommando oder ein falsches Signierungsprofil auf das Ergebnis auswirken.

Eine praktische Sequenz

1. Überprüfen Sie den Commit. Führen Sie Formattierungsprüfungen, Linting, statische Analyse, Einheitstests und Integrationsprüfungen durch, bevor Sie ein Releaseartefakt erstellen. Versagen Sie frühzeitig, während der Änderung noch leicht zu korrigieren ist.

2. Bauen Sie einmal für die Promotion. Generieren Sie die iOS- und Android-Artefakte in einem kontrollierten Umfeld. Rebuilden Sie nicht separat für Beta und Produktionsversion, wenn der zugrunde liegende Binärdatei identisch sein soll. Verschieben Sie stattdessen das überprüfte Artefakt.

3. Signieren und überprüfen. Halten Sie die Signierungsdaten außerhalb des Repositorys, injizieren Sie sie sicher an der Buildzeit und überprüfen Sie das resultierende Paket vor dem Upload. Ein erfolgreicher Compile beweist nicht, dass das Verteilungsartefakt korrekt signiert ist.

4. Veröffentlichen Sie mit Metadaten. Befügen Sie den Commit, die Release-ID, den Zielkanal, die Änderungsliste und die Buildkonfiguration. Metadaten machen ein Paket zu einem überprüfbaren Release-Protokoll.

5. Bewerten Sie absichtlich. Hochladen Sie zunächst in die Beta- oder Staging-Umgebung und bewerten Sie dann nach expliziter Genehmigung und Gesundheitsregeln. Teams, die sich auf CI/CD-Canary-Deployments für die gleiche Prinzipien erkennen: Exponieren Sie eine Änderung schrittweise anstatt die Produktionsumgebung als einzelnen Schalter zu behandeln.

Ein mobiler CI/CD-Leitfaden empfiehlt, den gesamten Build-, Test- und Sign-Zyklus unter 15 Minuten. (Mobile-App-Veröffentlichungs- und -Freigabehandbuch) Das ist keine universelle Gesetz, aber es ist ein nützliches Betriebsmaß. Kurze Pipelines machen kleine Releases praktisch. Lange Pipelines fördern das Bündeln, und das Bündeln erhöht die Anzahl der Änderungen, die bei einem Fehler diagnostiziert werden müssen.

Die häufigste Verzögerung ist nicht die Kompilierung. Es ist das Warten auf einen Menschen, der eine Ergebnis interpretiert, ein Anmeldeproblem behebt, eine Beförderung genehmigt oder einen Schritt wiederholt, den der System einmal aufgezeichnet haben könnte. Die Bereitstellungsaufschlüsselung für mobile Teams ist am nützlichsten, wenn er auf diese Handover angewendet wird, nicht nur um Build-Befehle zu erstellen.

App Store Releases gegenüber Instant Live Updates

Ein vollständiger Store-Release und ein live update lösen unterschiedliche Probleme. Der Store ist der richtige Kanal für Änderungen, die das native Binärdatei ändern, neue Berechtigungen anfordern, native Plugins hinzufügen, die Berechtigungen ändern oder eine Hauptversionsumstellung erfordern. Ein Live-Update-Mechanismus ist besser geeignet für Änderungen innerhalb des bereits installierten Web-Schicht, wie JavaScript, CSS, Kopieren, Konfiguration und kompatible Assets.

Die Unterscheidung ist bei Vorfällen wichtig. Ein Store-Submission stellt die Reparatur hinter der Überprüfung und der Nutzerakzeptanz. Ein live update kann eine signierte Web-Bundle an einen ausgewählten Kanal veröffentlichen und es anwenden, wenn die App gestartet wird, vorausgesetzt, die installierte native Shell unterstützt das Bundle. Es eliminiert nicht die Tests oder die Governance. Es ändert nur, welcher Teil des Lieferwegs die Genehmigung benötigt.

Entscheidung am Buildzeitpunkt treffen

Die Pipeline sollte die Änderung vor der Veröffentlichung klassifizieren. Wenn ein Pull-Request native Projektdateien, Berechtigungen, Zugriffsrechte oder Plugin-Konfigurationen ändert, leitet es zur Veröffentlichung in einem App-Store. Wenn es nur die kompatible Web-Bundle ändert, leitet es zur Live-Update-Pfad, unter Vorbehalt von Tests und Richtlinien.

Dieses Klassifizierung verhindert eine häufige Fehlerquelle: das Ausnutzen von Live-Updates, um die Veröffentlichungsdisziplin zu umgehen. Ein Web-Bundle benötigt auch Versionskontrolle, Signierung, Kanalsteuerung, Kompatibilitätsprüfungen und Telemetrie. Teams sollten auch definieren, was passiert, wenn ein Gerät offline ist, einen nicht unterstützten Shell läuft oder die Aktualisierung nicht sicher anwenden kann.

Der Vergleich von App-Store-Veröffentlichungen und direkten Updates ist nützlich, um diese Grenze mit Produktions-, Sicherheits- und Supportteams zu dokumentieren. Die richtige Frage ist nicht, ob eine Kanal universell schneller ist. Es ist, ob die Änderung im Binärdatei oder in der updatbaren Ebene gehört.

Rollout- und Rollback-Muster, die Katastrophen verhindern

Ein Release-Pipeline kann perfekt deployen und trotzdem eine schlechte Aktualisierung an jeden Benutzer verteilen. Eine sichere Automatisierung begrenzt die Auswirkungen zuerst, beobachtet die reale Laufzeitverhalten und greift dann zu einer vordefinierten Wiederherstellungsaktion, wenn die Signale sich verschlechtern.

Für mobile Mikro-Veröffentlichungen empfiehlt die Leitlinie, die Aktualisierung für 10 bis 60 Minuten zu beobachten nach der Veröffentlichung. Überwachen Sie Crash- und Fehlerraten, Start-up-Rückgänge, ANRs und Geschäftsindikatoren wie Konversion oder Retention. Wenn ein Schwellenwert überschritten wird, pausieren Sie die Promotion, rollen Sie die Bundle zurück oder deaktivieren Sie das betroffene Verhalten mit einem Feature-Flag. Ratgeber für CI/CD für schnelle Mobilfunkveröffentlichungen)

Baue den Sicherheitskreis auf

Ein praktischer Rollout hat vier Kontrollen:

• Zielgerichtete Ausstrahlung: Beginne mit einer definierten Kanal oder Zielgruppe. Erweitere nur, wenn seine Signale innerhalb der vereinbarten Grenzen bleiben.
• Objektive Schwellenwerte: Speichere die Bedingungen, die die Promotion stoppen. „Alles gut“ kann kein Produktionskontrolle sein.
• Automatische Aktion: Pause die Werbung, rufen Sie die Bundle zurück oder deaktivieren Sie die Funktion ohne auf eine Besprechung zu warten.
• Veröffentlichungs Kontext: Binde den Kanal, die Release-ID, den Gerätekontext und die Crash-Logs so, dass Reaktanten die betroffene Bevölkerung identifizieren können.

Halten Sie einen Rollback-Schutz für etwa 5 bis 30 Minuten., mit Release-Metadaten, die jeder Entscheidung beigefügt werden.Mobile-Rollback-Leitfaden für kleine Releases) Die richtige Fenstergröße hängt von der Basisverhalten, den Verkehrsmustern und der Risikotoleranz ab. Ein für eine Kopie geeigneter Schwellenwert kann für eine Zahlungsabwicklung gefährlich sein.

Ein Rollback ist nicht nur ein technischer Schalter. Ein stufenweisees Release benötigt einen benannten Besitzer, der entscheidet, ob die Änderung repariert, deaktiviert oder ersetzt werden soll. Bewahren Sie die fehlgeschlagene Artefakt und seine Telemetrie auf, anstatt sie mit dem nächsten Build zu überschreiben. Diese Aufzeichnung hilft dabei, eine fehlerhafte Pakete von einer nativen Shell- oder Dienstfehler zu unterscheiden.

Die Release-Sicherheit hängt nicht nur von der Zeit zwischen dem Commit und der Bereitstellung ab, sondern auch von der Zeit zwischen der Erkennung und der Wiederherstellung.

Verwenden Sie das folgende Video als visuelle Referenz für die roll-backorientierte Release-Denke:

Für Capacitor-Teams Die Konfiguration des Rollbacks für Capacitor-Updates bietet Plattform-spezifische Mechanismen. Capgo-stilige Live-Updates können die Zeit von einem bestätigten Web-Schichtfehler bis zu einem kontrollierten Fix verkürzen, indem sie eine neue Store-Überprüfung vermeiden. Dieser Geschwindigkeitsvorteil entfernt jedoch nicht die Notwendigkeit für eine stufenweise Bereitstellung, Kompatibilitätsprüfungen und eine getestete Rückkehr in einen bekannten Zustand. Werkzeuge schließen den Bereitstellungssprung. Sie lösen jedoch nicht die unklare Besitzerrolle oder die schwachen Releasekriterien.

Beobachtbarkeit und Compliance über Release-Kanäle

Automatisierung schafft nur Geschwindigkeit, wenn das Team erklären kann, was passiert ist. Der Support muss wissen, welches Release ein Benutzer erhalten hat. Der Engineering-Team muss einen Crash mit einem Bundle, einem nativen Shell, einem Gerät und einem Kanal korrelieren. Die Compliance-Teams benötigen eine Audit-Trail, die zeigt, wer ein Release genehmigt hat, was getestet wurde, wo es geliefert wurde und wie das Team mit einem Fehler umgegangen ist.

Ein nützlicher Release-Record kombiniert die Bereitstellungs-Geschichte mit Evidenzen aus der Laufzeit. Verfolgen Sie die Versions-Geschichte, die Zuweisung von Kanälen, die Akzeptanz, die Fehler, die Geräte-Ebene-Protokolle und die Rollover-Ereignisse. Diese Aufzeichnungen sollten nach dem Release-Identifier suchen, anstatt sie aus Chat-Nachrichten und separaten Anbieter-Dashboards wiederherzustellen.

Behandeln Sie Kanäle als Grenzen für die Politik

Kanäle sind nicht nur bequeme Etiketten. Sie sollten die Zielgruppe und das Risiko kodieren. Ein Staging-Kanal könnte internen Testern zugänglich sein. Ein Beta-Kanal kann eine breitere, aber kontrollierte Zielgruppe erhalten. Die Produktion sollte die Überprüfungen und Genehmigungen erfordern, die der Anwendung angemessen sind, während ein Kunden-spezifischer Kanal strengere Isolation benötigen könnte.

Dieses Modell ist in der FinTech, im Gesundheitswesen und im E-Commerce wichtig, wo ein schneller Fix immer noch verantwortlich bleiben muss. Ein live update , das den Laden-Review umgeht, darf nicht den internen Autorisierung, der Sicherheits-Überprüfung oder der Änderungs-Verfolgung umgehen. Speichern Sie die Provenienz des Bundles, den Signierungsstatus, die beabsichtigte Zielgruppe und die Kompatibilitätsannahmen mit dem Release.

Differential delivery kann auch den Betriebsweg verbessern, indem nur geänderte Dateien gesendet werden, anstatt ein gesamtes Web-Bundle. Das reduziert die Menge an Daten, die Geräte herunterladen müssen, und macht kleinere Korrekturen einfacher zu verteilen, insbesondere für Benutzer mit unzuverlässigen Verbindungen. Der Vorteil ist nicht die Erlaubnis, die Validierung zu überspringen. Es ist ein effizienteres Transportprotokoll innerhalb eines regulierten Prozesses.

Wenn der Support nicht erkennen kann, was ein Gerät erhalten hat, ist das Release-System nicht ausreichend beobachtbar.

Legen Sie Retentions- und Zugriffsregeln vor einem Vorfall fest. Ingenieure sollten in der Lage sein, Fehlerdaten zu überprüfen, ohne jedem Operator die Erlaubnis zu geben, zu publizieren. Release-Manager sollten in der Lage sein, einen Kanal ohne Änderung der Anwendung code zu pausieren. Diese Grenzen ermöglichen es den Teams, schnell voranzukommen, während die Verantwortlichkeit erhalten bleibt.

Wo Capgo in Ihrem Automatisierungsstapel passt

Consider a production Capacitor app with a UI defect that blocks a critical user flow. The native shell is healthy, the fix changes only JavaScript and CSS, and waiting for a store submission would add an external approval step. The CI pipeline can run tests, build the web bundle, sign it, and publish it to a targeted channel through Capgo, where compatible users receive it on the next app launch.

Capgo ist eine Live-Update-Plattform für CapacitorJS- und Electron-Anwendungen. Sein offener Quellcode-Updater-Plugin arbeitet mit einer sicheren Cloud-Delivery-Dienstleistung, die signierte Web-Bundles veröffentlicht, während seine öffentlichen API- und CI/CD-Integrationen es ermöglichen, dass eine fusionierte Änderung durch die Build-, Signierung-, Veröffentlichungs- und Kanal-Veröffentlichung ohne manuelle Uploads fortschreitet.

Verbinde Bereitstellung mit Benutzerwirkung

Eine praktische Integration hält die bestehende native Pipeline im Gange. Die Speicherung von Releases bleibt für native Änderungen verantwortlich, während die Live-Update-Aufgabe kompatible Web-Schichten-Änderungen bearbeitet.

1. Klassifizieren Sie die Änderung. Erkennen Sie, ob der Commit native code- oder nur die updatbaren Web-Schichten berührt.
2. Führen Sie die normalen Überprüfungen durch. Verwenden Sie die gleichen Tests, Linting, statische Analyse und Sicherheitskontrollen wie bei jedem anderen Release.
3. Veröffentlichen Sie in einem Kanal. Senden Sie das signierte Bundle an Beta, Staging, Produktion oder eine kundenbezogene Zielgruppe.
4. Beobachten Sie die Akzeptanz und die Fehler. Überprüfen Sie die Geräteprotokolle, die Releasehistorie und die Fehlermetriken.
5. Promoten oder rückgängig machen. Erweitern Sie die Zielgruppe, wenn Signale gesund sind, oder verwenden Sie eine Rollover-Schutzfunktion, wenn sie es nicht sind.

Die Plattform unterstützt kanalbasierte Kanäle, automatische Rückschlagschutzfunktionen, differenzielle Updates und die Lieferung über ein globales Edge-Netzwerk in über 300+ Städte, laut der Veröffentlichungs-Produktinformation. (Capgo GitHub Handbuch zur Actions-Integration) Diese Funktionen adressieren den Gap zwischen „der Pipeline ist abgeschlossen“ und „die Benutzer sind sicher“, aber sie ersetzen die Release-Design nicht. Teams benötigen immer noch kompatible Bundle-Regeln, Genehmigungsrichtlinien, Überwachungsschwelle und eine klare Trennung zwischen native und web-layer Änderungen.

Die stärkste Konfiguration ist nicht ein separates Notfallverfahren. Es ist der gleiche Pipeline mit einem anderen Ziel. Ein Pull-Request kann die Release-Typ bestimmen, CI kann das Artefakt produzieren und signieren, Kanalregeln können die Auslieferung steuern und Telemetrie kann entscheiden, ob die Promotion fortgesetzt wird. Diese Anordnung reduziert das Koordinationsparadox, weil das System Kontext von code Änderung bis zum Benutzer-Ergebnis trägt.

Capgo bietet signierte Live-Updates, Channel-basierte Rollouts, Rollover-Schutz, Beobachtungsfunktionen und CI/CD-Integration für kompatible Änderungen der Web-Schicht von CapacitorJS und Electron. Besuchen Sie Capgo um Ihre bestehende Release-Pipeline mit schnelleren, kontrollierteren Reparaturen zu verbinden, ohne die App-Store-Abgabe als einzigen Weg zur Produktion zu behandeln.