Flutter jenseits von Mobile — wie wir ein Full-Stack-Produkt zu 100 % in Dart gebaut haben

Am 24. April 2026 habe ich beim PeakIT 008 in Brașov einen Talk gehalten — zu einem Thema, das mich seit einigen Jahren beschäftigt: warum beschränken wir Flutter auf Mobile-Apps? Dieser Artikel ist die schriftliche Version derselben These, plus einige Details, die in einem 30-Minuten-Slot nicht Platz hatten.

Persönlicher Kontext — 16 Jahre Mobile

Ich begann 2010 iOS-Code zu schreiben, bevor iPads Retina-Bildschirme hatten. Wien (forfone, VoIP-App), dann Düsseldorf (Secusmart/BlackBerry, Mobile in Sicherheitsqualität), dann 2021 bin ich bei IDT Corporation eingestiegen, wo ich die Migration nativer Apps auf Flutter leite. Parallel bin ich seit 2023 CEO bei TAGonSoft, wo wir Flutter-Produkte end-to-end bauen — einschließlich table-online.ro, dem Multiplayer-Backgammon-Spiel, das ich im Talk als Case Study verwendet habe.

Ich erwähne das nicht zum Angeben, sondern um den Kontext zu setzen: ich bin nicht jemand, der auf Flutter umgestiegen ist, weil er kein Native konnte. Ich habe tiefen Respekt vor Native; ich habe Code ausgeliefert, der nicht kompromittierbar sein durfte. Genau das macht meinen Wechsel zu Flutter beachtenswert.

Die echten Kosten von „Native überall”

Native gibt einem Dinge, die man liebt: butterweiche Performance, Plattform-Fidelity, vollständigen OS-Zugriff. Die Kosten zeigen sich, sobald das Team wächst:

Zwei Teams, zwei Codebases, zwei Bug-Listen. Dasselbe Feature wird in iOS in 2 Wochen ausgeliefert, in Android in 4. Oder umgekehrt. Es gibt immer einen Abstand.
„Funktioniert auf iOS” ≠ „funktioniert auf Android” — jeder Production-Incident ist eine Zwei-Plattform-Untersuchung.
Hiring: Sie suchen zwei Spezialisten statt einen. Für ein kleines Team in Osteuropa ist das buchstäblich der Unterschied zwischen Ausliefern und Nicht-Ausliefern.
Wissens-Silos — der iOS-Entwickler kann bei einem Android-Bug nicht helfen, und umgekehrt.

Die Industrie hat versucht, das mehrfach zu lösen. PhoneGap/Cordova (Web in einem Wrapper). Xamarin (.NET überall, dann gekauft und eingestellt). React Native (JS über eine Bridge zu Native). Alle hatten architektonische Obergrenzen.

Was Flutter anders macht (und warum es jetzt zählt)

2017 erschien Flutter mit einer radikalen Entscheidung: es nutzt keine nativen Widgets, sondern malt seine eigenen Pixel. Klingt unbedeutend. Ist es nicht. Es bedeutet, dass Flutter nicht an eine Plattform gebunden ist — es kann überall rendern, wo es einen Pixel-Canvas gibt.

Drei direkte Folgen:

Eigene Rendering-Engine (Skia, jetzt Impeller) — nicht mehr an Plattform-Widgets gebunden, läuft also identisch auf iOS, Android, Web, Desktop und sogar auf Automotive-Embedded-Bildschirmen.
Compiliert zu nativem ARM — nicht interpretiert, nicht über eine Bridge. Performance ist real.
Eine Sprache — Dart — für Frontend, Backend, Spiele, CLIs, alles.

Diese drei Dinge zusammen erschließen Use Cases, die niemand erwartet hat, als Flutter als Mobile-Framework veröffentlicht wurde.

Der „Moment-Mal…”-Moment

Irgendwann 2022 ertappte ich mich beim Kleindenken. Wenn Flutter das Rendering besitzt und Dart überall kompiliert — warum bauen wir damit nur Mobile-Apps?

