Google brengt toolkit uit voor maken iOS- en Android-apps met enkele codebase

Google heeft versie 1.0 van Flutter uitgebracht, een toolkit om vanuit een enkele codebase apps te maken voor Android en iOS. De bèta van Flutter kwam eerder dit jaar online. Nieuw is onder meer de functie om een bestaande app verder te ontwikkelen met de toolkit.

Flutter werkt het met het Dart-platform voor 32bits- en 64bits-ARM-code en gebruikt Skia 2D Graphics voor het tonen van de interface, schrijft Google. Met Flutter moet de ontwikkeling van apps voor iOS en Android sneller gaan, onder meer door de functie om wijzigingen in realtime te zien in apps voor beide platformen zonder te hoeven herladen.

Google laat Flutter werken met de standaardprogrammeertalen voor Android en iOS, Kotlin, Java, Swift en Objective-C. Google heeft de eigen toolkit al gebruikt voor het maken van de Ads-app en claimt dat sommige grote bedrijven, waaronder Philips Hue en Alibaba, apps ontwikkelen en uitbrengen die met Flutter zijn gemaakt.

De opensource-toepassing moet in de komende tijd ook naar desktops komen, waarbij het gaat werken met Windows, macOS en Linux. Dat gebeurt door ARM-code om te zetten in Javascript, via een tool die Google Hummingbird heeft genoemd. De bèta van de toolkit kwam in februari online. Flutter 1.0 is als download beschikbaar voor Windows, Linux en macOS.

Reacties (49)

[Stannieman]

"Dat gebeurt door ARM-code om te zetten in Javascript, via een tool die Google Hummingbird heeft genoemd."

Slaat het nu niet een beetje door? Een soort generieke code zoals JS om het makkelijk op elk platform te laten draaien tot daar aan toe.

Maar een app vervolgens "hardcoded compilen naar ARM" of hoe moet ik het noemen? En dan terug omzetten naar JS (wat waarschijnlijk gruwelijk inefficiënte code oplevert) om het vervolgens weer door een JS engine te laten uitvoeren? Gaat dat niet wat ver? Straks hebben we een i9 nodig om onze mails te syncen.

[reneflo]

Ik weet niet hoeveel verstand de auteur van dit artikel precies heeft van Flutter, maar veel wat hier staat is raar opgeschreven of klopt niet.
Dart is gekozen omdat het werkt in een VM en kan compilen naar native code. Flutter is bedoeld om te draaien als native app, omdat dan de prestatie gewoon het beste is. Flutter is in eerste instantie gemaakt voor mobiel, maar wel met het idee dat het overal op kan draaien. Flutter komt inderdaad naar de desktop, zoals in het artikel staat, maar als "flutter desktop embedder" en dit gaat ook om compiled code. Daarnaast is Google bezig om Flutter ook naar het web te krijgen door te compilen naar javascript en dit is Hummingbird. Dit zijn dus 2 verschillende projecten waarvan de desktop embedder nu al te proberen is, maar Hummingbird publiek nog niets van te zien is.

De apps zijn dus daadwerkelijk gecompiled naar native arm-code, maar omdat Dart toevallig makkelijk naar javascript compiled is het Flutter team ook bezig om het te laten compilen voor web, maar daar is nog een lange weg te gaan.

[Verwijderd]

Hoe native is native wanneer Google er gewoon even een Skia laag tussenpropt die pixel voor pixel de rendering overneemt? Het is niet native, de output lijkt verschrikkelijk veel op native.

[Boy]

Ik denk eerder dat je het moet vergelijken met een game engine.

Volgens mij worden games bijvoorbeeld in C++ geschreven en kunnen vervolgens gebruikt worden op iOS en Android middels een game engine. Zo heeft Flutter ook een engine die dus de knoppen tekent.

Ik vind dit genoeg om 'native' te noemen, ipv een bridge die zorgt dat de componenten van het OS zelf gebruikt worden vanuit shared code zoals andere cross-platform toolkits doen.

[aegis]

Op Android word vrij veel door SKIA gerenderd her word ook door Chrome gebruikt. Het verschil tussen native apps en flutter als je het heel simpel zou zeggen zijn flutter apps meer native dan Java/kotlin apps op Android en op IOs zouden ze hetzelfde moeten zijn als Swift/Objective-c. Het eind resultaat van een flutter app is alsof een app in C++ hebt geschreven ten opzichte van een Java die naar bytecode is compileerd zodat het binnen de Java VM kan draaien.

