Aus genau diesem Grund empfehlen richtige Cross-Platform Entwickler ja auch, seine Anwendung mehrschichtig aufzubauen, UI von Logik zu trennen und für jedes System eine native
GUI mit dem jeweiligen am besten passenden Toolkit zu erstellen, und den non-
Gui-Code hinten halt wiederzuverwenden.
Was man dann ja wohl vergessen kann...
Nö. Mit einem bisschen Architektur und vielen Ogern.. erm.. Zwiebeln.. äh.. Schichten, ja genau: Schichten, geht das ohne weiteres.
Man muss halt etwas mehr Zeit da rein stecken.
Mal ein Beispiel: Der Bugtracker von RemObjects war irgenwann mal ein Bugzilla. Dann kam ein Projektsystem (nochmal Bugzilla) dazu. Und ein Supportsystem (nochmal Bugzilla). Im Laufe der Jahre wurde aus dem Projekt- und Bugtracking ein Komglomerat von 6 Bugzilla-Datenbanken, einem angepassten Bugzilla-Frontend und einer Windows-Applikation. Historisch gewachsen eben.
Heute steht dort ein Middle-Tier-Server der die Datenbanken bedient, eine Windows-Applikation, eine Mac-Applikation und eine iPhone & iPad-App. Die Windows-, Mac- und iOS-App teilen sich den gleichen Code für den Zugriff auf den Backend-Server und stellen nur jeweils andere GUIs zur verfügung. Die iOS App sogar gleich zwei unterschiedliche GUIs je nach Gerät. Der Backend-Server teilt auch noch ein bisschen Code mit den Frontend-Apps.
Natürlich war das ein Stück Arbeit, aber herausgekommen sind Apps, die vorne jeweils die bestmögliche User-Experience bieten und dennoch hinten im 'unsichtbaren Teil' mit einem Schlag kollektiv erweitert / gewartet werden können.
Von daher ist das nichts, "Was man dann ja wohl vergessen kann", sondern ein (und meiner Meinung nach der richtige) Weg, Cross-Platform Anwendungen aufzusetzen.