Porting the Flemish news app to Flutter
A retrospective overview of how we recreated the VRT NWS app in Flutter.
VRT NWS is part of Belgium’s national media VRT.
The VRT NWS brand serves as their news app. On a daily basis it serves 350,000 active users.
Which means it is in the top 10 news apps in Belgium.
Analytics showed the future is in mobile and our stakeholders decided it was time to revamp the existing native app.
How did we end up deciding for Flutter 💙 and how did we experience the switch? With this blogpost we hope you pick the right tool for the job.
tl;dr Download our public beta for either Android or iOS and leave your feedback.
Back in time
How did we end up choosing Flutter, an emerging new cross platform technology, for our most important visible app?
In order to get the full picture we need to understand where we are coming from.
Deredactie.be (2015 — 2017)
In March 2015 we launched our first mobile news app.
At that point it had been in the making for over a year.
Prior to VRT NWS, Deredactie was the official brand name.
The app was very simple and straightforward.
An endless scrolling list served the latest headline articles.
You could read offline thanks to an internal database.
In the hamburger menu you could easily switch between categories or even rewatch your favourite VRT NWS tv shows.
Even though the app worked incredibly snappy, it also had some considerable downsides. The most important ones were:
- Editors worked in a website environment unknowing how things would look in the app.
Every website component needed to be ported to a native component.
This not only took way too much time, but often times did not look completely similar to the website.
Even worse: web embeds simply did not render in the app.
This was frustrating not only for the editor, but for the end user as well. - The endless scrolling list meant the app was hard to navigate to retrieve your relevant content.
- Deredactie app talked directly to the CMS at the time.
The CMS output was suboptimal for mobile use. This resulted in a lot of business logic in both iOS and Android to get the correct data.
VRT NWS Rebranding (2017 — 2019)
In August 2017 we rebranded deredactie to VRT NWS.
2017 was an important year, not only did we rebrand, we switched to a new CMS (AEM), moved to the cloud (AWS) and overhauled our site and app.
The rebranding allowed us to start from a blank canvas and learn from our mistakes.
We again agreed for native development to ensure a responsive feel.
- However we opted for WebViews in our article details. This alleviated the problem of creating native component for equivalent web components. Thus cutting development costs.
- A better navigation pattern; We split up our main app in to 3 sections.
Headlines — , most recent — and popular articles.
A bottom navigation gives you access to videos, audio (podcast) and ‘discover’ which houses our in depth articles and explainers. - AEM allowed for easier transformation of the output JSON.
We installed a small backend between our CMS and our app which transforms the dirty CMS JSON to ready to use JSON in the app. Minifying the need for data processing on the clients.
Internally this is known as the Backend for Frontend or BFF.
Despite of catering to the concerns of the preceding deredactie app, we created new problems:
- Turns out WebViews are not loved by the end user:
“The app is slow!! 1 star” “The app does not load! 1 star”
We improved the mobile web performance significantly during the first months of our release, but nothing beats instant, native article details.
These comments have stabilised, but it’s still an eyesore. - The switch to AEM meant our editors now had access to a WYSIWYG interface where you can drag and drop components on a canvas.
This works perfectly for our app detail screens (WebView), but not for our native screens (headlines, recent, popular).
The app decides its own layout by a complex set of rules, of what we initially thought was well thought out.
As more AEM components emerged, it was not future proof. Business wants more flexibility and configurability with one single source of truth: AEM.
To make matters worse as time passed by the Android and iOS implementation drifted apart. - Native is slow in development and costly. It became increasingly more difficult to justify building a feature for both Android and iOS.
- Due to circumstances our iOS code base became increasingly more difficult to deliver features in time. This gave the impression app development was stalling.
Flutter VRT NWS (2020 — …)
Fast forward to June 2019 and the editors now have a lot of web components to style the site.
The current production app however only features about 2–3 different types with minimal difference.
Needless to say a lot of UI structure gets lost.
We knew we were put up for a challenge and were tasked to come up with a solution to following problems:
- When the editor designs the home page the app should look similar to the site structure.
- The editors maintain one homepage for the site. The app should adapt accordingly.
- Our single source of truth should be AEM.
In order for our frontend to be more flexible we decided our BFF was now required to forward the UI structure from AEM to the app.
Besides the obvious data payload the BFF is now also responsible for sending text size, which font to use, colors and so on.
Together with our designer, product owner, team and business we identified a set of components for the app
Effectively this meant our entire current JSON structure would drastically change. Furthermore our entire current data retrieval and view logic was now obsolete.
In the end this meant we were to rewrite the app once again.
Enter Flutter
It became more evident the next phase for this app was going cross platform.
As a team we played with different cross platform technologies before and always came back disappointed.
However Flutter felt, … different.
It proved to be a very potent candidate for our use case.
Our app has minimal use of true native features:
- Push notifications with custom notification rich push
- Background work; We periodically fetch the latest articles in the background.
- Today Widget (iOS only)
- Custom Video Library
- Analytics
To make matters even better there are no notable visual differences between our Android and iOS app.
Proof Of Concept Time
We wrote down a few potential bottlenecks to try and see how Flutter handles them before deciding. In particular we were really interested in the handling of WebView embedded within Flutter and Accessibility.
Not only that but how difficult was it to bridge the native feature listed above inside of Flutter?
We were pleased to see Flutter had support for both native views and accessibility.
Bridging required a bit more manual effort to implement. Since Flutter is quite a new platform popular libraries like Adobe Analytics did not have a Flutter counterpart.
Together with our custom libraries for our video player and other in-house analytics we quickly made a few reusable Flutter packages.
We even open sourced a few libraries and became a verified publisher.
Dart
Dart was a bit of a mixed bag for us.
Coming from Kotlin and Swift it felt like a step back in terms of language features.
However Dart is so similar to Java the switch was easy enough to be fully proficient within a week. The addition of the async/await is indispensable.
Another big plus is the great tooling support in IntelliJ!
We are convinced Dart is THE language that makes Flutter work like it does.
Without Dart no Hot Reload would be possible and there is no way adding that extra semicolon at the end of a line is that much of a burden.
Google knows Dart has to catch up and are making efforts. For example in Dart 2.3 they added the spread operator, support for if’s and fors in collections and not to mention the recently introduced extension support and the upcoming nullability support.
Overall:
No blogpost about Flutter is complete without mentioning Hot Reload. Coming from native development where waiting 2 minutes for a minimal change was commonplace, Hot Reload really stole everyone’s heart ❣
There is something about changing a value hitting save and immediately seeing that change happen on screen which sparks joy in every app developer.
The framework itself compared to native felt a lot less bulky. Not carrying so much cognitive load.
Creating a list of items is effortless in Flutter (like it should be), compared to on native side were you would first need to know all about recycling, adapters, views, lifecycles, item separators, item animators, … and then I intentionally forgot about Fragment and/or Activities.
The fact that everything is a Widget threw us off a couple of times, but we completely embraced this new paradigm.
It’s no secret Google turned to React Native for this idea, but Google perfected this by the vast set of built in Widgets which are dead easy to customise to business liking. This helped us to move quickly and create working mockups to show to business.
The tone was set; App development did not need to be slow nor expensive in the meantime we have already started to rework other VRT apps to make use of Flutter.
Beta
As a bonus we want to invite anyone interested in testing the bèta version of the VRT NWS Flutter app
Android:
iOS:
Thanks for reading.
We are hiring!
Check out the job description:
https://jobs.vrt.be/nl/job/flutter-ontwikkelaar-vrt-nws-freelance-151243
