WeGo 4.X, not just a new look

In the software development world, the creation and distribution of “major” releases of a product (no matter if it is an app, a website or a service) always comes with a unique set of opportunities, challenges, and requirements. Below, I will summarize how we approached creating the new version of HERE WeGo 4.X.

From a user's perspective, this latest release might just "look different” in comparison to the previous one because of a change in the UI or the addition of new functionalities, while everything else is expected to work exactly as it did before. When we started the development of HERE WeGo 4.X we knew that the challenges and the requirements on the table were not only technical. The app had a massive user base of loyal users that relied on it in their daily life, and we had a clear responsibility towards them. At the same time, the industry had moved forward, bringing up innovative technologies, novel approaches, new opportunities. 

It was during 2019 when a couple of colleagues, Daniel Rolf and Raul Cajas, started exploring how to leverage the latest and greatest of the technology available on the market, together with the latest and greatest of the HERE platform, to give HERE WeGo a new design and a new core. Quickly after that, a new small team of a dozen of individuals was established to build up on this initial idea and, making clever use of the learning from the previous years, in January 2020 the alpha version of WeGo 4.X was presented at the CES in Las Vegas: 

After ingesting and converting the  feedback received at CES in lines of code, in October 2020 the public beta version of WeGo 4.x was launched for both Android and iOS. The main purpose of the beta version was to interact with both old and new users by establishing quick feedback loops, powered by biweekly releases. Finally, in March 2021, WeGo 4.x started to progressively rollout to the existing user base of millions of users, bringing us to where we are today. Let's look what's under the hood.

A multi-platform project, a single team 

When we started the development of the new HERE WeGo, we had to make many decisions, the most fundamental one being: do we develop two apps or one? HERE WeGo is available for Android and for iOS. Previously, these were two different apps with completely independent implementations. Every new feature had to be implemented twice, once for iOS and once for Android. There were subtle differences in functionality and not all features available on one platform were available on the other. 

Starting two new apps from scratch in parallel seemed inefficient right from the start, so instead we were looking into cross-platform toolkits that allow to write one common application for multiple platforms. Earlier cross-platform toolkits like Phonegap (now Apache Cordova) gave cross-platform development a bit of a bad reputation due to not looking like native apps, being slow and not well integrated with the phone's capabilities. Also, from the developer perspective, apps written with these toolkits were more difficult to write and harder to debug. A more modern approach we evaluated was Kotlin multiplatform which, despite being quite appealing from the language capabilities and vibrant community perspectives, was not giving enough advantages on the UI toolkit side.  

Luckily, in 2017 a new contender entered the scene: Flutter, which claimed native performance, fast development and a flexible and easy to develop user interface definition. After an initial exploration, a PoC was developed, and it was working like a charm: a single project, a smooth interactive map, a common Material Design UI running on both Android and iOS devices? Deal! 

Fast-forward to today: the new WeGo is entirely written in Flutter by leveraging the HERE SDK 4.x for Flutter and is developed by a single team of quite “diverse” engineers coming from different backgrounds (iOS, Android, Web). There is only one codebase, one SDK, and all the engineers contribute by features, not to platforms. WeGo releases happen on the same day for both Android (Google Play, Huawei AppGallery, Samsung Store) and iOS (App Store), and they contain the exact same features (beside the platform specific ones, like CarPlay for iOS or Samsung Gear Watch for Android). 99% of the WeGo app lives in Flutter/Dart. 

Developing HERE WeGo in Flutter

Developing in Flutter comes with some challenges, which can be summarized in the following categories: 

Platform specificity 

Android and iOS platforms often implement the same features in different ways and can offer completely unique features. Luckily, neither of these is a blocker for Flutter, but some work is required. 

• “Different platforms, same features”: usually covered using Flutter plugins that expose a common interface in Flutter by leveraging platform specific code (e.g., accessing the Location service to obtain the user location). It’s very likely that, no matter what platform functionality you need, it’s already having a dedicated plugin listed on https://pub.dev/, check it out! 
   
• “Different platforms, different features”: Usually covered by using a Flutter plugin or simply via a MethodChannel to communicate with the native platform to offer a feature only on that specific platform (e.g., supporting CarPlay for iOS, or Android Auto for Android).  

Performance 

By design, Flutter can be seen as layer on top of the native application, which renders using its own renderer (making it more similar to Unity rather than React Native). This design implies that the initialization time (or startup time) of a Flutter app will be usually slower than a normal native app (given the extra initialization needed for the Flutter engine). However, runtime performances can be absolutely comparable to native apps: it will depend on how well the performance best practices are followed and, of course, on the kind of task the app must execute. 
If your app is making use of C/C++ libraries as well (like WeGo and the HERE SDK 4.x), Flutter can provide an extremely effective multi-platform interface through Dart-FFI, a fast Dart -> C -> C++ dual way communication channel. 

Look & Feel 

The most debated topic, and probably the most perceivable by the users. Flutter comes with its own UI toolkit which reflects Google’s Material Design specification. This means that a standard Flutter app will “look different” than a standard iOS app, whilst it will look pretty much identical to a standard Android app. Even though Flutter offers a Cupertino version of its Widgets (miming the iOS look & feel), providing different pixel-perfect UIs for Android and iOS diminishes the benefit of using Flutter in the first place. For this reason, the new WeGo adopts a single, unified style and a common design system for both Android and iOS. 

Ready to get started with Flutter? 

If you are looking for a solid solution to build your multi-platform map apps using Flutter, check out the HERE SDK 4.x for Flutter and give it a try: 

• HERE SDK for Flutter (Explore Edition) 
• HERE SDK for Flutter (Navigate Edition) 
• Examples

Looking for your feedback

The team is eager to get feedback from regular and new HERE WeGo users and there are many ways to connect with us: 

• Via the feedback function within the app 
• By sending a mail to our support team at: appsupport@here.com  
• By connecting with us on Twitter @WeGoApp