Warum die Anfragen nativ laufen
Die verwendeten Bahn-Hosts erlauben keine Browser-Anfragen aus einer fremden Website. Zusätzlich blockiert DB mehrere typische Skript-Laufzeiten anhand ihres TLS-Fingerabdrucks. Ein gewöhnlicher Web-Client scheitert deshalb bereits vor der Auswertung der Antwort.
In der installierten App leitet Capacitor den normalen fetch-Aufruf an URLSession auf iOS oder OkHttp auf Android weiter. Diese nativen Netzwerkstapel senden die Anfrage direkt an DB oder Flix. Dazwischen steht kein Bahnsparer-Proxy.
Nur die lokale Entwicklungsumgebung besitzt einen Relay: Vite übergibt erlaubte Testanfragen an curl. Dieser Pfad gehört nicht zum Produktions-Bundle und kann keine Anfrage einer installierten App verarbeiten.
WebView und Hintergrundprozess teilen sich die Arbeit
WebView
Sie führt Suchen aus, filtert Verbindungen, wertet Zuverlässigkeit aus und speichert Preisverläufe. Beim Start und nach der Rückkehr in die App liest sie den aktuellen Stand des Hintergrundprozesses ein.
Background Runner
Er erfasst zuerst laufende Fahrten und prüft danach einen rotierenden Ausschnitt der beobachteten Reisetage. So bleibt das Anfragebudget begrenzt. iOS und Android entscheiden, wann ein Lauf stattfinden darf; die App verspricht deshalb kein Intervall.
Der Runner speichert neue Tiefstpreise und aufgezeichnete Ankünfte. Lokale Hinweise zu Preisen oder vorbereiteten Fahrgastrechten entstehen direkt auf dem Gerät. Weder Push-Anbieter noch ein Bahnsparer-Server kennen diese Daten.
Welche Daten in welchem Speicher liegen
- Speicher
- WebView-Speicher
- Inhalt
- Einstellungen, Routen, Fahrten und Preisverläufe
- Grenze
- Lokal mit lesbarer Sicherungs- und Wiederherstellungskopie
- Speicher
- CapacitorKV
- Inhalt
- Preisalarme, Fahrten, Beobachtungen und Runner-Fortschritt
- Grenze
- Für WebView und Background Runner, nicht für iCloud
- Speicher
- Keychain oder Keystore
- Inhalt
- Optionaler DB-Aktualisierungsschlüssel
- Grenze
- Native sichere Ablage, nie im App-Datensatz
- Speicher
- Private CloudKit-Datenbank
- Inhalt
- Preisalarme, Fahrten, Routen und Sucheinstellungen
- Grenze
- Nur nach Aktivierung, im privaten iCloud-Konto
| Speicher | Inhalt | Grenze |
|---|---|---|
| WebView-Speicher | Einstellungen, Routen, Fahrten und Preisverläufe | Lokal mit lesbarer Sicherungs- und Wiederherstellungskopie |
| CapacitorKV | Preisalarme, Fahrten, Beobachtungen und Runner-Fortschritt | Für WebView und Background Runner, nicht für iCloud |
| Keychain oder Keystore | Optionaler DB-Aktualisierungsschlüssel | Native sichere Ablage, nie im App-Datensatz |
| Private CloudKit-Datenbank | Preisalarme, Fahrten, Routen und Sucheinstellungen | Nur nach Aktivierung, im privaten iCloud-Konto |
Preisverläufe, Benachrichtigungsstatus und DB-Anmeldedaten werden nicht über iCloud abgeglichen. Die private CloudKit-Datenbank zieht Änderungen zuerst vom Server, führt Datensätze über stabile IDs und Zeitstempel zusammen und überträgt danach lokale Änderungen.
Was bei einem Fehler weiter funktioniert
Jede Schnittstelle hat einen eigenen Client. Fällt etwa die Wagenreihung aus, bleiben Preissuche und Zuglauf nutzbar. Fehlende Live-Daten werden nicht als pünktlich oder leer ausgegeben.
Gespeicherte Routen, bisherige Preisbeobachtungen und das Zuverlässigkeitsmodell liegen weiterhin auf dem Gerät. Eine ausgefallene Netzabfrage löscht diesen Stand nicht.
Die genauen Hosts und Request-Pfade stehen unter Schnittstellen. Welche optionalen Daten das Gerät verlassen, erklärt die Datenschutzerklärung.