---
title: "Patch Rollbacks: Der Lebensretter für deine Flutter-App"
description: "Lerne wie du mit Shorebird Code Push OTA Updates für Flutter-Apps durchführst und fehlerhafte Patches sofort zurückrollst. Der komplette Guide für sichere Deployments."
canonical_url: "https://robocitrus.com/blog/patch-rollbacks-lebensretter"
last_updated: "2026-07-19T00:12:32.265Z"
---

## Der Moment, wenn dein Update die App crasht

Es ist Freitagabend, 23:47 Uhr. Du hast gerade den letzten Bug gefixt und pushst voller Stolz das Update. "Endlich fertig", denkst du. Du schließt den Laptop und gehst ins Bett.

Samstag, 8:00 Uhr. 47 verpasste Anrufe. 283 neue E-Mails. 4,2 Sterne gefallen auf 1,8. Dein "kleiner Bugfix" hat die App für 50.000 User unbenutzbar gemacht.

**Klingt wie ein Albtraum?** Das ist die Realität für viele Entwickler, und der Grund, warum ich heute über das Wichtigste sprechen will, das mir als Flutter-Freelancer passieren kann: **Patch Rollbacks.**

## Was ist Code Push überhaupt?

Bevor wir über Rollbacks reden, müssen wir verstehen, was Code Push ist. Traditionell läuft ein App-Update so ab:

1. Du änderst Code
2. Du baust eine neue Version
3. Du lädst sie in den App Store hoch
4. Du wartest 1-3 Tage auf die Review
5. User müssen manuell updaten

Mit **Code Push** (auch OTA Updates genannt) sieht das anders aus:

1. Du änderst Dart-Code
2. Du pushst einen Patch
3. **User erhalten das Update sofort beim nächsten App-Start**

Kein App Store Review. Keine Wartezeit. Keine manuelle Update-Aktion der User.

## Shorebird: Code Push für Flutter

