---
term: 'Plattformübergreifende Entwicklung'
seoTitle: 'Plattformübergreifende Entwicklung: Frameworks und Backend'
headline: 'Was ist plattformübergreifende Entwicklung?'
slug: plattformuebergreifende-entwicklung
category: frontend-web
shortDefinition: 'Plattformübergreifende Entwicklung ist ein Ansatz, eine App aus einer geteilten Codebasis zu bauen, die auf iOS, Android, Web und Desktop läuft.'
relatedTerms:
  - backend-sdk
  - progressive-web-app-pwa
  - baas-vs-custom-backend
  - api
contrastsWith:
  - progressive-web-app-pwa
aboutTerms:
  - 'Native vs. Cross-Platform'
  - 'Compiled vs. Bridge vs. WebView'
  - 'Shared Backend'
faq:
  - question: 'Was ist plattformübergreifende Entwicklung?'
    answer: 'Eine Anwendung aus einer geteilten Codebasis zu bauen, die auf mehreren Plattformen läuft – iOS, Android und zunehmend Web und Desktop –, statt für jede getrennten Code zu schreiben. Der leitende Slogan lautet "write once, run anywhere" (einmal schreiben, überall ausführen), mit der Fußnote des Realisten: "write once, debug everywhere".'
  - question: 'Was ist der Unterschied zwischen plattformübergreifend und nativ?'
    answer: 'Nativ zielt auf ein Betriebssystem mit dessen eigener Sprache und Werkzeugen – Swift für iOS, Kotlin für Android – und erreicht damit Spitzenleistung und den tiefsten Gerätezugriff. Plattformübergreifend nutzt eine Codebasis über Betriebssysteme hinweg wieder, für geringere Kosten und schnellere Auslieferung, und gibt dafür etwas Performance und die sofortige Verfügbarkeit neuer OS-Funktionen auf.'
  - question: 'Welches sind die wichtigsten plattformübergreifenden Frameworks?'
    answer: 'Zwei führen das Feld an: ein JavaScript-Framework, das über eine Bridge echte native UI-Komponenten rendert, und eines, das eine eigene Rendering-Engine mitbringt und zu nativem Code kompiliert. Andere teilen die Geschäftslogik und behalten die native Oberfläche, oder sie verpacken eine Web-App in einen nativen Container. Sie unterscheiden sich vor allem darin, wie sie den Bildschirm zeichnen.'
  - question: 'Was ist der Unterschied zwischen hybrid und plattformübergreifend?'
    answer: 'Plattformübergreifende Frameworks kompilieren zu nativem Code oder rendern native Komponenten; hybride Apps führen eine Web-App in einer nativen Web-View-Hülle aus. Hybrid ist der schnellste Weg für Web-Teams und die schwächste Leistung; plattformübergreifend liegt zwischen hybrid und vollständig nativ. Manche Einteilungen behandeln hybrid als Unterform des Plattformübergreifenden.'
  - question: 'Ist plattformübergreifend so schnell wie nativ?'
    answer: 'Moderne Frameworks erreichen grob 90–95 % der nativen Leistung, was für die meisten Apps reichlich ist. Nativ gewinnt weiterhin bei grafikintensiven Spielen, AR und VR sowie schwerer Echtzeitverarbeitung, wo die letzten Prozente und der direkte Hardware-Zugriff zählen.'
  - question: 'Wie viel Code lässt sich wiederverwenden, und wie viel spart das?'
    answer: 'Im Frontend üblicherweise rund 90 %, je nach Framework und dem Anteil plattformspezifischer Oberfläche oder Logik. Branchenberichte nennen etwa 30–40 % geringere Kosten und eine 30–40 % schnellere Auslieferung gegenüber getrennten nativen Apps. Der größere und verlässlichere Gewinn an Wiederverwendung ist aber das Backend – es wird zu 100 % von allen Clients geteilt, nativen wie plattformübergreifenden.'
  - question: 'Wann sollten Sie plattformübergreifend statt nativ wählen?'
    answer: 'Plattformübergreifend bei knappen Budgets und Zeitplänen, für MVPs, klassische Geschäfts- und Content-Apps sowie gleichzeitige Starts auf mehreren Plattformen. Nativ für performancekritische, hardwarenahe oder als Aushängeschild einer Plattform gedachte Apps. In beiden Fällen ist das Backend geteilt – die Entscheidung betrifft also in Wahrheit das Frontend.'
  - question: 'Geht es bei plattformübergreifender Entwicklung nur um das Frontend?'
    answer: 'Nein – und genau das übersehen die meisten Leitfäden. Die Wahl des Frontend-Frameworks ist ein Trade-off zwischen Bedienerlebnis und Leistung, aber der größte Gewinn an Wiederverwendung ist ein geteiltes Backend: eine API, die iOS, Android, Web und Desktop bedient. Selbst zwei vollständig native Apps sind auf der Backend-Ebene plattformübergreifend, wenn sie es teilen.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Write once, run anywhere — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Write_once,_run_anywhere'
  - name: 'Cross-platform software — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Cross-platform_software'
  - name: 'React Native — open-source framework'
    url: 'https://reactnative.dev/'
  - name: 'Stack Overflow Developer Survey'
    url: 'https://survey.stackoverflow.co/'