Also entschied ich, die Idee zu testen. Nicht mit einem Toy Project — mit einem echten Produkt, das unter Druck halten musste.

Case Study — Table Online, 100 % Dart

Table Online ist ein klassisches Echtzeit-Multiplayer-Backgammon-Spiel. Klingt einfach, erfordert aber: Matchmaking, Rating-System, Chat, serverseitige Regelvalidierung, Admin-Panel zur Moderation, IAP. Team: TAGonSoft, klein. Einschränkung: Auslieferung auf iOS, Android und Web, plus Backend und Admin.

Der traditionelle Ansatz wäre: Unity für das Spiel, Node.js/Go für das Backend, React für den Admin, Swift/Kotlin für die nativen Varianten. Vier Sprachen, vier CI/CD-Pipelines, vier Arten von Entwicklern.

Wir wählten: Flutter + Flame für das Spiel, Flutter Web für Web-Spieler, Flutter Web für das Admin-Panel, Serverpod für das Backend. Eine Sprache — Dart — überall.

┌──────────────────────────────────────────────────────┐
│                   DART / FLUTTER                     │
├─────────────────┬─────────────────┬──────────────────┤
│  🎮 Spiel       │  🌐 Web         │  📊 Admin        │
│  Flutter +      │  Flutter Web    │  Flutter Web     │
│  Flame Engine   │  (Spieler)      │  (Moderation)    │
├─────────────────┴─────────────────┴──────────────────┤
│               🔧 Serverpod (Dart)                    │
│          API · WebSockets · Auth · DB                │
├──────────────────────────────────────────────────────┤
│               PostgreSQL · Redis                     │
└──────────────────────────────────────────────────────┘

Flame — Game Engine auf Flutter

Flame ist die 2D-Game-Engine, die auf Flutter aufbaut. Sie ist kein Spielzeug — sie ist produktionsreif. Was sie besonders macht: sie läuft auf Flutter, sodass man reguläre Flutter-Widgets über das Spiel legen kann. In-Game-Chat? Reguläres Flutter-Widget. Pause-Menü? Reguläres Flutter. Hot Reload funktioniert im Spiel — Unity-Entwickler würden dafür zahlen.

class BackgammonBoard extends FlameGame
    with HasDraggables, HasTappables {

  @override
  Future<void> onLoad() async {
    final board = await Sprite.load('board.png');
    add(SpriteComponent(sprite: board, size: size));

    for (final piece in gameState.pieces) {
      add(GamePiece(piece));
    }
  }

  @override
  Widget build(BuildContext context) {
    return GameWidget(
      game: this,
      overlayBuilderMap: {
        'chat': (ctx, game) => ChatOverlay(),
        'menu': (ctx, game) => GameMenu(),
      },
    );
  }
}

Ein Flame-Spiel ist ein Flutter-Widget. Man kann es überall einbetten, man kann alles drüberlegen. Wer Flutter-Apps bauen kann, kann 2D-Spiele bauen.

Serverpod — Dart-Backend mit End-to-End-Typsicherheit

Serverpod macht den Stack wirklich stark. Modelle werden einmal definiert, und Serverpod generiert den Client. Ändern Sie ein Feld auf dem Server — der Client-Code kompiliert nicht mehr, bis Sie ihn aktualisieren. Der Compiler wird zum Integration-Test.

// Server-Endpoint (Dart)
class GameEndpoint extends Endpoint {
  Future<GameState> makeMove(
    Session session, int gameId, Move move,
  ) async {
    final game = await Game.db.findById(session, gameId);

    if (!game!.isValidMove(move))
      throw GameException('Invalid move');

    game.applyMove(move);
    await Game.db.updateRow(session, game);

    // Gegner per WebSocket benachrichtigen
    session.messages.postMessage(
      'game_$gameId', GameMoveMessage(move: move));

    return game.state;
  }
}

// Client-Call (gleiches Dart, gleiche Typen)
final newState = await client.game.makeMove(gameId, myMove);

