Flutter – Cross Platform App Development from Google

fluttericonFlutter is a new cross platform app development framework from Google that allows apps to be created for both Android (KitKat or later) and iOS (iOS 5 or later). It’s still being developed, primarily by engineers at Google.

Flutter is a high performance (60fps) 2D rendering engine with framework and widgets on top. There are also Material Design widgets. It’s all open source.

Internally, Flutter is a mix of C, C++, Dart and Skia (the 2D rendering engine). On Android, there a Dart VM that isn’t an interpreter. Instead, the Dart VM generates JIT-compiled optimized native code. On iOS the code is compiled with LLVM and Dart code is AOT-compiled into native code. On either platform you can call native services via IPC.

The programming language used is Dart which is also open source. Dart, which became available about a year ago, was once thought to be a future replacement for Javascript in the browser but now seems to have taken a new direction. Dart is a mix between c++ and Java and supports classes with single-inheritance. It supports interfaces, abstract classes, reified generics and optional typing.

Flutter isn’t suitable for production apps just yet and you can’t yet produce installable apps that easily. On the plus side I can see it will be enable us to produce high performance, cross platform apps with much less effort and cost. However, I have some reservations.

The first is that the widgets don’t use the respective system’s underlying widgets. There are Material Design widgets but who is going to want these on iOS? iOS look and feel widgets are needed. Even if these were available, it will create ‘look and feel’ problems when Apple and Google update the system widgets in the future. Also, I can’t see how Flutter widgets would ever provide for all the theme/style customisations provided by the native platforms.

Of course, we have been here during Nokia’s ownership of Qt. Providing for respective platform UIs, especially over time, is a monumental task. Getting developers to learn a new language also requires some sort of motivation. Apple is managing it with Swift but people are coming from the much more unfriendly Objective-C. Another unknown is the Google internal politics of where this fits into existing Android dev tools. Again, internal politics helped to kill Nokia Qt. However, the wildcard is Oracle that could tip things the other way. Much longer term, there’s a (small?) chance Oracle’s continual battles over Java IP could tip Google into using an alternative.

Finally, Flutter isn’t the only cross-platform framework trying to use Dart. Fletch is also based on Dart.

Nokia R&D and Symbian

nokia.gifAccording to my web logs, my post yesterday on Nokia MeeGo and Belle was very popular. Some people agreed with me on Twitter. However, a tweet by Sebastian Brannstrom made me look at it from another angle. He said "I think an important factor is the staggering cost of Nokia R&D. They can’t develop at reasonable cost".

This is true. According to Bernstein Research, Nokia spent $3.9 billion, almost three times the average of its rivals’, in 2010. About a third of this was on Symbian.


While there were, no doubt, savings to be made in company inefficiencies, a lot of blame has been centred on Symbian. When I worked at Symbian in London in 2006/7, I was amazed that the people there were hit by the same problems as 3rd party developers. I had somehow thought that the difficult APIs and ideoms might have been mastered by the people creating the OS. Instead, a mindset persisted that things were difficult because they needed to be, to provide for an efficient OS. Things took much longer to do than, for example, on Windows Mobile on which I also had deep experience.

As I mentioned as long ago as 2005, and again more recently, all Symbian needed was something more friendly (e.g. dev libraries and UI) on top of Symbian. In fact, this is what Windows Phone became – a new UI and APIs on top of Windows CE. Nokia could have done the same thing (but much better with native rather than managed code) on top of Symbian. Nokia tried something similar with Qt but had problems agreeing a new UI and Qt mobility (device APIs) arrived too little, too late. Adapting the Qt dev environment acquired from Trolltech proved too difficult. A simpler native c++ dev library that both internal and 3rd party developers could use, and new Belle-style UI might have been all that was required.

Nokia N9 Apps and Development

nokia.gifNokia have finally announced their first (and probably last) MeeGo phone. This is the culmination of years of effort, many blind alleys and u-turns. I am not sure why Nokia released it given their new Windows Phone strategy. I suppose there was so much already done and in the pipeline that it made sense to at least show some capability in between ditching Symbian and introducing Windows Phone. Most Nokia phones are sold via network operators and according to some I have spoken to, they have already ‘turned off’ thinking about Symbian and MeeGo phones so I suspect very few will sell via this channel. Instead, it will become much like the N900 for people who want to experiment with the software in their phones.