cta:
  title: 'Schreiben Sie das Backend einmal'
  text: 'Back4app liefert SDKs für Flutter, React Native, iOS, Android und JavaScript über eine API – welches Frontend die einzelne Plattform auch nutzt, Daten, Authentifizierung und Regeln werden einmal geschrieben.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-28'
translationKey: cross-platform-development
---

**Plattformübergreifende Entwicklung ist ein Ansatz, eine App aus einer geteilten Codebasis zu bauen, die auf iOS, Android, Web und Desktop läuft.** Der Slogan lautet "write once, run anywhere"; die Realität ergänzt "write once, debug everywhere". Die gesamte Diskussion darüber behandelt das Thema quer durch alle einschlägigen Leitfäden als *Frontend*-Frage – welches UI-Framework es sein soll. Dieser Eintrag ergänzt den Teil, den sie alle auslassen: **Der größte und verlässlichste Gewinn an Code-Wiederverwendung ist nicht die Oberfläche, sondern ein geteiltes Backend** – und dieser Gewinn steht selbst vollständig nativen Apps offen.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Die Idee | Eine Codebasis → mehrere Plattformen, statt einer je Betriebssystem |
| Die Frontend-Ansätze | Kompiliert (eigener Renderer) · Native Bridge · Web-View-Hülle |
| vs. nativ | Reichweite + Tempo + geteilter Code ↔ Spitzenleistung + native Bedienung |
| Der unausgesprochene Gewinn | Das **Backend wird zu 100 % geteilt** – nativ oder plattformübergreifend |
| Der Mechanismus | [SDKs](/glossary/de/backend-sdk/) + eine REST-/GraphQL-[API](/glossary/de/api/), die jeder Client spricht |

## Dasselbe Backend, jedes Frontend

**JavaScript:**

```javascript
// JavaScript / React Native / web — Back4app JS SDK
// The SAME backend call, whatever the frontend framework
const query = new Parse.Query('Task');
query.equalTo('done', false);
const tasks = await query.find();
// This exact query runs from React Native, a web SPA, or Node —
// because the backend is written ONCE and every client shares it.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Same data, same auth, same rules — a different frontend framework
final tasks = await QueryBuilder<ParseObject>(ParseObject('Task'))
    .whereEqualTo('done', false)
    .query();
// The Flutter app and the native iOS app can differ entirely on the frontend
// and still share ONE backend — the cross-platform win nobody talks about.
```

**Swift:**

```swift
// iOS / Swift (native) — Back4app Swift SDK
// A fully NATIVE iOS app — still cross-platform at the backend layer
let tasks = try await Task_.query("done" == false).find()
// Native iOS + native Android + web can each pick their own UI stack
// and share the identical backend API — write the backend once.
```

**Kotlin:**

```kotlin
// Android / Kotlin (native) — Back4app Android SDK
// A fully NATIVE Android app — still cross-platform at the backend layer
val tasks = ParseQuery.getQuery<ParseObject>("Task")
    .whereEqualTo("done", false)
    .find()
// Native iOS + native Android + web can each pick their own UI stack
// and share the identical backend API — write the backend once.
```

