"aber nach ausreichendem Testen und Abwägen"... genau deshalb nehmen wir doch Delphi mit FMX für Apps!
Der jeweils einmalige (VM) Aufwand bei Updates wird sicher jeweils von einem gemacht, der erstmal Account & Geräte mit AndroidStudio und XCode checkt und dann ein für uns passendes Standardprojekt in Delphi erstellt. Ab jetzt können dann "alle die nur Delphi können" die Sache nutzen.
Wenn die "gebastelte" shared
GUI 20% im Projektumfang ist, 20% notfalls "irgendwie" angepasster und aufs nötigste begrenzter Plattformcode ist und ich dann 60% echtes CodeShare für 4 Platformen (Win/OSX,IOS,Android) habe, ist das für uns trotz des Aufwandes "bis bei Updates was läuft" ein Zeitgewinn für das was wir dann machen.
Selbst kommerziell rechnet sich das, denn für XCode mit ObjC/Swift, AndroidStudio mit Java oder VS.NET mit C# gibt es viele junge dynamische Programmierer und Angebote wie Sand am Meer.
Da ist man schnell ersetzbar und muss sich stets großer (Wissens&Angebots)Konkurrenz stellen. Nö, das tuen wir uns nicht an. Deshalb per Delphi-FMX bewusst mit voller Absicht mal was anderes.
Über dem Tellerrand von Desktop&Mobile im Embedded-Bereich auf kleinen Microcontrolern herrscht mit C/C++ zwar noch die große Spracheinigkeit, aber bei LowPower 8/16Bit und nur einigen KB Flash & wenig
RAM ist es auch eine "Glaubensfrage" welche Prozessortechnologie und dann welcher Derivatehersteller genutzt wird. (z.B. x51, AVR, PIC, ARM, MSP).
Das INet ist voll von Zeug & Leuten für AVR&ARM, und genau deshalb nehmen wir es als bewusste Entscheidung nicht. Wir machen alles mit MicroChip PIC-18/24/32 einfach aus Prinzip, auch wenn wir manches selbst anpassen und einpflegen müssen.
=> deshalb machen wir uns hier das bewusst gewollte Leben mit FMX eben in Selbsthilfe etwas leichter und erträglicher. Wer es anders sieht kann ja VS.NET,XCode,AndroidStuidio oder was auch immer nehmen und sich damit schneller und einfacher seine Erfolgserlebnisse schaffen