Während React Native schon länger CodePush von Microsoft hatte, fehlte Flutter lange eine vergleichbare Lösung. Das änderte sich mit [Shorebird](https://shorebird.dev), gegründet von ehemaligen Google-Flutter-Team-Mitgliedern.

### So funktioniert Shorebird technisch

Shorebird nutzt einen modifizierten Flutter-Engine, der beim App-Start nach Updates sucht:

```dart
// Die App prüft automatisch auf Updates
// Beim nächsten Neustart ist der Patch aktiv

// Oder manuell mit dem shorebird_code_push Package:
import 'package:shorebird_code_push/shorebird_code_push.dart';

final updater = ShorebirdUpdater();

Future<void> checkForUpdates() async {
  final status = await updater.checkForUpdate();
  
  if (status == UpdateStatus.outdated) {
    // Update verfügbar!
    await updater.update();
    // Beim nächsten App-Neustart ist der Patch aktiv
  }
}
```

### Was kann gepatcht werden?

- ✅ Jeglicher Dart-Code
- ✅ Generierter Code (z.B. Lokalisierungen)
- ✅ Dart-Dependencies (ohne native Änderungen)
- ❌ Assets (Images, Fonts), kommt bald
- ❌ Native Code (Java/Kotlin, Swift/Objective-C)
- ❌ Flutter Engine Version

## Der Workflow: Von Release zu Patch

### 1. Release erstellen

Zuerst erstellst du einen Release, das ist die Basis-Version, die in den App Store kommt:

```bash
# Shorebird initialisieren
shorebird init

# Release für Android erstellen
shorebird release android

# Release für iOS erstellen  
shorebird release ios
```

Das generierte `.aab` bzw. `.ipa` lädst du wie gewohnt in die Stores hoch.

### 2. Patch erstellen

Wenn du später Code änderst, erstellst du einen Patch:

```bash
# Bug in lib/main.dart gefixed?
shorebird patch android

# Ausgabe:
# 📱 App: My App
# 📦 Release Version: 1.0.0+1
# 📺 Channel: stable
# 🕹️ Platform: android [arm64, arm32, x86_64]
# 
# ✅ Published Patch!
```

**Das war's.** Alle User mit Version 1.0.0+1 bekommen beim nächsten App-Start automatisch den Fix.

## Staging: Patches vor dem Rollout testen

Hier wird's interessant, und wichtig für unser Rollback-Thema. Shorebird unterstützt verschiedene **Tracks**:

```bash
# Patch nur für Staging deployen
shorebird patch android --track=staging

# Lokal testen mit shorebird preview
shorebird preview --track staging --release-version 1.0.0+1
```

So kannst du Patches intern testen, bevor du sie auf alle User loslässt.

### Percentage-Based Rollouts

Noch sicherer: Schrittweises Ausrollen an nur einen Teil der User:

```dart
// In deiner App
Future<UpdateTrack> determineTrack() async {
  final rolloutPercentage = await fetchRolloutPercentage(); // z.B. aus Firebase
  final userGroup = await getUserGroupNumber(); // 1-100, lokal gespeichert
  
  // User in Gruppe 1-25 bekommen Beta-Patches bei 25% Rollout
  return userGroup <= rolloutPercentage 
    ? UpdateTrack.beta 
    : UpdateTrack.stable;
}
```

## Rollbacks: Der Lebensretter

Jetzt zum Kern des Artikels. **Was passiert, wenn dein Patch Probleme macht?**

### Methode 1: Track wechseln

Das Einfachste: Den problematischen Patch vom `stable`-Track entfernen:

```bash
# Patch von stable auf staging zurückstufen
shorebird patches set-track \
  --release-version 1.0.0+1 \
  --patch-number 2 \
  --track staging
```

User bekommen dann automatisch den letzten funktionierenden Patch (oder die originale Release-Version).

### Methode 2: Über die Shorebird Console

In der [Shorebird Console](https://console.shorebird.dev) kannst du:

1. Zum Release navigieren
2. "Change Track" auswählen
3. Den Track ändern (z.B. von `stable` zu `staging`)

**Ein Klick, alle User sind wieder auf der sicheren Version.**

### Methode 3: Neuen Patch pushen

Manchmal ist der schnellste Fix einfach ein neuer Patch:

```bash
# Revert im Code machen (git revert, manuell, etc.)
git revert HEAD

# Neuen Patch pushen
shorebird patch android
```

### Was passiert technisch beim Rollback?

Wenn ein Patch "zurückgerollt" wird:

1. Shorebird markiert den Patch als nicht mehr aktiv
2. Beim nächsten App-Start fragt die App nach Updates
3. Die API antwortet: "Kein neuer Patch verfügbar"
4. Die App nutzt den **letzten bekannten guten Zustand** (vorheriger Patch oder Release)

## Real-World Disaster Stories: Warum Rollbacks unverzichtbar sind

### Der Fall CrowdStrike (2024)

Obwohl kein Mobile-Beispiel, zeigt der CrowdStrike-Vorfall perfekt das Problem: Ein fehlerhaftes Update legte Millionen Windows-Rechner lahm, Krankenhäuser, Flughäfen, Banken. **Ohne schnelle Rollback-Möglichkeit dauerte die Recovery Tage.**

### Mobile App Disasters

Auch in der App-Welt gibt es genug Horror-Stories:

- **Spotify (2023):** Ein Update crashte die App auf älteren Android-Geräten. Tausende 1-Stern-Reviews in Stunden.
- **Banking Apps:** Regelmäßig brechen Authentifizierungs-Flows nach Updates, mit Code Push wäre das in Minuten gefixt.
- **E-Commerce Apps:** Black Friday ist der schlimmste Tag für einen Bug. Mit Rollbacks könntest du in Sekunden zurück.

### Meine eigene Erfahrung

Bei einem Kunden-Projekt hatten wir mal einen Patch gepusht, der auf 5% der Geräte (bestimmte Android-Versionen) einen White Screen verursachte.

**Ohne Shorebird:** Hotfix bauen → App Store Review abwarten → User bitten, zu updaten → 3-5 Tage Downtime für diese User.

**Mit Shorebird:** Track gewechselt → 30 Sekunden später waren alle wieder auf der funktionierenden Version.

## Best Practices für sichere Deployments

### 1. Staging immer nutzen

Niemals direkt auf `stable` pushen:

```bash
# NICHT so
shorebird patch android

# BESSER
shorebird patch android --track=staging
# Testen...
shorebird patches set-track --track stable
```

### 2. Percentage-Based Rollouts implementieren

Roll deine Patches schrittweise aus: 5% → 25% → 50% → 100%

### 3. Crash Monitoring einrichten

Verbinde Crashlytics/Sentry mit deinem Deployment:

```dart
void main() async {
  await SentryFlutter.init((options) {
    options.dsn = 'YOUR_DSN';
  });
  
  // Patch-Version in Sentry-Context setzen
  final patch = await ShorebirdUpdater().readCurrentPatch();
  Sentry.configureScope((scope) {
    scope.setTag('shorebird_patch', patch?.number.toString() ?? 'none');
  });
  
  runApp(MyApp());
}
```

### 4. Patch Signing aktivieren

Für maximale Sicherheit, nur signierte Patches werden akzeptiert:

```bash
# Schlüsselpaar generieren
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem

# Release mit Public Key erstellen
shorebird release android --public-key-path public.pem

# Patches müssen jetzt signiert sein
shorebird patch android --private-key-path private.pem --public-key-path public.pem
```

### 5. Feature Flags kombinieren

Code Push + Feature Flags = maximale Kontrolle:

```dart
// Feature Flag Check
if (await featureFlags.isEnabled('new_checkout_flow')) {
  return NewCheckoutScreen();
} else {
  return OldCheckoutScreen();
}
```

So kannst du Features auch ohne neuen Patch deaktivieren.

## Store Compliance: Ist das überhaupt erlaubt?

**Kurze Antwort: Ja.**

### Google Play Store

> An app may not download executable code from a source other than Google Play. *This restriction does not apply to code that runs in a virtual machine or an interpreter.*

Shorebird nutzt die Dart VM, vollständig compliant.

### Apple App Store

> Interpreted code may be downloaded to an Application but only so long as such code does not change the primary purpose of the Application.

Solange du keine "major features" pushst, die den App-Zweck ändern, bist du safe.

**Wichtig:** Code Push ist Standard in der Industrie. React Native nutzt es seit Jahren (Microsoft CodePush, Expo). Alle großen Apps (Facebook, Airbnb, Lyft) setzen auf ähnliche Technologien.

## Preismodell: Was kostet Shorebird?

- **Hobby (Free):** 5.000 Patch Installs/Monat
- **Team ($20/Monat):** 50.000 Patch Installs
- **Business ($500/Monat):** Unlimited Installs + Priority Support

Für die meisten Side Projects reicht der Free Tier. Für Production Apps ist $20/Monat ein No-Brainer, das sind die [laufenden Kosten](/blog/laufende-app-kosten), die sich definitiv rechnen.

## Fazit: Kein Production Deployment ohne Rollback-Strategie

Patch Rollbacks sind kein Nice-to-have, sie sind **Pflicht für jede Production App**.

Mit Shorebird hast du:

- Sofortige Updates ohne App Store Wartezeit
- Ein-Klick Rollbacks bei Problemen
- Staging Tracks für sicheres Testen
- Graduelle Rollouts für Risikominimierung
- Patch Signing für Enterprise-Security

Der Freitagabend-Albtraum vom Anfang? Mit Shorebird wäre das ein 30-Sekunden-Fix gewesen statt eines Wochenend-Disasters.

**Mein Rat:** Integriere Code Push von Anfang an. Nicht erst, wenn du es brauchst, dann ist es zu spät.

Wenn du generell noch am Anfang deiner App-Entwicklung stehst, schau dir meinen Artikel zur [App-Idee Validierung](/blog/app-idee-validieren) an. Und wenn du verstehen willst, wie das Backend dahinter funktioniert, findest du alle Infos in meinem [Backend-Guide](/blog/so-funktioniert-das-backend-meiner-production-app).