Vier verschiedene Frontends – eine JS-Web-App, Flutter, natives Swift, natives Kotlin – und eine Abfrage, weil alle mit demselben Backend sprechen. Das ist die Architektur, die in den Suchergebnissen nie auftaucht: **plattformübergreifendes Frontend (oder sogar native Frontends) + ein einziges geteiltes Backend.** Die Wahl des Frontend-Frameworks ist eine echte Entscheidung mit echten Trade-offs; die Wiederverwendung des Backends ist nahezu kostenlos und nahezu universell.

## Die drei Frontend-Ansätze

| Ansatz | Wie er die Oberfläche zeichnet | Abwägung |
| --- | --- | --- |
| Kompiliert / eigener Renderer | Bringt eine eigene Engine mit, kompiliert zu nativem Code | Spitzenleistung, pixelgleiche Oberfläche auf allen Plattformen |
| Native Bridge | Rendert *echte* native Komponenten über eine Bridge | Natives Erscheinungsbild je Plattform, JS-Ökosystem |
| Web View / hybrid | Eine Web-App in einem nativen Container | Am schnellsten für Web-Teams, schwächste Leistung und Bedienung |

Die Einteilung, die die meisten Leitfäden verwischen: Ein **kompiliertes** Framework zeichnet jeden Pixel selbst (überall einheitlich, nativ schnell); ein Framework mit **Native Bridge** lässt das Betriebssystem seine eigenen Widgets zeichnen (wirkt je Plattform nativ); eine **Web-View-/Hybrid-App** rendert HTML in einer Hülle (eine Website im App-Kostüm). "Plattformübergreifend" meint meist die ersten beiden, "hybrid" die dritte – und der Unterschied besteht genau darin, ob echter nativer Code läuft oder eine Browser-Engine.

```mermaid
flowchart LR
  accTitle: Plattformübergreifende Frontends über einem geteilten Backend
  accDescr: Mehrere Frontends — eine kompilierte plattformübergreifende App, eine App mit Native Bridge, native iOS- und Android-Apps sowie eine Web-App — laufen jeweils auf ihrer eigenen Plattform, sprechen aber alle mit einer einzigen geteilten Backend-API, die Daten, Authentifizierung und Geschäftslogik bereitstellt. Die Wahl des Frontend-Frameworks ist unabhängig vom geteilten Backend.
  F1["Plattformübergreifende App<br/>(kompiliert / Bridge)"] --> API[("Geteilte Backend-API<br/>Daten · Auth · Logik")]
  F2["Natives iOS"] --> API
  F3["Natives Android"] --> API
  F4["Web / PWA"] --> API
  API -.->|"SDKs je Plattform"| SDK["Ein Backend,<br/>einmal geschrieben"]
```

## Nativ vs. plattformübergreifend, ehrlich betrachtet

| | Plattformübergreifendes Frontend | Natives Frontend |
| --- | --- | --- |
| Codebasis | Eine, ~90 % geteilt | Eine je Betriebssystem |
| Zeit und Kosten | ~30–40 % weniger | Basis ×2 für zwei Plattformen |
| Performance | ~90–95 % von nativ | 100 % |
| Treue der Bedienung | Sehr gut; Randfälle schlagen durch | Plattformgenau |
| Neue OS-Funktionen | Auf Framework-Unterstützung warten | Sofort |
| Passend für | Klassische Apps, MVPs, Reichweite | Grafik, AR, tiefer Hardware-Zugriff |
| **Das Backend** | **Geteilt** | **Geteilt** |

Die letzte Zeile ist der ganze Punkt dieses Artikels. Die Frontend-Wahl ist ein echter Trade-off zwischen Bedienerlebnis und Leistung, den Sie bewusst treffen sollten – aber *welche Seite* Sie auch wählen, das Backend wird einmal geschrieben und von allen Clients geteilt. Damit ist die schwierigste und wertvollste Wiederverwendung in der plattformübergreifenden Entwicklung genau die, die niemand als plattformübergreifend bezeichnet.

## Wie das Backend plattformübergreifend wird: SDKs und eine API

