Erfahre, warum Dart entwickelt wurde, welche praktischen Probleme es löst und wie Laufzeit, Tooling und Flutter‑Integration schnelle, flüssige moderne Mobile‑Apps ermöglichen.
Dart ist eine moderne Programmiersprache von Google, die zum Erstellen von Apps mit starkem Fokus auf flüssige Benutzeroberflächen verwendet wird. Die meisten Menschen „lernen“ Dart über Flutter kennen: Wenn du eine mit Flutter gebaute Mobile‑App benutzt hast, ist die UI und ein Großteil der App‑Logik sehr wahrscheinlich in Dart geschrieben. Entwickler nehmen Dart wahr, weil es sich wie eine Sprache anfühlt, die speziell für UI‑Arbeit gemacht ist — schnell in der Iteration, gut lesbar und darauf ausgelegt, mit vorhersehbarer Leistung ausgeliefert zu werden.
Wenn eine App auf iOS und Android das gleiche UI‑Verhalten zeigt und regelmäßig polierte Updates erhält, kann es eine Flutter‑App sein — und das bedeutet meist Dart unter der Haube. Teams wählen Dart, wenn sie eine einzige Codebasis für mehrere Plattformen wollen, ohne auf Reaktionsfähigkeit zu verzichten.
Dart wurde mit ein paar praktischen Zielen geschaffen, die eng mit realer App‑Entwicklung übereinstimmen:
Dieser Artikel erklärt warum Dart entwickelt wurde, welche Probleme es für moderne Mobile‑Apps lösen will und wie es Flutter in der Praxis antreibt. Wir betrachten, wie Dart in Entwicklung vs. Produktion läuft, wie es asynchrone Arbeit handhabt, ohne die UI einzufrieren, und welche Sprachfeatures helfen, Bugs und Wartungskosten zu reduzieren.
Dart wurde geschaffen, um eine Lücke auf der „Client“‑Seite der Software zu füllen: interaktive Apps mit reichen UIs zu bauen, die trotzdem schnell laden, flüssig bleiben und wartbar sind, wenn sie wachsen.
Damals standen Entwickler oft vor der Wahl zwischen Sprachen, die entweder sehr gut für Scripting und schnelle Prototypen waren oder sehr gut für große Codebasen und langfristige Wartbarkeit — aber nicht beidem. Dart wollte eine moderne, zugängliche Sprache anbieten, die von einer kleinen Demo zu einem großen Produkt skaliert, ohne eine komplette Neuimplementierung zu erzwingen.
Darts Design begann mit einer praktischen Frage: Wie sollte eine Sprache aussehen, wenn sie für Benutzeranwendungen verwendet wird — Apps, die reaktionsschnelle Oberflächen, viele Zustandsaktualisierungen, Animationen, Networking und kontinuierliche Feature‑Arbeit brauchen?
Das führte zu einem Fokus auf vorhersehbare Leistung, Tooling und ein Ökosystem, das sauberen, lesbaren Code fördert. Wichtig ist: Dart sollte vertraut genug sein, damit Entwickler aus Java, JavaScript oder C‑artigen Sprachen schnell produktiv werden.
Dart verfolgte einige klare Ziele:
Diese Ziele prägten viele spätere Entscheidungen in der Sprache, wie eine starke Standardbibliothek, ein strukturiertes Async‑Modell und Features, die Fehler früher auffangen.
Dart wurde nicht ursprünglich „für Flutter“ geschaffen. Flutter jedoch wurde das Produkt, das Darts Ziele außerordentlich gut traf — schnelle Entwickler‑Iteration, UI‑schwere Apps und Code, der verständlich bleibt, wenn er wächst. Flutter machte Dart vielen mobilen Entwicklern sichtbar.
Dart ist nicht „nur noch eine Sprache“. Es zielt auf praktische Probleme ab, die Teams beim Bau von mobilen Apps erleben, die sich flüssig anfühlen, oft ausgeliefert werden und wartbar bleiben.
Traditionelle Mobile‑Workflows können Experimentieren bestrafen: Du änderst eine Button‑Farbe oder eine Layout‑Constraint und wartest dann auf Rebuild, Neuinstallation und das Zurücknavigieren zu dem getesteten Bildschirm.
Dart (in Kombination mit Flutter) ist so gestaltet, dass sehr schnelle Iteration möglich ist. Das Ziel ist einfach: UI‑Arbeit soll sich anfühlen wie das Bearbeiten eines Dokuments — ändern, sehen, anpassen — sodass Entwickler Ideen öfter testen und Fehler früher beheben.
Mobile‑Nutzer merken Ruckler sofort, besonders bei animationlastigen Oberflächen: Scrolllisten, Übergänge und gesteuerte Effekte.
Dart zielt darauf ab, konstante Leistung zu liefern, indem Frameworks die Möglichkeit bekommen, in effizienten nativen Code zu kompilieren und Nebenläufigkeit so zu strukturieren, dass der UI‑Thread nicht einfriert. Der Fokus liegt nicht auf Benchmark‑Prahlerei, sondern darauf, Alltagserlebnisse auf einer breiten Gerätepalette stabil zu halten.
Zwei separate native Apps zu pflegen bedeutet oft:
Dart unterstützt eine gemeinsame Codebasis, die trotzdem echte native Apps produziert — weniger Duplikation, ohne auf app‑store‑reife Performance verzichten zu müssen.
Mit wachsender App entstehen Bugs häufig aus „Klebecode“: Netzwerkaufrufen, Hintergrundaufgaben, Zustandsaktualisierungen und Datenmodellen.
Dart begegnet dem mit Sprachfeatures, die asynchrone Workflows lesbarer machen (weniger Callback‑Tangles) und mit starkem Null‑Safety‑Tooling, das Abstürze durch fehlende Werte reduziert — Probleme, die sonst teuer nachgebessert werden müssten.
Dart ist ungewöhnlich, weil es so ausgelegt ist, in zwei „Modi“ zu laufen, je nachdem, ob du entwickelst oder auslieferst.
Während der Entwicklung läuft dein Code typischerweise auf der Dart VM — das ist eine Laufzeit, die deine App laden, ausführen und während der Laufzeit aktualisieren kann. Du schreibst Dart‑Code, drückst Run und die VM wandelt den Code in ausführbare Form für das Gerät um.
Diese Umgebung ermöglicht schnelle Edit‑Run‑Zyklen: Die VM ist flexibel und kann Änderungen schnell anwenden, ohne alles neu zu bauen.
Ahead‑Of‑Time‑Kompilierung hilft bei Dingen, die Nutzer unmittelbar spüren:
Kurz: JIT optimiert für Entwicklergeschwindigkeit; AOT optimiert für Nutzererlebnis.
Beim Targeting des Browsers liefert Dart keine Dart‑VM aus. Stattdessen wird Dart nach JavaScript kompiliert, weil Browser JavaScript ausführen. Das Ziel bleibt dasselbe: ein konsistentes Entwicklererlebnis bieten und gleichzeitig Output erzeugen, der zur Plattform passt.
Hot Reload ist einer der sichtbarsten Alltagsvorteile von Dart mit Flutter. Statt die App zu stoppen, neu zu bauen, neu zu installieren und zurück zum getesteten Bildschirm zu navigieren, kannst du Codeänderungen in die laufende App injizieren und die UI fast sofort aktualisiert sehen.
Hot Reload aktualisiert den Code der App, während die aktuelle Sitzung erhalten bleibt. Das bedeutet typischerweise:
Für UI‑schwere Arbeit verwandelt das die Entwicklung von „ändern → warten → neu öffnen → neu navigieren“ zu „ändern → schauen → anpassen“. Diese eingesparten Sekunden summieren sich schnell beim Feintuning von Abständen, Typografie, Animationen oder Interaktionen.
UI‑Entwicklung ist iterativ: selten stimmt Padding, Ausrichtung oder Komponentenstruktur auf Anhieb. Hot Reload macht Mikro‑Experimente günstig. Du kannst ein neues Layout testen, eine Theme‑Farbe anpassen oder ein Widget in kleinere Teile zerlegen und sofort prüfen, ob sich der Bildschirm verbessert hat.
Es verkürzt auch die Feedback‑Schleife für viele Bugs — besonders visuelle oder zustandsbezogene Probleme — weil du Logik ändern und Verhalten ohne Ortsverlust in der App erneut prüfen kannst.
Hot Reload ist kein Allheilmittel. Bekannte Grenzen:
Stell dir vor, du baust einen Checkout‑Bildschirm und der "Bestellung aufgeben"‑Button wirkt eingeengt. Du änderst Padding von 12 auf 16, passt die Schriftstärke an und verschiebst den Button in eine Bottom‑Bar. Mit Hot Reload siehst du das neue Layout sofort auf dem Gerät, tippst zur Kontrolle herum und iterierst weiter, bis es sich richtig anfühlt — ohne die App jedes Mal neu zu starten.
Reale Mobile‑Apps fühlen sich nicht "schnell" wegen eines Benchmarks — sie fühlen sich schnell an, wenn die UI flüssig bleibt, während die App echte Arbeit verrichtet.
Eine flüssige UI bedeutet konsistente Frame‑Auslieferung (z. B. zuverlässig 60 fps oder 120 fps treffen) und responsive Eingaben. Wenn Frames verzögert werden, entsteht Jank: Scrollen stottert, Animationen ruckeln und Taps fühlen sich verzögert an. Schon kleine Hänger (50–100 ms) sind bemerkbar.
Dart verwendet Isolates, um zu verhindern, dass deine UI einfriert. Ein Isolate ist ein eigener Worker mit getrenntem Speicher, sodass aufwändige Aufgaben anderswo laufen können, ohne die Haupt‑Isolate zu blockieren, die Frames rendert und Gesten verarbeitet.
Das ist wichtig, weil viele normale Operationen überraschend schwer sein können:
Ein einfaches Muster ist: UI‑Arbeit in der Haupt‑Isolate, aufwändige Berechnungen an eine andere Isolate senden und Ergebnisse per Message‑Passing zurückbekommen.
Nicht jede Aufgabe braucht eine eigene Isolate. Viel App‑Zeit ist Warten auf I/O: Netzwerkaufrufe, Datenbankzugriffe, Dateizugriffe. Darts Future und async/await erlauben es, auf etwas zu warten, ohne das Event‑Loop zu blockieren, sodass die UI weiter rendern und Eingaben entgegennehmen kann.
final data = await api.fetchProfile(); // waiting, not blocking UI
setState(() => profile = data);
Der entscheidende Unterschied: Verwende async/await beim Warten auf I/O und Isolates, wenn CPU‑Arbeit (Parsen, Verarbeitung, Krypto) sonst Zeit vom Frame‑Rendering stiehlt.
Dart wurde so gestaltet, dass Teams UI‑schwere Apps ausliefern können, ohne dass Wartung zur ständigen Feuerwehr wird. Vieles davon kommt aus Sprachfeatures, die häufige Fehler früher verhindern — bevor sie zu Abstürzen in Produktion oder zu teurem Nacharbeiten werden.
Null Safety macht „kann das leer sein?“ zur bewussten Entscheidung. Wenn ein Wert vorhanden sein muss, erzwingt das Typsystem das; wenn er fehlen kann, musst du das explizit behandeln.
Das verändert das tägliche Coden praktisch:
Darts statische Typisierung verbessert Autocomplete, Navigation und Refactorings in IDEs. Es ist einfacher, Felder umzubenennen, Methoden zu extrahieren oder Module umzustrukturieren, ohne subtile Laufzeitfehler einzuführen.
Generics tragen dazu bei, dass Code konsistent bleibt — Sammlungen und APIs können stark typisiert sein (z. B. eine Liste von User statt „eine Liste von irgendwas“), was Datenform‑Fehler reduziert, die sonst spät auftreten.
Extensions erlauben es, fokussierte Helfer zu bestehenden Typen hinzuzufügen, ohne überall Utility‑Klassen zu schaffen (z. B. Formatierung auf DateTime oder Validierung auf String). Zusammen mit einem soliden Async‑Stil (async/await) bleibt typische App‑Logik lesbar statt in verschachtelten Callbacks zu versinken.
Darts Paket‑Ökosystem ist eine Stärke, aber Abhängigkeiten sind auch langfristige Verbindlichkeiten. Bevorzuge gut gepflegte Pakete, prüfe jüngste Releases und Issue‑Aktivität und halte die Abhängigkeitsliste klein. Pinne Versionen bedacht und aktualisiere regelmäßig, damit Sicherheits‑ und Breaking‑Changes sich nicht ansammeln.
Flutter ist keine UI‑Schicht über nativen Controls — es zeichnet seine eigene UI Frame für Frame, und Dart ist die Sprache, die das praktikabel macht, ohne Teams zu verlangsamen.
Flutter‑Apps bestehen aus Widgets — kleine, komponierbare Bausteine, die beschreiben, wie die UI für einen gegebenen Zustand aussehen soll. Darts Syntax unterstützt das Schreiben solcher Bäume gut, und seine Async‑Features machen es einfach, auf Ereignisse (Taps, Netzwerk‑Ergebnisse, Streams) zu reagieren, ohne in Callback‑Knäuel zu geraten.
Wenn sich etwas ändert, baut Flutter die Teile des Widget‑Baums neu auf, die von diesem Zustand abhängen. Dieses „Neubauen ist normal“‑Modell funktioniert gut, wenn dein Code schnell ausführbar und leicht refaktorierbar ist — zwei Bereiche, in denen Darts Tooling und Sprachdesign helfen.
Flutter zielt auf flüssige UI‑Updates ab, die konsistente Frame‑Zeiten erfordern. Dart unterstützt schnelle Iteration in der Entwicklung (via JIT) und kompiliert dann für Release‑Builds Ahead‑Of‑Time. Diese AOT‑Ausgabe vermeidet Laufzeit‑Overheads, die bei animationintensiven Interfaces Jank verursachen könnten.
Ebenso wichtig: Flutters Rendering‑Pipeline ist vorhersehbar. Dart‑Code läuft in einer verwalteten Laufzeit mit standardmäßig single‑threaded UI‑Modell, was viele übliche Fehler im Zusammenhang mit dem UI‑Thread reduziert, während Hintergrundarbeit nach Bedarf möglich bleibt.
Buttons, Padding, Reihen, Themes, Navigation — vieles ist ein Widget. Das klingt abstrakt, bis man merkt, dass Wiederverwendung meist Komposition statt Vererbung bedeutet. Du kannst Verhalten (Abstände, Styling, Gesten) konsistent um jedes Element herum bündeln.
Die meisten Teams wählen einen von wenigen Ansätzen — lokales setState für einfache Bildschirme, Provider/Riverpod für app‑weite Abhängigkeiten oder BLoC/Cubit für ereignisgesteuerte Flows. Die beste Wahl folgt meist der App‑Komplexität und Teampräferenz, nicht Ideologie.
Wenn du einen praktischen Vergleich willst, siehe /blog/flutter-state-management.
Cross‑Platform heißt nicht „kein nativer Code“. Reale Apps brauchen Plattformfunktionen — Kamera, Push‑Benachrichtigungen, Bluetooth, Biometrie, In‑App‑Payments, Hintergrunddienste und tiefe OS‑Integrationen. Darts Ökosystem (insbesondere mit Flutter) ist so gestaltet, dass du diese Fähigkeiten erreichst, ohne das Projekt in ein gemischtes Sprachenchaos zu verwandeln.
Platform Channels sind eine strukturierte Möglichkeit, dass Dart Code nativen Code (Kotlin/Java auf Android, Swift/Obj‑C auf iOS) aufruft und ein Ergebnis zurückbekommt.
Auf hoher Ebene sendet dein Dart‑Code Nachrichten wie „start payment“ oder „scan for Bluetooth devices“, und die native Seite führt die plattformspezifische Arbeit aus und gibt Daten (oder einen Fehler) zurück. Die meisten Teams nutzen das für:
Der Produktivitätsgewinn: Du hältst den Großteil der App in Dart und isolierst plattformspezifischen Code auf kleine, klar definierte Grenzen.
Dart FFI (Foreign Function Interface) erlaubt es Dart, C‑APIs direkt aufzurufen, ohne das nachrichtenbasierte Kanalmodell. FFI ist sinnvoll, wenn:
Native Integrationen sind mächtig, bringen aber Komplexität mit sich:
Gute Praxis: native Aufrufe in einer kleinen Dart‑API kapseln, Integrationstests pro Plattform hinzufügen und den Vertrag zwischen Dart und nativen Komponenten klar dokumentieren.
Dart ist am bekanntesten für Flutter auf Telefonen, aber dieselbe Sprache und ein großer Teil desselben Codes können weiterreisen. Entscheidend ist, zu wissen, was wirklich portabel bleibt (meistens Business‑Logik) und was plattformspezifisch ist (oft UI und Integrationen).
Dart kann im Browser laufen (meistens via Kompilierung nach JavaScript). Teams teilen oft:
Was typischerweise angepasst werden muss:
Wenn du bereits eine Flutter‑App hast, kann Flutter Web helfen, die UI‑Logik ähnlich zu halten, aber plane Zeit für web‑spezifisches Feintuning ein.
Flutter unterstützt Windows, macOS und Linux. Ein übliches Muster ist, die UI‑Struktur und Zustandsverwaltung ähnlich zu halten, während du anpasst an:
Dart wird auch für Kommandozeilen‑Tools, Build‑Skripte und leichte Backends genutzt. Es passt praktisch, wenn du Model‑ oder API‑Clients wiederverwenden willst oder eine Single‑Language‑Toolchain bevorzugst. Für schwere Serverökosysteme hängt die Wahl oft mehr von Bibliotheken und Team‑Erfahrung ab als von reinen Sprachfähigkeiten.
Teile vor allem Business‑Logik (Modelle, Services, Zustand, Tests) zwischen Mobile/Web/Desktop und behandle UI und native Integrationen als Plattform‑Layer. So bleibt Portabilität hoch, ohne jeden Plattformkompromiss beim Nutzererlebnis zu erzwingen.
Dart glänzt, wenn dein Ziel ist, schnell ein poliertes, interaktives Produkt auszuliefern — ohne zwei native Codebasen zu pflegen. Es ist jedoch nicht automatisch das beste Werkzeug für jede App, besonders wenn du sehr an plattformspezifischen UI‑Konventionen oder Nischen‑Native‑Tools gebunden bist.
Wenn deine App UI‑schwer ist — viele Bildschirme, Animationen, individuelle Komponenten, häufige Design‑Anpassungen — ist Dart eine starke Wahl. Hot Reload und eine gemeinsame Codebasis sind praktische Vorteile für Startups und Produktteams mit wöchentlichen Iterationen.
Es passt auch, wenn du konsistente UI‑Erlebnisse über Plattformen brauchst oder dein Team vorhersehbare Wartung schätzt: eine Feature‑Liste, ein Bug‑Set, ein Release‑Rhythmus.
Wenn du sehr spezifische native UI‑Muster strikt befolgen musst oder sofort die neueste native UI‑Bibliothek der Plattform brauchst, kann native Entwicklung einfacher sein.
Ein weiteres Hindernis ist die Abhängigkeit von Nischen‑SDKs oder Hardware‑Integrationen mit dünnem Flutter‑Plugin‑Angebot. Native Bridges sind möglich, reduzieren aber den Vorteil „ein Team, eine Codebasis“.
Hiring ist normalerweise machbar, aber lokale Märkte haben eventuell mehr native Entwickler als Dart/Flutter‑Spezialisten. Berücksichtige auch bestehenden Code: Wenn du bereits reife native Apps hast, lohnt sich ein Wechsel meistens nur bei größeren Umstrukturierungen.
Wenn du bei den meisten Fragen mit „Ja“ antwortest, ist Dart wahrscheinlich eine pragmatische Wahl. Bei mehreren „Nein“ erwäge native‑first oder einen hybriden Ansatz.
Der schnellste Weg zu verstehen, warum Dart für moderne App‑Entwicklung gut funktioniert, ist, den Workflow selbst zu erleben. Du musst nicht alles vorher lernen — starte, indem du etwas Echtes ausführst, und vertiefe dein Wissen mit dem, was du baust.
Installiere Flutter (es bündelt ein Dart‑SDK) und führe flutter doctor aus, um sicherzugehen, dass deine Maschine bereit ist.
Erstelle und starte die Beispiel‑App:
flutter create hello_dart
cd hello_dart
flutter run
lib/main.dart, ändere ein Widget (z. B. einen Text()‑String oder eine Farbe) und speichere. Die App sollte sich sofort via Hot Reload aktualisieren — der einfachste Weg, Darts enges Feedback‑Loop praktisch zu erleben.Wenn dein Ziel ist, eine Produktidee schnell zu validieren (nicht nur die Sprache zu lernen), ist ein „UI + Backend + Datenbank“‑Prototyp oft der Engpass. Plattformen wie Koder.ai können hier helfen: ein Vibe‑Coding‑Workflow, bei dem du die App im Chat beschreibst und eine funktionierende Implementierung schneller generierst als beim traditionellen Aufbau von Grund auf. Für Flutter‑Teams ist das besonders nützlich, um erste Screens und Flows zu erzeugen und dann in Dart mit Hot Reload zu iterieren. Wenn du ein Backend brauchst, kann Koder.ai Go‑Services mit PostgreSQL generieren und unterstützt Quellcode‑Export, Deployment/Hosting und Rollback via Snapshots.
Widgets: Betrachte die UI als Baum kleiner Teile. Lerne Basis‑Layout‑Widgets (Row, Column, Container) und wie Zustand funktioniert (StatefulWidget).
Async + await: Reale Apps holen Daten, lesen Dateien oder rufen Plattform‑APIs auf. Werde mit Future, async und Fehlerbehandlung vertraut.
Null Safety: Dart hilft, gängige „fehlender Wert“‑Abstürze zu vermeiden, indem Nullbarkeit explizit gemacht wird. Das zahlt sich schnell aus, wenn die Codebasis wächst.
Packages: Lerne, wie man Abhängigkeiten in pubspec.yaml hinzufügt und wie man Paketqualität bewertet (Wartung, Beliebtheit, Plattformunterstützung).
Baue eine kleine App, die die Grundlagen beweist: zwei Bildschirme, ein Formular und ein Netzwerkaufruf (oder lokaler Speicher). Das reicht, um Leistung, Iterationsgeschwindigkeit und Integrationspunkte zu testen, ohne große Verpflichtungen.
Für weiterführende Artikel: /blog/flutter-vs-react-native, /blog/dart-null-safety, /blog/flutter-performance-basics
Dart ist eine moderne Sprache von Google und heute vor allem sichtbar, weil Flutter Dart für UI und einen Großteil der App‑Logik nutzt.
Teams schätzen Dart, weil es schnelle Iteration in der Entwicklung (Hot Reload) und vorhersehbare Leistung in Produktion (AOT‑kompilierter nativer Code) ermöglicht.
Dart zielt auf das Problemfeld „Client‑Apps“: interaktive, UI‑schwere Anwendungen, die schnell laden, flüssig bleiben und mit wachsendem Umfang wartbar bleiben müssen.
Es wurde entworfen, um folgende Balance zu bieten:
Während der Entwicklung läuft Dart häufig auf der Dart VM mit JIT (Just‑In‑Time)‑Kompilierung, was schnelle Iteration und Workflows wie Hot Reload ermöglicht.
Für Release‑Builds verwendet Dart AOT (Ahead‑Of‑Time)‑Kompilierung, um nativen Maschinencode zu erzeugen – das verbessert Startzeit und reduziert Laufzeit‑Overhead, der UI‑Ruckler verursachen kann.
Hot Reload injiziert aktualisierten Dart‑Code in die laufende App und erhält typischerweise deinen aktuellen Bildschirm und Navigationszustand.
Es ist besonders nützlich für UI‑Iteration (Layout, Styling, Widget‑Refactorings), aber manche Änderungen erfordern einen vollständigen Neustart—insbesondere alles, was die App‑Initialisierung betrifft oder tiefere Verdrahtungen verändert.
Verwende async/await für I/O‑Wartezeiten (Netzwerk, Datenbank, Dateizugriff), damit die UI weiter gerendert werden kann, während auf ein Future gewartet wird.
Verwende Isolates für CPU‑intensive Arbeit (große JSON‑Parsen, Bildverarbeitung, Kryptographie), damit die Haupt‑Isolate (UI) keine Frames verliert.
Praktische Regel: → ; → Isolate.
Null Safety macht die Frage „Kann das null sein?“ explizit im Typensystem, sodass der Compiler fehlende Werte früher erkennt.
Praktische Vorteile:
Darts statische Typisierung verbessert die IDE‑Unterstützung (Autocomplete, Navigation, Refactorings) und macht große Codebasen wartbarer.
Generics helfen, Datenformfehler zu vermeiden – z. B. List<User> statt lose typisierter Sammlungen, sodass Unstimmigkeiten früh auffallen.
Im Web wird Dart typischerweise nach JavaScript kompiliert, weil Browser keine Dart‑VM ausführen.
Praktisch teilen Teams oft Business‑Logik (Modelle, Validierung, Networking) zwischen Plattformen, während UI und Plattform‑Integrationen an die Web‑Anforderungen (Routing, Accessibility, SEO) angepasst werden.
Verwende Platform Channels, wenn du OS‑spezifische APIs oder native SDKs (Zahlungen, Bluetooth, Kamera, Push) ansprechen musst. Dart sendet Nachrichten an Kotlin/Java (Android) oder Swift/Obj‑C (iOS) und erhält Ergebnisse zurück.
Verwende Dart FFI, wenn du direkt C‑APIs aufrufen musst (z. B. performante Bibliotheken, bestehender C/C++‑Code) und geringere Latenz als beim Nachrichten‑Bridging brauchst.
Dart (mit Flutter) passt gut, wenn du:
Es kann weniger gut passen, wenn:
async/await