From a user and developer viewpoint there are lots of misconceptions as to what apps will run on the N9. People are speculating that existing Qt apps for Symbian will run on the phone which isn’t strictly correct, not least because the N9 won’t be accepting .sis files. There will also be other small inconsistencies related to how the Qt needs to do things slightly differently on MeeGo (different preprocessor symbol for the technically oriented) and some UI assets might need slight changes for optimal viewing. However, it will be possible for Qt developers to easily modify and rebuild their apps to run on the N9. Whether they bother to do so is another matter.

Qt QML Tips

qt.gifLast week Nokia released Qt SDK 1.1 Technology Preview. This is a very important milestone for Nokia. This is the first release that allows developers to a) Use deeper Qt Mobility APIs to access phone features b) Easily create QML apps for Symbian. Previously, this required a lot of patience, luck and black magic to get working by combining and building separately released components. You still can’t ship apps because it’s a pre-production SDK and the respective Qt runtime isn’t available to end user users yet. However, once the final version of this SDK ships, developers will be able to ship Qt QML apps (that also integrate deeper into phone features) for the very first time.

QML is significant because it greatly simplifies development compared to Symbian. It also provides a bridge to Meego in that once MeeGo devices ship, Qt QML apps we be able to be re-built for MeeGo.

For early adopters such as myself the development documentation and QML development community is young and it can take a while to know how best to go about some common tasks. Also, there are still some elements of QML that are missing and need workarounds. It’s for this reason I have started a ‘Qt QML Tips‘ page to gather some tips I have discovered. 

Nokia Qt QML

qt.gifQML is Nokia’s new declarative language to build Qt UIs and apps. It’s what Nokia is recommending developers (and its internal developers) use to develop new apps so that they will be compatible with current/future Symbian OS-based and future MeeGo-based devices.

I have been using QML for a few weeks. Here are my thoughts…

  • QML feels a little like Javascript. Unlike c/c++, you don’t have to worry about memory allocations and it’s not strongly typed. There’s no compilation which means most syntax errors get found at run time. However, running apps is fairly quick (using the QMLviewer under emulation) and you can re-run your app without restarting the emulator.
  • Once you have used it for a short while, QML is significantly easier to develop for than Symbian, iOS, and even Android.
  • There’s no standard UI for next-gen Symbian or new MeeGo because Nokia are still working on them. For this reason, there’s no framework yet for creating screens and widgets/controls. Instead you have to deal with rectangles, mouse events, images etc. This means you have you build up your own UI. There are examples how to build your own buttons, edit boxes etc so it’s not as onerous as you might think.
  • The IDE, QT Creator, used to edit/build qml files is proprietary rather than Eclipse-based so you end up missing lots of features you might take for granted. 
  • One disadvantage is that because the files describing your screens/code are not compiled, they remain readable to hackers should they try to uncompress your installer. Nokia need to look into this and provide some kind of source encryption. UPDATE: I have since been informed by Nokia "Adding your QML files to a QRC (resource file) will get them compressed and compiled into the binary". To use these files, you reference your first QML file (in c++) from a resource, all further relative requests for files come from the resource. Further tip: Don’t put large graphics in a resource as they get hexdumped which bloats the executable hugely – if your first qml comes from resource you can later reference outside the resource using ‘file:<filename>’.
  • The forums on qt.nokia.com are a great place to ask questions if you get stuck.

Unfortunately a lot of the existing documentation (and many Qt developers) still uses the older QWidget-based development that isn’t suitable for today’s touch screen devices. I think Nokia needs to put more effort into converting developers (and developers for developers) to Qt QML.

Nokia Qt Insights

qt.gifI have been continuing to try to get the latest Qt tools working and have learnt a few things that should have been made clearer by Nokia. I have spent a considerable amount of time trying to get the Mobility 1.1 APIs working under emulation. I have tried on Windows, Ubuntu and have even tried updating the Nokia Qt SDK with the latest libraries.

Here’s what I have learnt…

  • You should really only be downloading stuff from the Qt web pages at Forum Nokia. The Nokia Qt SDK 1.0 contains sets of Qt libraries and SDKs that have been tested to work together.
  • Conversely, if you download anything from qt.nokia.com  you will be downloading components that haven’t necessarily been tested to work with other components. For example, the latest released mobility APIs don’t compile (without a huge amount of fixing) on Windows or Ubuntu and won’t work with the Nokia supplied version of Qt Creator.
  • If you try mixing and matching components you most likely get into difficulties. I have experienced that you also won’t get any help from the Forum Nokia or Qt developer forums because you are ‘on your own’ and outside the realms of a fully tested environment.
  • As regards the Mobility 1.1 APIs/Qt 4.7.1, all I managed to get working with the current Nokia Qt SDK 1.0 was a Symbian target build but the resultant configuration wasn’t for the faint hearted.

