Nja, Grunssätzlich wäre es doch eigentlich
am Besten für die einzelnen Plattformen, wenn jeweils ihre nativen Komponenten verwendet werden,
also so wie es die
VCL,
CLX, LCL und CrossVCL machen.
Und dafür dann im Delphi eine Schnittstelle bauen, welche die "Gemeinsamkeiten" aller/der meisten Komponenten aller Plattformen auf eine einheitliche Delphi-
API (ala
VCL) abbilden.
Und dann gibt es eben auch noch den Weg, wo man sich auf den Plattformen eine grundlegende Zeichengrundfunktion sucht (können auch auf den Plattformen unterschiedliche sein),
dann alles selbst malt und alle Komponenten der Systeme nachbaut, bzw. das System komplett ignoriert und einfach selbst irgendwas baut, was dann optisch garnicht in die Systeme rein passt. siehe FMX, Java usw.
Stellt dann das
OS sein Erscheinungsbild in der nächsten Version um, dann muß der Style erstmal wieder neu nachgebaut/angepasst werden (die
VCL sieht sofort "richtig" aus).
Darum kann man im FMX auch inzwischen mehr oder weniger gut einige Komponenten auch auf Plattform umstellen, um die Funktionen des Systems zu bekommen, die nicht nachgebaut wurden.
Auch ScreenReader und andere Techniken für z.B. blinde und sehbehinderte Menschen, funktionieren erstmal nur bei den nativen Controls, falls es nicht zusätzliche Schnittstellen gibt, wo die selbstgemalte Komponente/Form dann dem
OS/System seinen Inhalt sagen kann.
Und auch eine
GUI Test Automation ist mit den nativen Controls einfacher, da alles Andere erstmal eine Schnittstelle zum Inhalt benötigt, denn die Pixel der Ausgabe zu analysieren ist eine saublöde unzuverlässige Idee.