Mobile-App-Backend, APIs und Offline-Sync: eine Architektur für Apps, die zuverlässig funktionieren

Dieser Leitfaden richtet sich an CTOs, technische Leads und Product Owner, die die Serverseite einer App planen. Unser Leitfaden zur mobilen Produktentwicklung gibt einen Überblick über den gesamten Weg von der Konzeption bis zur Skalierung; diese Seite geht tiefer auf das Backend, den API-Vertrag und die Offline-Synchronisierung ein. Wie die App selbst gebaut wird, vergleicht Native vs. Cross-Platform Mobile Development.

In diesem Leitfaden

• Was muss ein mobiles Backend leisten, das eine Website nicht muss?
• Der API-Vertrag für mobile Clients
• Offline-Synchronisierung: vier Modelle
• Konflikte und wer entscheidet
• Anmeldung, Push und Gerätesicherheit
• Backend-Routen: Alternativen und Auswahlkriterien
• KI-Funktionen und das Backend
• Ein Bauplan
• Wie Netbase mobile Backends baut
• Welcher Liefernachweis existiert – und welcher nicht?
• Was sind die Grenzen dieses Leitfadens?
• Häufig gestellte Fragen
• Nächster Schritt

Was muss ein mobiles Backend leisten, das eine Website nicht muss?

Eine Website ändert sich für jeden Besucher im Moment der Bereitstellung. Eine mobile App nicht: Nutzer aktualisieren, wann sie möchten, und manche tun es nie. Drei Konsequenzen prägen das Backend.

• Viele Client-Versionen gleichzeitig. Der Server muss jede noch unterstützte App-Version bedienen; ein umbenanntes Feld oder ein neuer Pflichtparameter kann tausende installierter Apps über Nacht unbrauchbar machen.
• Netzwerke, die auf halbem Weg versagen. Eine Anfrage kann den Server erreichen und die Antwort auf dem Rückweg verlieren. Die App wiederholt die Anfrage, und ein unachtsames Backend erzeugt eine zweite Bestellung oder eine zweite Zahlung.
• Arbeit, die abseits des Servers stattfindet. Außendienstmitarbeiter, Reisende und Kunden in Tiefgaragen öffnen die App ohne Signal und erwarten, dass sie funktioniert – und dass ihre Änderungen später ankommen, ohne die Daten anderer zu überschreiben.

Der API-Vertrag für mobile Clients

Behandeln Sie die API als eigenständiges Produkt mit eigenen Regeln, nicht als Nebenprodukt des Web-Frontends.

• Bewusst versionieren. Felder können frei hinzugefügt werden, dürfen aber nicht entfernt oder umbenannt werden, solange eine unterstützte App-Version sie liest. Bruchänderungen kommen hinter eine neue Version; veröffentlichen Sie eine Mindest-App-Version und lassen Sie das Backend ältere Apps zur Aktualisierung auffordern.
• Antworten für den Bildschirm formen. Eine Backend-for-Frontend-Schicht – ein schlanker Dienst, der genau das zusammenstellt, was ein Bildschirm benötigt – spart Roundtrips in langsamen Netzwerken und hält interne Systeme aus dem Blickfeld der App.
• Mit Cursors paginieren. Paginieren Sie Listen mit einem Cursor statt einem Offset, damit Einträge, die während des Scrollens hinzugefügt werden, nicht doppelt angezeigt oder übersprungen werden.
• Erstellungen sicher wiederholbar machen. RFC 9110 definiert POST als nicht idempotent; daher trägt jeder Erstellvorgang einen auf dem Gerät generierten Idempotenzschlüssel. Der Server speichert ihn mit dem Ergebnis und gibt bei einer Wiederholung das erste Ergebnis zurück.
• Nur senden, was das Gerät braucht. Bilder gerätespezifisch skalieren, Antworten komprimieren und nur geänderte Datensätze seit dem letzten Sync-Marker der App übertragen.
• Fehler zurückgeben, auf die die App reagieren kann. Ein stabiler Fehlercode teilt der App mit, ob sie es erneut versuchen, sich neu authentifizieren oder abbrechen soll.