Der Mechanismus hat zwei Schichten. Ein Backend stellt eine **plattformneutrale [API](/glossary/de/api/)** bereit – [REST und GraphQL](/glossary/de/rest-api/) sprechen JSON mit allem – und darüber liegen **[plattformspezifische SDKs](/glossary/de/backend-sdk/)**, die die API in die Idiome der jeweiligen Sprache kleiden: ein Swift-SDK für iOS, Kotlin für Android, JavaScript für Web und React Native, Dart für Flutter. Jedes SDK ist ein dünner Client über denselben Endpoints, also leben *Datenmodell, Authentifizierung, Berechtigungen und Geschäftslogik* einmal auf dem Server, und jedes Frontend erbt sie. Deshalb ist ein [BaaS](/glossary/de/baas-vs-eigenes-backend/) das natürliche Backend für plattformübergreifende Arbeit: Es *ist* das geteilte Backend, mit bereits geschriebenen SDKs. Eine [PWA](/glossary/de/pwa/) ist schlicht ein weiterer plattformübergreifender Auslieferungsweg – eine Web-App, die sich auf allen Plattformen installieren lässt – und spricht mit demselben Backend.

## Typische Anwendungsfälle

- **Start-ups und MVPs** – iOS und Android mit einem Team und einem Zeitplan abdecken.
- **Content- und Geschäfts-Apps** – klassische Oberflächen, bei denen 90 % wiederverwendeter Code reine Ersparnis sind.
- **Produktfamilien über mehrere Plattformen** – Mobil-, Web- und Desktop-Clients über einem Backend.
- **Native Apps, die dennoch ein Backend teilen** – Frontends mit Spitzenleistung, eine API dahinter.
- **[PWA](/glossary/de/pwa/) plus nativ** – Reichweite im Web und Tiefe im Nativen, dasselbe [Backend](/glossary/de/baas-vs-eigenes-backend/).

## Sollten Sie plattformübergreifend arbeiten? Entscheidungsmatrix

| Situation | Tendenz |
| --- | --- |
| Budget/Zeitplan knapp, klassische App | Plattformübergreifendes Frontend |
| iOS und Android starten gemeinsam | Plattformübergreifendes Frontend |
| Grafik, AR, tiefer Hardware-Zugriff | Natives Frontend |
| Aushängeschild einer Plattform oder Spitzenleistung | Natives Frontend |
| Jeder der Fälle oben | **Geteiltes Backend** – immer |
| Web-Reichweite mit kleinem Budget | [PWA](/glossary/de/pwa/) über dem geteilten Backend |

## Grenzen und Trade-offs

- **Frontend-Frameworks hinken hinterher.** Neue OS-Funktionen kommen zuerst nativ, plattformübergreifende Frameworks ziehen nach – ein echter Preis für Apps, die sie am ersten Tag übernehmen müssen.
- **Die letzten Prozente an Leistung.** Grafiklastige und echtzeitnahe Apps spüren den Abstand zu nativ; die meisten Apps nie.
- **Bedienkonventionen schlagen durch.** Plattformspezifische Gesten und Muster brauchen Aufmerksamkeit je Plattform, selbst in "geteiltem" Oberflächencode.
- **App-Größe und Abhängigkeiten.** Plattformübergreifende Runtimes bringen Gewicht mit und eine von einer Community gepflegte Abhängigkeit, die Sie nicht in der Hand haben.
- **Nichts davon berührt das Backend.** Jede Grenze oben ist eine *Frontend*-Grenze; der Gewinn des geteilten Backends bleibt unberührt, und genau deshalb ist er die sichere Wette in einer unsicheren Frontend-Entscheidung.

## Plattformübergreifende Entwicklung mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie ist die Hälfte "geteiltes Backend" dieses Artikels, wörtlich genommen: Back4app liefert [SDKs](/glossary/de/backend-sdk/) für Flutter, React Native, iOS (Swift), Android (Kotlin) und JavaScript über eine REST-/GraphQL-[API](/glossary/de/api/). So bedienen – wie die Code-Tabs zeigen – dieselbe Abfrage, dieselbe [Authentifizierung](/glossary/de/authentifizierung-vs-autorisierung/) und dieselben [ACL-Regeln](/glossary/de/zugriffskontrolllisten-acl/) jeden Client, ob das Frontend nun eine einzige plattformübergreifende Codebasis ist oder vier getrennte native Codebasen sind. Die Frontend-Entscheidung bleibt Ihre, getroffen nach Bedienerlebnis und Leistung; das Backend wird ohnehin einmal geschrieben – der plattformübergreifende Gewinn, der am meisten wert ist und am wenigsten besprochen wird.