[reneflo]

Wat @Boy en @aegis ook zeggen, het ligt er totaal aan wat je zelf definieert als 'native'.
Als je native definieert als je moet in java of kotlin schrijven en het moet draaien in de Android Runtime dan is het inderdaad niet native. Alleen waar de Android Runtime java code nog moet compilen naar ARM code doet Flutter dat al bij met maken van een apk. Wat dat betreft kan de code dus sneller draaien dan native code. Inderdaad een beetje zoals een game engine.

[Stannieman]

Dat houdt al heel wat meer steek en is ook de manier waarop ik verwacht dat zoiets werkt.
Want een ARM-binary decompilen en omzetten naar JS daar valt denk ik niet aan te beginnen.

[robvanwijk]

De code generator kan hiermee (enigszins) rekening houden met de code die ie uitspuugt. Als ie daarbij (voornamelijk) gebruikmaakt van code die door de JS engine goed te optimaliseren valt, dan zou het mee kunnen vallen met de inefficiëntie.

Vergeet niet dat er ooit een tijd was waarin alles in assembly werd geschreven. Toen kwam C (en co) en tegenwoordig vinden we PHP (hoeveel abstractie-lagen zitten er tussen PHP en machinecode; hoeveel machinecode instructies worden er uitgevoerd als overhead voor één PHP-functieaanroep?) efficiënt genoeg voor talloze toepassingen. Het principe "compile alles naar JS, run JS overal" (een beetje vergelijkbaar met hoe netwerken het doen: elk protocol wordt bovenop IP gebouwd; IP kan over elk medium getransporteerd worden) is helemaal zo gek nog niet. Uiteindelijk is het vooral een afweging waar je inefficiënt bent: moet een programmeur tijd verspillen aan het schrijven van code voor verschillende platformen, of laat je hardware cycles verspillen aan generieke code en extra "vertalingen"?

[8uurg]

Hier komt ook nog eens bij kijken dat een apparaat zelf weet welke instructies er worden ondersteund, zo kan generieke code later vertalen juist gebruik maken van wat er in een specifieke situatie aanwezig is.
Het is dus niet zo dat al die vertalingen cycles hoeven te verspillen in het eindresultaat wat uitgevoerd moet worden.

[Verwijderd]

Ja dat wel, alleen Draait PHP nog steeds aan de server side, en Is het een script taal en draait C op de laagste laag van de hardware. De server waar de PHP op draait, werkt nog steeds op basis van C/C++ of misschien wel ADA (Coreboot linux kernel).

Maar je punt komt wel over !

[aegis]

Er word voor hummingbird geen arm code om gezet naar JavaScript. Als een app maakt met flutter schrijf je die in Dart dat is een taal die naar andere talen ge compileerd kan worden waaronder JavaScript 1 is.

Also je technische wilt weten hoe ze dit doen moet je misschien “Hummingbird: Building Flutter for the Web” by Yegor Jbanov https://link.medium.com/dyPNUgbfqS eens lezen.

[Parrotmaster]

Waarom zou ARM die is geconverteerd naar Javascript zo veel performance vereisen?

[clueless12]

Ik gebruik inmiddels een paar maanden Flutter en ik ga echt geen 'native' apps meer ontwikkelen. De ontwikkelomgeving (IntelliJ) werkt echt super en het verschil met de native os elementen is bijna niet te zien. De bounce van ios en de maan van Android werken gewoon.
Ze geven aan dat Flutter 60 fps haalt en tot nu toe geloof ik dat.
Dart is wel even wennen

Echt super blij met Flutter

[jabwd]

Probeer eens naar dvorak-qwerty te gaan, probeer dan cmd+S en je komt er achter dat het niet native is.

Deze projecten proberen we al jaren, het blijft, en is in zijn gegeven, troep. Platformen zijn nou eenmaal niet aan elkaar gelijk. De enige reden dat we het proberen is omdat developers geld kosten, en laten we dat nou eens een keer niet ontkennen Goede native development is niet meer te zien tegenwoordig, ookal proberen ze in React/Redux het woord "native" te stiekem te gebruiken in de hoop dat we het addertje niet zien.

Ik draai slack lekker in safar ipv "native", heb ik nog 3gb extra aan geheugen voor andere programma's die ik echt gebruik.