Wenn dasselbe Backend auch die Website, Partner und interne Systeme bedient, finden sich die Regeln für diese Abläufe in unserem Leitfaden zur Enterprise-Systemintegration.

Offline-Synchronisierung: vier Modelle

Wählen Sie ein Modell je Datenart: Ein Katalog, ein Entwurfsformular und eine Zahlung benötigen unterschiedliche Garantien.

• Nur online, mit Lesecache. Die App zeigt die zuletzt abgerufenen Daten und blockiert Änderungen im Offline-Modus. Geeignet für Preise, Lagerbestände und alles, was aktuell sein muss.
• Schreibwarteschlange. Änderungen werden in einer ausgehenden Warteschlange gespeichert und der Reihe nach gesendet, wenn die Verbindung zurückkommt. Androids Offline-First-Leitfaden nennt dieses Muster für Daten wie Analyse-Events und Logs.
• Local-First-Daten. Die App liest und schreibt eine lokale Datenbank, und ein Synchronisierungsprozess tauscht Änderungen mit dem Server aus. Androids Leitfaden bezeichnet die lokale Quelle als die massgebliche Quelle der Wahrheit fuer die App; dies eignet sich für Notizen, Inspektionen und Felddaten.
• Ein verwalteter Synchronisierungsdienst. Eine Plattform hält eine lokale Datenbank und die Serverkopie synchron und liefert Konfliktbehandlung – zum Preis der Übernahme ihres Datenmodells.

Die Synchronisierung selbst läuft entweder auf Anfrage (Pull) oder mit Server-Benachrichtigung der App bei Änderungen (Push); Androids Leitfaden empfiehlt Pull für kurze Offline-Phasen und Push für lange Offline-Perioden und zusammenhängende Daten.

Konflikte und wer entscheidet

Wenn zwei Personen denselben Datensatz ändern, während eine von ihnen offline ist, muss eine Seite gewinnen. Legen Sie es feldweise schriftlich fest – vor dem ersten Build.

• Last Write Wins. Jede Änderung trägt einen Zeitstempel; die neuere wird behalten. Einfach und richtig für Daten, die einer Person gehören, wie ein Profil oder ein Entwurf.
• Server entscheidet. Das Backend akzeptiert eine Änderung nur, wenn der Datensatz noch dieselbe Version hat, die das Gerät gesehen hat; andernfalls zeigt die App den aktuellen Stand und fragt den Nutzer.
• Zusammenführung nach Feld. Änderungen an verschiedenen Feldern bleiben beide erhalten; nur ein Konflikt im selben Feld erfordert eine Regel.
• Niemals offline. Zahlungen, Lagerreservierungen und Genehmigungen werden vom Server bestätigt, solange eine Verbindung besteht – unabhängig davon, was der Rest der App tut.

Führen Sie ein Server-Sync-Protokoll mit Gerät, Nutzer, Version und Ergebnis, damit der Support erklären kann, was mit einem Datensatz geschehen ist.

Anmeldung, Push und Gerätesicherheit

Anmeldung. Eine mobile App kann kein Geheimnis bewahren: IETF RFC 8252 klassifiziert native Apps als öffentliche Clients und verlangt die PKCE-Erweiterung für OAuth, wobei die Anmeldeseite im System-Browser statt in einer eingebetteten Web-View geöffnet wird. Verwenden Sie kurzlebige Access-Token mit Refresh-Token im sicheren Speicher der Plattform und bieten Sie zusätzlich biometrische Entsperrung an.

Push. Firebase Cloud Messaging bezeichnet sich selbst als plattformübergreifende Messaging-Lösung, mit Benachrichtigungsnachrichten, die das System anzeigt, und Datennachrichten, die die App selbst verarbeitet. Senden Sie Datennachrichten, um die App zur Synchronisierung aufzufordern, Benachrichtigungen für das, was der Nutzer sehen muss, und fragen Sie zu einem Zeitpunkt um Erlaubnis, den der Nutzer versteht.

