Cross-Platform

Bekannte Beispiele:

• Java: "Write once, run anywhere." (Läuft auf jedem Gerät, das eine Java Virtual Machine hat).
• Webseiten: Laufen in jedem Browser (Chrome, Firefox), egal ob auf Handy oder PC.
• Flutter / React Native: Apps, die gleichzeitig auf iPhone und Android laufen.

1. Native vs. Cross-Platform

• Nativ: Du schreibst in der Sprache des Geräts (Swift für iPhone).
  • Vorteil: Extrem schnell, Zugriff auf alle Features.
  • Nachteil: Geht nur auf iPhone.
• Cross-Platform: Du nutzt eine Zwischenschicht.
  • Vorteil: Ein Code für alle.
  • Nachteil: Oft etwas langsamer ("laggier"), sieht manchmal "fremd" aus (ein Android-Button auf dem iPhone).

2. Electron

Viele moderne Desktop-Apps (Discord, Slack, VS Code) sind eigentlich Webseiten, die in einem eigenen Fenster laufen (Electron Framework). Deshalb kannst du sie leicht auf Windows, Mac und Linux anbieten. Nachteil: Sie fressen extrem viel RAM (jeden App ist quasi ein eigener Chrome-Browser).

1. Rendering: WebView (Cordova) vs. UI-Bridge (React Native) vs. Canvas (Flutter)

Wie zeichnet Framework X den Button auf dein iPhone Display? Hier gibt es drei Architektur-Welten:

• WebView (Cordova/Ionic): Die App ist insgeheim nur eine unsichtbare Safari-Browser-App, die HTML/CSS rendert. Keine echten nativen iPhone-Buttons. Extrem langsam bei Animationen, wird heute oft belächelt.
• JavaScript-Bridge (React Native): Du programmierst in JavaScript. Wenn du in React <Button> schreibst, funkt eine C++-Bridge asynchron 60 mal pro Sekunde an das OS (iOS/Android): "Zeichne mir auf diesen Koordinaten bitte deinen echten System-Button". Fühlt sich zu 90% nativ an, aber die ständige Kommunikation über die Bridge frisst Performance.
• Eigene Rendering-Engine (Flutter): Flutter nutzt Dart. Es weigert sich, iOS/Android Buttons zu nutzen ("Ich traue euren Buttons nicht"). Stattdessen nutzt Flutter die Grafikkarte (Skia/Impeller-Engine) wie ein 3D-Computerspiel und zeichnet jeden einzelnen Pixel des Buttons physisch selbst auf ein leeres Canvas. Fühlt sich enorm flüssig und konsistent (wie bei 120Hz) an, aber die App-Payload (Artefakt) wird massiv größer, weil die ganze Engine mitgeschickt werden muss.

2. PWA (Progressive Web Apps)

Eine Alternative zum App-Store-Wahnsinn. Du programmierst eine völlig normale Webseite (HTML/JS) und hostest sie auf deinem Web-Server. Aber in der Seite nutzt du sogenannte Service Workers (kleine JS-Skripte, die der Browser im Hintergrund des Handys weiterlaufen lässt, selbst wenn die Seite zu ist). Dadurch kann die Website plötzlich Offline-Cache-Fähigkeiten entwickeln und dem Handy Push-Benachrichtigungen schicken. Der Nutzer klickt auf der Website auf "Zum Homescreen hinzufügen", und bekommt ein App-Icon, ganz ohne den Apple/Google App Store passiert zu haben.

3. Conditional Compilation (Compiler Directives)

In klassischen kompilierten Sprachen (C, C++) macht man Cross-Platform ohne Framworks auf Kernel-Ebene über den Compiler vs. Interpreter. Man nutzt Compiler Directives (Präprozessor-Befehle):

#ifdef _WIN32
   // Führe Windows System-Call DeleteFile() aus
#elif __APPLE__
   // Führe MacOS POSIX-Call unlink() aus
#endif

Der Compiler ignoriert auf Windows physikalisch den Apple-Code und kompiliert ihn nicht mit ein. So schreibt man eine Codebase, pflegt aber den Plattform-spezifischen OS-Code in diesen Weichen.