The consequence of this is that…

  • The current released Mobility 1.1 APIs and Qt 4.7.1 aren’t usable at the moment for current development because they haven’t been integrated into the Forum Nokia supplied Nokia Qt SDK that currently uses 1.0.2 and 4.6.3 respectively.
  • Qt Quick and qml are based on Qt 4.7.1 so also aren’t usable at the moment for current development. In fact if you look in the current Nokia Qt 1.0 SDK the Demo Declarative samples aren’t runnable yet.

In summary, for current commercial development (and sanity), stay away from qt.nokia.com and stick with downloads from Qt web pages at Forum Nokia… and wait for released components on the former to become available on the latter.

As Marina, on the Qt forums says…

"I tried install Qt Framework 4.7.1, Qt Mobility 1.1.0 and Qt Creator several times. Making everything to work together is mission impossible. I can’t run examples, the worst thing is that to figure out what everything need to be installed you have to google whole day and when you think “ok, everything is ready now”, it is not. Every time some stupid error is shown in compile output. I just don’t understand why people from Nokia allow release of semi-product. If Nokia Qt SDK is not ready, i also don’t understand why doesn’t exist link with described installation steps, for example : 1) Install Perl (download link is here) . You have to do this and this, bla bla 2) Install Qt Framework 4.7.1 (link is here) 3) Install Qt Mobility (link for download is here) following these instructions"

Nokia releasing components on qt.nokia.com is great for PR but it’s no good if they aren’t easily usable. To avoid confusion and frustration, it might be better if Nokia kep’t them back until the respective Nokia Qt SDK is available.

Nokia Qt Quick, QML and Mobility 1.1

qt.gifFollowing Nokia’s announcement that the future of all Symbian and MeeGo development will/should be based on Qt, Qt Quick and QML, I have been evaluating Qt Quick, QML and the latest mobility APIs for use on a client project I will be working on very soon.

Previously when creating Qt UIs, you had to either use Qt QWidgets or build your screens on top of QGraphicsView. QWidgets are the lowest common denominator in Qt in that they work on all Qt platforms (Windows, Linux, Mac, Symbian, MeeGo). However, the user experience is very poor, especially on touchscreen phones. You don’t get the phone’s underlying look and feel and hence this method of development isn’t really acceptable for today’s applications.

QGraphicsView is newer and allows use of things such as transitions and animations. You still have to build your own controls (buttons, lists, edit boxes etc) on top of QGraphicsView and for this reason it can take a lot of effort to create an app. Orange Wednesdays is an app that was produced this way.

The very latest option being promoted by Nokia is to use Qt Quick and QML. This is built on top of QGraphicsView and allows for declarative (textual) based descriptions of screens. It’s possible (yet slightly convoluted) to communicate back and forth with Qt (c++) for times when you need to do more than QML provides. The latest Mobility APIs (1.1) also expose bindings that allow QML to access phone-specific features. However, Qt Quick and QML are still work at a lower UI level than many developers might expect. For example, you have to deal with things like rectangles and regions as opposed to buttons and text boxes. There’s a project to create higher level Qt Components but they aren’t suitable for commercial use at the moment.

Unfortunately, I haven’t, as yet, got the latest Mobility APIs (v1.1) working under emulation. They are supplied in source form and you have to first build them. I didn’t get that far and instead ended up with an error:

c:\qt-mobility-opensource-src-1.1.0\src\mobilitysimulator\mobilityconnection_p.h(50) : fatal error C1083: Cannot open include file:
‘private/qsimulatordata_p.h’: No such file or directory

I question why developers have to compile these APIs at all. Why can’t they be pre-built and included (and upgraded) via Qt Creator?

While Nokia’s Qt developer story, as told by Nokia executives, might seem ok at a high level, when you dig deeper there are some big issues for people wanting to develop now. The Qt tools have been a ‘work in progress’ for a long time now and it’s not possible to create applications with the ease provided by other platforms’ (or even Symbian Carbide) tools.