Sicherheit. Der OWASP Mobile Application Security Verification Standard gruppiert die Kontrollen für Speicherung, Kryptografie, Authentifizierung, Netzwerkkommunikation und Resilienz. Auf dem Server prüft jeder Endpunkt die Rechte des Nutzers selbst, unabhängig davon, was die App anzeigt oder verbirgt.

Backend-Routen: Alternativen und Auswahlkriterien

Vier Kriterien entscheiden: Wer besitzt die Daten heute? Wie viel des Produkts funktioniert offline? Mit wie vielen Systemen muss die App kommunizieren? Und wer betreibt das Backend nachts? Wenn das Backend auch mit einem Shop, einem ERP und einem CRM kommunizieren muss, gestalten Sie diese Abläufe zuerst mit ERP-, CRM- und E-Commerce-Integrationsarchitektur; Netbase's Systems- und API-Integrationsdienst baut diese Schicht.

Wie Netbase mobile Backends baut

Netbase baut Cross-Platform-Apps mit React Native – eine Rolle, für die das Unternehmen seit Langem einstellt – auf dem Stack, der auf unserer Seite Backend-Plattformen beschrieben ist. Teams von 3 bis 30 Personen vereinen Analysten, Architekten, Entwickler, QA und Designer; der Arbeitsbeginn liegt typischerweise 1 bis 2 Wochen nach der Discovery. Die meisten Netbase-Projekte werden auf Festpreisbasis abgewickelt, die nach der Discovery vereinbart wird (siehe dediziertes Team vs. Festpreis); bei der individuellen Entwicklung verbleiben die IP-Rechte beim Auftraggeber. Die Sicherheitspraxis umfasst Secure-Code-Reviews, TLS in der Übertragung und AES im Ruhezustand, rollenbasierte Zugriffskontrolle und MFA für Admin-Dashboards. Siehe den Mobile-App-Entwicklungsdienst oder den Mobile Product Accelerator, wenn wiederverwendbare Bausteine passen.

Welcher Liefernachweis existiert – und welcher nicht?

• Was existiert. Der RB-Marketplace-Datensatz beschreibt eine Kunden-Shopping-App, die nach einem API-Audit auf der eigenen Marktplatz-API aufgebaut wurde, mit Push-Benachrichtigungen, einer serverseitig synchronisierten Wunschliste und Offline-Browsing – für Android, mit iOS im erweiterten Scope. Der Dey-Page-Datensatz beschreibt eine React-Native-App für iOS und Android auf demselben Backend wie das Web-Verzeichnis, mit Telefon-OTP-Konten, Push und Deep Links; die Felderfassung mit Offline-Sync läuft in der mobilen Web-App. Der Reward-Shop-Datensatz beschreibt mobile UI-Komponenten für die eigenen Apps des Kunden und die Synchronisierung mit dessen Systemen über Webhooks und einen geplanten Sync; der Kunde wird nicht genannt.
• Was nicht existiert. Keiner dieser Datensätze veröffentlicht Downloads, Nutzungszahlen, Verfügbarkeit, Sync-Volumina oder Fehlerquoten, und der RB-Marketplace-Datensatz nennt kein Framework. Keiner wird als Beweis angeboten, dass ein Sync-Modell oder eine Backend-Route besser abschneidet.

Was sind die Grenzen dieses Leitfadens?

• Plattformaussagen stammen von den Android-, IETF-, Firebase- und OWASP-Seiten zum Zugriffsdatum; Plattformen ändern sich, prüfen Sie daher die aktuellen Versionen.
• Die Sync-Modelle eignen sich für Business-, Commerce- und Feld-Apps; Echtzeit-Kollaboration und Spiele erfordern ein eigenes Design.
• Sicherheitspraktiken reduzieren Risiken; sie sind keine Garantie für eine App oder ein Backend.

Nächster Schritt

Teilen Sie uns mit, welche Daten Ihre App offline vorhalten muss, aus welchen Systemen sie liest und welche App-Versionen bereits im Einsatz sind – wir vereinbaren dann ein Solution-Review, um den API-Vertrag und ein Sync-Modell je Datentyp zu erarbeiten. Sie können auch den Mobile-App-Entwicklungsdienst oder weitere Netbase Insights ansehen.

Verwandte Leistungen und Lösungen