[Reactie gewijzigd door jabwd op 22 juli 2024 15:40]

[hiostu]

Xamarin doet dit al lange tijd en is ook al vrij ver gevorderd met optimalisaties en zaken als Xamarin forms. Ook de performance is goed van dit soort apps. Tegenwoordig is Xamarin van Microsoft en werkt dus met een van de beste IDEs (Visual Studio).

[Wraldpyk]

Daarnaast bestaan er ook JavaScript frameworks waarmee dit kan. Zoals React Native, Nativescript of Titanium welke respectievelijk uit 2015, 2014 en 2009 komen. Dus dit is alles behalve nieuw. Maar ik verwelkom altijd nieuwe technologie!

Mijn ervaring met Flutter was niet heel positief though, het was vrijwel onmogelijk om een Google maps view toe te voegen aan een scherm, het lukte alleen als full-screen scherm, iets waar de bovengenoemde frameworks geen moeite mee hebben.

[Fleximex]

Ik maak er sinds enkele maanden gebruik van. Hiervoor enkel ervaring met desktop applicaties en geen mobiele applicaties (of je moet een Unity export naar Android meetellen). Ik moet zeggen dat het heel fijn werkt. De meerwaarde ligt vooral in het snel prototypen. Als ik mijn telefoon aan mijn PC aansluit, en een wijzinging aan de code doe, wordt de app direct op de smartphone geüpdatet zonder dat ik de app opnieuw hoef te builden. Heel handig! En met heel weinig code maak je een visueel prachtige app.
Je bouwt de apps met widgets (in widgets, in widgets, etc). Het werkt als het ware als een boomstructuur. Echter kun je daarnaast ook met de taal Dart (dat wat weg heeft van Java) prima complexere classes schrijven.
Het nadeel is wel dat het platform nog niet volwassen is. Vooral qua core functionaliteit mist er nog het een en ander. Zo is er voor Bluetooth de package 'Flutter Blue', maar dat wordt gewoon door één persoon gemaakt. Echt alternatieven zijn er niet. Dus als hij dat niet had gemaakt dan was er geen Bluetooth ondersteuning? Als je het zelf wilt doen moet je wat dieper de Java of Kotlin van Android en de objective-C of Swift van iOS doorspitten.

[Reactie gewijzigd door Fleximex op 22 juli 2024 15:40]

[hoi1234]

Is dit vergelijkbaar met Xamarin?

[Verwijderd]

Xamarin is vergelijkbaar met .NET op Windows. De applicatie draait native, maar vereist ook dat Mono touch aanwezig is (en een aantal Xamarin specifieke libs).

En Xamarin.IOS / Xamarin.Android wordt gewoon "vertaald" naar Objective-C en Java. De PCL / managed code draait via Mono.

[KeesAlderlieste]

Nee. Op iOS wordt C# code vooraf (AOT) gecompileerd naar ARM assembly language, op Android wordt het gecompileerd naar IL dat door mono uitgevoerd wordt. Het draait daar dan naast Java en is daarom vaak sneller dan native Java apps.
https://docs.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/building-cross-platform-applications/understanding-the-xamarin-mobile-platform

[Verwijderd]

Dat geldt voor het PCL project, oftwel de shared code. Het gewone Xamarin.Android project is echt wel Java (of Androids implementatie van Java).

Kijk maar eens in de obj map van de broncode van je Android project

[KeesAlderlieste]

Daar vind ik mijn code en teksten alleen maar in dll's met IL code, geen java. Er staan wel een aantal autogenerated files met java die voor oa project resources gebruikt worden.

[KeesAlderlieste]

Compilation. The platform has two major products: Xamarin.iOS and Xamarin.Android. In the case of iOS, the source code is compiled directly into native ARM assembly code (Ahead-of-Time compilation), while Android Xamarin apps are first compiled down to Intermediate Language and then – into native assembly code at runtime (Just-in-Time compilation). However, in both cases the process is automated and tailored to handle such issues as memory allocation, garbage collection, and platform interoperability by default.
https://www.altexsoft.com/blog/mobile/pros-and-cons-of-xamarin-vs-native/

[PPie]

Probleem van dit soort tussenlagen is dat je smallest common denominator ondersteuning krijgt met gedrag wat voor geen enkel platform als native aanvoelt...