JSON-Serialisierungsfehler verschwinden. „Client sendet int, Server erwartet string”-Fehler verschwinden. Das Team gewinnt Zeit, die es sonst beim Cross-Stack-Debugging verbrennen würde.

Was funktioniert hat

Ein Entwickler kann am gesamten Stack arbeiten. Es gibt kein „Du bist Mobile-Person” oder „Du bist Backend-Person”. Alle sind Dart-Personen.
Hot Reload für Spielentwicklung — Sub-Sekunde. In Unity würde man 30+ Sekunden warten.
~40 % geteilter Code über die vier Produkte. Backgammon-Regelvalidierung wird einmal geschrieben und identisch auf Client und Server verwendet.
Typsicherheit über den Stack hat Bugs zur Compile-Zeit gefangen, die sonst Production-Crashes geworden wären.
Ein kleines Team hat auf drei Plattformen in Monaten ausgeliefert, nicht Jahren.

Was schwer war (der ehrliche Teil)

Ich verkaufe Flutter nicht als Allheilmittel. Einige Dinge waren schwer:

Flutter-Web-Performance — besonders beim First Load. Es gibt echte Trade-offs zwischen Canvas- und HTML-Renderern.
Das Flame-Ökosystem ist kleiner als Unity oder Godot. Kein Problem für 2D-Spiele, aber für AAA-3D nutzt man etwas anderes.
Serverpod ist jung — weniger Stack-Overflow-Antworten. Man muss bereit sein, Source-Code zu lesen.
Manche pub.dev-Pakete unterstützen nicht alle Plattformen. Vor Abhängigkeiten prüfen.
Andere Entwickler davon zu überzeugen, dass Dart eine „echte” Backend-Sprache ist — mehr Kultur-Kampf als technisch.

Keines war ein Blocker. Es sind Trade-offs. Im Engineering hat man immer Trade-offs.

Was das für Ihr Team bedeutet

Wenn Sie Entwickler sind: lernen Sie Dart tief, nicht nur Flutter. Ihre Skills erstrecken sich über Mobile, Spiele, Backend, CLIs.

Wenn Sie Tech Lead sind: evaluieren Sie Flutter für Ihr nächstes Greenfield-Projekt. Starten Sie mit einem internen Tool oder Dashboard. Messen Sie die Team-Velocity.

Wenn Sie CTO oder Gründer sind: denken Sie Plattform-ROI, nicht nur Mobile-ROI. Ein Team, eine Sprache, schnellere Time-to-Market, niedrigere Gesamtkosten. In unserer Erfahrung liegt die Team-Größen-Reduktion bei gleichem Output zwischen 30 % und 50 % — keine Marketing-Zahl, sondern was wir in der Praxis beobachtet haben.

Wann Flutter die Antwort ist (und wann nicht)

Ja, wenn Sie ein Produkt haben, das mehrere Plattformen abdeckt, ein kleines bis mittleres Team, das Hebel braucht, ein 2D-Spiel / interaktives Erlebnis, interne Tools oder Dashboards, ein Startup, das Geschwindigkeit braucht.

Nicht (noch), wenn Sie eine SEO-lastige Content-Site haben, ein 3D-AAA-Spiel, sehr spezialisierte native Features oder ein Team, das tief in einen anderen Stack investiert ist.

Wenn Sie das Ergebnis direkt sehen möchten, öffnen Sie table-online.ro und spielen Sie eine Runde. Alles, was Sie dort anfassen — von der Würfel-Rotation bis zur Score-Anzeige nach einem gewonnenen Match — wurde von uns in Dart geschrieben, vom Pixel bis zum SQL-Query.

Möchten Sie ein Flutter-End-to-End-Projekt besprechen (Mobile + Web + Backend)? Schreiben Sie uns. Und wenn Sie nach der Aufnahme des PeakIT-Talks suchen, folgen Sie dem offiziellen PeakIT-YouTube-Kanal.