Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] How does this compare to the "official" flutter desktop? #191

StefanLobbenmeier opened this issue Jul 15, 2019 · 8 comments
guidance question User questions wontfix This will not be worked on


Copy link


I found this article on medium. From my understanding, that means that flutter has an official approach to flutter-desktop, what does this mean for the future of this approach?

Copy link

pchampio commented Jul 15, 2019

@GeertJohan and I are maintaining this alternative desktop embedder.

This approach has some benefits: plugins are way easier to write in Golang than in C++/Objective-C; and our API is easier to use for non-system developers. Those reasons are why we are maintaining such package.

The major drawback is that we aren't part of the flutter team. So at some point, if @GeertJohan and I stop maintaining this package, it is going to die.

That been said, the embedder is a relatively small layer between the flutter/engine and a rendering API (GLFW in our case). The flutter/engine ABI is stable, and shouldn't change too much. I don't think go-flutter will stop working; most of the bugs are fixed. The only deprecated feature we are using from the engine should be resolved by #175

My opinion is:

  • Your Flutter app works regardless of the embedder you use, official or unofficial?
    • Choose the embedder you prefer!
  • You have an issue with the 'official' flutter desktop
    • Give go-flutter a try, it's rare, but sometimes features are available in go-flutter before FDE.
  • You have to write a plugin:

Your core business logic is written in Dart; there is no cost in swapping the embedder!
The only waste you can make is: you have written a go-flutter plugin, and the go-flutter project suddenly stops working with the latest version of flutter, you have to throw your golang code and rewrite it into C++/Objective-C (Keep in mind that C++/Objective-C codes are usually more cost-heavy to develop and maintain).

To sum up,

How does this compare to the "official" flutter desktop?

Not that much, modulo some implementation differences, it's the same, but in another programing language.
You will have to use hover instead of flutter / export ENABLE_FLUTTER_DESKTOP=true because we cannot plug our-self into the flutter toolkit for building the embedder. Using the flutter toolkit or hover, your flutter dart code will be compiled the same way (with flutter build bundle)

what does this mean for the future of this approach?

At some point, FDE will have more feature than what go-flutter offers. I'm okay with that; we aren't google!
Also, more importantly, if you miss a feature from go-flutter and need to use FDE to have that feature, than go, it's basically free!!!

Edit1: what I was calling FDE is now part of flutter, it should now simply be called 'flutter desktop'.

Edit2: it's possible to write macos plugins in swift.

Edit3: Look at the below #191 (comment) to get the latest differences.

@pchampio pchampio added the question User questions label Jul 15, 2019
Copy link

@Drakirus I think the answer to this question would be great to have it linked in the README or in the Wiki. I also had this question when looking at the different desktop alternatives with Flutter.

Copy link

pchampio commented Jul 16, 2019

@davidmartos96 I have linked the question in the Wiki. Also, the README notices the user of the existence of a wiki.

Leaving this Issue open; If anyone has questions about this package, we will be happy to answer them!

@pchampio pchampio pinned this issue Jul 16, 2019
Copy link
Contributor Author

Thanks for the elaborate answer :)

Copy link

stuartmorgan commented Sep 13, 2019

[Edit: Updated June 2020 for current status]

A few notes, since there have been a number of changes since July 2019. (Please don't take this as criticism; I think your overview of the similarities and differences is excellent!)

  • it's the same, but in another programing language

    A substantial difference is that go-flutter-desktop uses GLFW, which is no longer used in any of the official embeddings. The official embeddings are now all view-based, which means they can be combined incorporated into a window containing native elements.


    This is no longer used.

  • your flutter dart code will be compiled the same way

    This is no longer true; release mode is now AOT rather than JIT for the official embeddings.

  • it's possible to write macos plugins in swift

    Not just possible, but the default.

  • Consider go-flutter, writing plugins in golang is way easier

    With the introduction of FFI, I don't know that there's a good argument for this any more. While some might find using Go as an intermediate layer between Dart and platform APIs easier than using C++ or Swift, now there's no need for either. A desktop "plugin" can in most cases be written now as a Dart package that calls platform APIs directly.

Copy link

@stuartmorgan is it possible to use go plugins from the official flutter-desktop-embedding repo? I'm assuming that's not in the project's goals.

Copy link

@phanirithvij go-flutter plugins aren't compatible with Flutter Desktop (used to be flutter-desktop-embedding) and Flutter Desktop plugins aren't compatible with go-flutter.

Copy link

stuartmorgan commented Sep 28, 2019

To expand on that a bit:

is it possible to use go plugins

Flutter plugin APIs are part of each embedding, not Flutter itself; there's no such thing as "go plugins" for Flutter in a generic sense, there are go-flutter plugins. The lack of interoperability isn't primarily about them being in Go, but that the APIs are not the same.

As one concrete example: go-flutter's plugin API appears to include a way of getting a pointer to the GLFW window. Flutter's embeddings have no GLFW windows, so it's impossible to use a plugin that expects one. The richer the plugin APIs become, the more of that kind of problem will exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
guidance question User questions wontfix This will not be worked on

No branches or pull requests

5 participants