[DynaSpan]

@PPie en @kingofkamikaze , hebben jullie überhaupt al eens de Flutter site gelezen of een app gedownload? Flutter compiled naar een volledig native app met native UI elementen. Er is geen performance verschil tussen Flutter en native apps.

[PPie]

Maakt niet uit dat het 'naar native compileert', het probleem is dat dingen die niet op alle platformen zitten, dan niet in dit soort abstractielagen zitten en vaak het moeilijk maken om alsnog iets toe te voegen.
Vroeger had je AWT op Java, dat was ook zo'n enorm succes, het werkte op alle platformen 'net niet'.

Las net deze:
http://www.takingnotes.co...act-native-accessibility/
Gaat over React Native, een vergelijkbaar iets, maar dan van Facebook.
Hier staat in dat het bijna niet te doen is om VoiceOver toe te voegen aan een app die gebruik maakt van React Native op iOS, omdat het framework het niet ondersteunt, juist dingen abstraheert die nodig zijn om Accessibility mogelijk te maken en het zelfs moeilijk maakt omdat het framework 'hidden buttons' gebruikt om de GUI te layouten. (Geen idee of een screen reader wel werkt aan de Android kant, maar het laat zien wat ik bedoel, mismatch in ondersteuning)

[KeesAlderlieste]

Xamarin lost dat op met custom renderers en is niet echt moeilijk. Kan dat bij Flutter ook?

[kingofkamikaze]

Amen,
Dat het naar native compiled laat het nog niet native aanvoelen.

[YopY]

Het zijn alleen "namaak" elementen - dat is, Flutter tekent zelf de graphics die lijken op die van het native platform. Het probleem is dat ze achter gaan lopen als bijv. Apple met een nieuw design van hun UI komt. En dan heb je nog alles in die standaard componenten die je niet ziet - voor iOS moet je dan denken aan accessibility (text to speech, fontgrootte (wat trouwens veel apps niet ondersteunen), hoog contrastmodus), maar ook bijv. force touch en de haptic feedback. Dat zijn veel features die ze opnieuw moeten implementeren - en waarschijnlijk niet gaan doen of bijhouden.

[kyura4k]

Flutter compiled inderdaad naar native, en voor zo ver ik weet worden de widgets gerendered via skia(c++). Correct me if i'm wrong, maar je bedoeld met native UI elements dat E naar machine code worden gecompileerd? Want naar mijn kennis zijn alle component van scratch met de hand geschreven, en dus geen native android of ios ui elements. Dus het kan heel goed dat het niet native aanvoelt.

Echter naar mijn ervaring met flutter is dat in de praktijk je daar niet veel van merkt (mijn ervaring blijft bij relatief aimpele apps met een simpele drawer, wat views met lists, animaties etc)

All in all vind ik Flutter een goede ontwikkeling en ik zal niet snel meer naar 1 van de andere bestaande (react native, ionic, etc) gaan

[Reactie gewijzigd door kyura4k op 22 juli 2024 15:40]

[fdm391]

@PPie en @kingofkamikaze , hebben jullie überhaupt al eens de Flutter site gelezen of een app gedownload? Flutter compiled naar een volledig native app met native UI elementen. Er is geen performance verschil tussen Flutter en native apps.

Flutter gebruikt dus zijn eigen renderer en tekent zelf controls en gebruikt niet de renderer/controls van het specifieke platform (android/ios/etc). Er hoeft dus geen performance verschil te zijn, maar dat kan zeker wel (beide kanten op). De makers van Flutter claimen dat ze sneller kunnen/willen gaan renderen dan de afzonderlijke platforms zelf doen.

Het verwarrende hier is, gezien ook meerder reacties het gebruik van de termen 'native' en 'native UI elementen'. Met name 'native' is op veel manieren te interpreteren. De een vind een Java-app op android native, de ander vind weer een ARM-gecompilede app met eigen rendering native.

Feit is in ieder geval dat Flutter zelf alles tekent en niet de UI controls van het systeem gebruikt. In deze is het erg vergelijkbaar met Qt bijvoorbeeld. Maar bijvoorbeeld totaal anders dan React Native, Xamarin en apps geschreven in Java/Kotlin (android) of Objective-C/Swift (ios).

[_Eagle_Eye_]

