Announcing preview FlutterFire support for Desktop & Dart

Earlier this year, Flutter announced an early release of Desktop on the stable channel, which was a huge step for its ambient computing vision.
FlutterFire is the official Firebase packages for Flutter apps, most of which currently support iOS, Android, web, and macOS, but for all of them, Linux and Windows platforms are missing.
There are some challenges behind getting Linux and Windows support to land quickly in the FlutterFire family, which we will briefly talk about in this blog.
Today, we at Invertase, with support from Canonical, are happy to announce that we kicked-off the work
on adding Linux and Windows support to the family, in addition to Dart-only apps.

MacOS is there, why not Linux and Windows?

For a while now, some of FlutterFire packages started supporting macOS, yet none has any support for Linux or Windows.
The main reason for that is macOS uses the same Firebase iOS SDK with very little conditional difference between the two, while there’s no SDK for Linux and Windows.
Consequently, we either have to use the Firebase C++ SDK or build a Firebase Dart SDK.

The C++ SDK seems like a good solution since everything is implemented and we just use the method channels to implement the packages.
Nevertheless, it didn’t sound like a good experience for Flutter developers, since the prerequisites to install the C++ SDK
for desktop puts additional hassle on FlutterFire users, hence a harder developer experience.
Eventually, since the goal is to build for Flutter, we decided to go with a Dart-only approach, by using Google REST APIs for Firebase and build a universal SDK from scratch using Dart.

A pure Dart SDK for Firebase

All FlutterFire packages are structured as follows:

1. The platform interface package, collection of abstract classes and methods to be extended.
2. The main package, which supports iOS, Android and macOS and extends the platform interface.
3. In addition, if it supports web, there’s a separate endorsed web package.

Let’s take firebase_core as an example, it has the following structure:

|_ firebase_core
|____ firebase_core // you only import this
|____ firebase_core_platform_interface
|____ firebase_core_web

Both firebase_core and firebase_core_web are using the underlying Firebase platform SDK for iOS, Android, macOS and Web, while extending firebase_core_platform_interface to keep the same interface.

The approach followed was to extend the platform interface in a _desktop package, e.g. firebase_core_desktop, and this will have dependency on Flutter since all the FlutterFire **_platform_interface packages depend on Flutter as well.
Because of that, the desktop package will delegate the internal implementation to another package, which is purely written in Dart with no dependency over Flutter or any plugin that depends on Flutter, e.g. flutterfire_core_dart.

So saying it’s for Desktop means it supports macOS?

Dart is cross-platform, and the Dart SDK will run on desktop and mobile as well with no issues.
A future goal behind this approach is to have a set of FlutterFire packages built for Dart apps, independently of the platform.
P.S we’re using macOS for the development part though it’s not a targeted production platform.

How the Federated Plugin system helped make it possible

Back to the packages structure, it’s following the federated plugins system in Flutter.
A federated plugin helps solving the problem of platform support for a package without compromising the package API, and allows using separate packages for different platforms.

Refer to the official document to understand more about Federated Plugins implementation.

This system helps making the Desktop packages available for Linux and Windows platforms without touching the main packages or repo of FlutterFire.

Let’s take firebase_core as an example, it already has a platform interface and supports iOS, Android, macOS and Web.
To tell FlutterFire to use our Desktop package as the platform implementation for Linux and Windows, we followed these steps:

First, a small change happened in the main FlutterFire package side:

1. Added the desktop package as a dependency in firebase_core pubspec file.

dependencies:  firebase_core_desktop: ^0.1.1-dev.0

2. Added linux and windows platforms.

linux:
  default_package: firebase_core_desktop
windows:
  default_package: firebase_core_desktop

This is what we mean by saying making a package available as a platform implementation of another package.

On the Desktop package side, pubspec will implement the main package, and specify that the instance to be registered for Linux and Windows is a dartPluginClass, not a native class like in Android, iOS and macOS.

flutter:
      plugin:
      implements: firebase_core
        platforms:
          linux:
            dartPluginClass: FirebaseCoreDesktop
            pluginClass: none
          windows:
            dartPluginClass: FirebaseCoreDesktop
            pluginClass: none

Lastly, in the main Dart class, a registerWith method is added.

class FirebaseCoreDesktop extends FirebasePlatform {
  /// Called by PluginRegistry to register
  /// this plugin as the implementation for Desktop
  static void registerWith() {
    FirebasePlatform.instance = FirebaseCoreDesktop();
  }
  ...
}

As a result, FirebaseCoreDesktop will be automatically be registered as the platform instance when the app is running on Linux or Windows.

Current progress & what’s next

We started with firebase_core, and firebase_auth, since most other packages and use cases of Firebase will require these two.

• Core is almost fully implemented.
• Auth has the main structure of the API ready, most of the user functionalities, and the following sign-in methods: password and anonymous.

FlutterFire will soon have a release to make these packages available for Linux and Windows under the development tag.

What about other packages?

The project is currently in a very early stage, and we don’t have a clear plan for other packages from the FlutterFire family yet,
but we will keep building in public, take feedback and discuss different solutions for the current challenges,
so we cannot wait to hear from you and see your contributions!

• FlutterFire Desktop repo link.