'dit soort' is wel heel generaliserend. Ik moedig dit soort ontwikkelingen aan, en hoop dat we uiteindelijk een volwassen oplossing bereiken. Het huidige probleem is dat we 2x budget moeten verbranden (iOS en Android) voor één app.

[YopY]

En dat is niet erg, want je krijgt 2x een goede native app ipv 1x een compromis waarbij developers alsnog 2x of meer tijd in moeten steken omdat het net niet goed werkt, of ze moeten een library schrijven en onderhouden om bepaalde native functionaliteit aan te kunnen spreken. En dan heb je nog de subtielere zaken - animaties, native look & feel, performance, maar ook niet direct zichtbare performance zoals batterijverbruik.

Ik geloof persoonlijk wel dat Flutter een beter platform is om Android apps te gaan ontwikkelen - het zal naar native compilen ipv naar JVM, bijvoorbeeld - maar voor iOS zijn er al goede tools om goede apps neer te zetten. iOS en de iOS apps liepen 5 jaar vooruit op Android, in ieder geval tot Android 4 - en de bijbehorende hardware - langs kwam.

[kingofkamikaze]

If(android){

}else{

}

Nee maar even serieus, ik ben het er helemaal mee eens dat de app niet native kan aanvoelen voor bijde systemen (zonder echt een if-statement bonanzai). Maar de laatste jaren komen er niet veel apps meer uit met een merkbaar andere interface op android of ios.

[Wraldpyk]

Ik ontwikkel al 7 jaar met cross-platform technologie (in mijn geval Titanium, vergelijkbaar als React Native), en dit is helemaal niet waar.

Ja... er wordt JavaScript mee gecompileerd, maar alle elementen werken cross platform op de manier dat de daadwerkelijk native elementen gebruikt zijn, en dus voelen ze ook zo.

Wat je ziet momenteel met iOS UI op Android, of andersom, is de slechte keuze van meestal de designer/manager die WIL dat ze op beide platformen hetzelfde er uit zien. Dit is vrijwel altijd meer werk dan ze er native uit laten zien.

Als voorbeeld een app waar ik 3 jaar aan gewerkt heb:
https://play.google.com/store/apps/details?id=net.roamler
https://itunes.apple.com/app/roamler/id440588804

[kingofkamikaze]

Als dit vanuit dezelfde code gegenereerd is dan moet ik toch toegeven dat het er wel erg netjes uitziet.

[Wraldpyk]

Dit is hoe het "moet". En ja, het is ongeveer 95% code-shared. De overige 5% is platform specifiek aangezien er natuurlijk verschillen zijn (navigatie structuur, knoppen zitten anders, andere native behaviour etc)

En voordeel, de designer en manager(s) weten dat het 2 verschillende platformen zijn en ook verschillend er uit moeten zien.

[graey]

Als de mogelijkheden op beide platforms aanwezig zijn en de abstractielaag deze goed aanspreekt, hoeft dat helemaal niet het geval te zijn. Je ziet dat soort dingen vaak bij tussenlagen die van webapps native apps moeten kunnen maken, omdat ze dan ook rekening moeten houden met wat er vanuit de webtechniek mogelijk is.

[Gamebuster]

De enige mensen die dit beweren hebben nog nooit daadwerkelijk een app gemaakt met "dit soort tussenlagen". In praktijk is dit nl. gewoon onwaar naar mijn ervaring. De abstractie laag bij bestaande "tussenlagen" is naar mijn ervaring dermate strak opgezet dat het gewoon prima aanvoelt als een native app bij zowel iOS als Android.

Zo groot zijn de verschillen overigens ook niet. Over het algemeen heb je 2 soorten apps: Apps die bestaande native componenten gebruiken (die beschikbaar zijn als abstractie in die tussenlaag), en apps die vrijwel volledig bestaan uit custom elementen, en die voelen sowieso al niet aan als specifiek "een android app" of "een ios app".

De enige die niet-native aanvoelt naar mijn smaak is de ionic framework, maar misschien is dat gewoon mijn gebrek aan ervaring met ionic

[Reactie gewijzigd door Gamebuster op 22 juli 2024 15:40]

[josttie]

Naja native, Google zet hard in op material design en vele iOS apps volgen die filosofie ook naar mijn weten, aangezien dit niet platform specifiek is maar een ontwerp filosofie. In een flutter project heb je ook gewoon een android project en een Swift project zodat je totaal iets native kunt maken als je er zin in hebt, dus het lijkt me ook wel mogelijk om de navigatie (wel/geen terug knop bijvoorbeeld) platform specifiek te maken, voor de specifieke content maakt het niet zoveel uit. Als je op de material.io website kijkt van Google zie je dat ze enorm flutter aan het ondersteunen zijn en al die elementen zijn wel ongeveer beschikbaar.

Ik heb me er nog niet helemaal in verdiept, maar toen ik het even uitprobeerde was het wel de eerst hybride optie die mij blij maakte. Het is loeisnel en er is geen enkel andere hybride optie dat dichtbij komt. Het zou helemaal cool zijn als je het in kotlin zou kunnen schrijven IPV dart maar misschien komt dat nog ooit

De instant run is zeer indrukwekkend, een druk op de knop en poef de app heeft de nieuwe code.

Dus ja, misschien zijn sommige bedrijven lui om twee designs te maken, maar flutter is 100x beter dan welke andere hybride oplossing, dus ik hoop te zien dat als een bedrijf dan toch een hybride oplossing kiest, er met flutter ten minste een fatsoenlijk resultaat uit komt.

[gekke-gerrit]

Voor basis apps is dit leuk! Hetzelfde geld voor react-native (doet hetzelfde, van Facebook) maar zaligmakend is dit niet. Lees hier hoe een grote partij als Airbnb het heeft ervaren om over te stappen naar react-native
https://link.medium.com/LcUn2ecepS

Ik heb inmiddels ontslag genomen bij mijn huidige werk omdat ze over zijn gegaan op react-native

[YopY]

Een commentaar op dat specifieke artikel is dat ze een hybride app probeerden te bouwen - native (iOS + Android) en React Native tegelijkertijd. Da's vragen om problemen, net als bijv. Facebook en Twitter jarenlang geprobeerd hebben om web views in apps redelijk werkend te krijgen (is ze niet gelukt). Is dat de schuld van het platform, of van de ontwikkelaars dat ze zich niet durven te specialiseren?

Vooral voor Facebook / Twitter en eigenlijk alle top 100 bedrijven vind ik het eigenlijk onaanvaardbaar dat ze niet gewoon het platform meester maken, ipv daarvan het denken beter te weten en kunnen. Of anders gezegd: dat weten en kunnen ze wel, maar ze kiezen voor de verkeerde technologie.

[Kdonkey]

Als er ook eens werd gedacht over het release proces voor iOS en Android dan werd het allemaal nog een stuk eenvoudiger. Ik verwacht toch dat web apps een groot deel van de native apps op termijn gaan vervangen door PWAs waardoor de eeuwige app store struggle ook over is.

Daarnaast denk ik dat Flutter wel een mooie toevoeging in het landschap kan zijn, echter zijn er momenteel wel erg veel spelers (Xamarin, Ionic, React Native etc.) en het blijft allemaal erg gevoelig voor platform updates en ben je daardoor redelijk vendor locked en afhankelijk van de community.

[Reactie gewijzigd door Kdonkey op 22 juli 2024 15:40]

[Menesis]

Hoe verhoudt zich dit tot wat Unity3D doet? Je schrijft daarin .NET en er komt een native android/iOS/MacOS/watdanook app uit. Zelfde principe?

[ATS]

Dat doe ik wel met Qt. Werkt ook op iOS, Android, Windows, OSX, Linux en zo nog een paar ossen.

Edit: ik zou nooit bouwen op een framework van Google, want die hebben nogal een reputatie als het gaat om het weer stoppen van projecten. Qt heeft een zeer goede track-record op dat gebied.

[Reactie gewijzigd door ATS op 22 juli 2024 15:40]

[YopY]

Qt wordt de laatste tijd steeds vaker weer genoemd als een serieuze speler op de markt; heb ik onder een steen gelegen en was het altijd al een topproduct, of hebben ze recent zodanig veel verbeteringen gedaan dat het weer een goede optie is?

[ATS]

Het ligt er aan waarvoor. Maar vraag aan mij geen objectief advies in deze: ik ben Qt consultant en weet praktisch niets van de alternatieven.

Maar ja: Qt met QML is IMO zeer geschikt om ook apps mee te bouwen en het wordt ook snel beter, zeker als je (grotendeels) dezelfde apps ook bijvoorbeeld op een embedded device wil gebruiken.