Flutter Desktop - All 3 platforms are now ALPHA

Windows was Dev Preview. Now it’s Alpha, alongside with Linux and MacOs.

Web is Beta for some time now. Maybe it wasn’t evolved to Stable because some architectural changes being made to support Desktop could affect it. Maybe the PWA support intended to it is a growing not stable enough thing as architecture. Maybe when Desktop reaches Beta, Web goes Stable?
The plan before the pandemic was to reach December with Android, iOS, Web, Windows, MacOS and Linux working… But is “working” Stable? Or just Alpha or Beta?

The entire x-platform ecosystem is getting much much more crowded

When Google started the movement that Microsoft avoided as hell for the same reasons Apple avoids (not spreading apps to other platforms), Microsoft saw that they could not run away from the fight and lose it, as they did with the mobile systems. So now, Microsoft AND Google are the main contenders.

1 Like

Swift also recently made its way to Windows

it gets more interesting day by day

There’s no company supporting it cross-platform alongside with some official UI solution. Apple don’t want it and I don’t see signs of change.

For now I don’t see Swift as a serious cross-platform contender. Unless and until, someone comes up with an Xcode like IDE with a crossplatform version of AppKit/UIKit… without a consistent way to build a UI, the reset is just a mind exercise

Still no competition that can check all these boxes:

  • Create and complle X-plat MacOS/Windows/Linux desktop app with no dependencies (I believe?)
  • MacOS/Windows IDE (is there a Linux IDE?)
  • Drag/Drop UI designer with mostly native controls
  • MacOS app built, UI designed and debugged using Windows IDE, Windows app built, UI designed and debugged on MacOS IDE
  • Write app, click build, fully runnable app, no additional steps required
  1. Flutter/DotNet6 :white_check_mark:
  2. Flutter/DotNet6 :white_check_mark:
  3. Flutter currently needs an external designer, DotNet6 have XAML designer, both you usually don’t need it if you get used to insert components coding them with live rendering. :white_check_mark:
  4. Flutter :red_square: currently. DotNet6 :white_check_mark:
  5. Flutter/DotNet6 :white_check_mark:

Note: I’m talking about the mature position after September/2021.

so right now, excluding mobile, you have to compile on the target platform (mac for mac, win for win, lin for lin). although there is going to be some changes to that but I dont see a lot. Flutter/Dart uses Xcode on Mac to compile Mac. and uses MS’s compiler on Windows and Gcc on Linux.

Mobile, you have to compile iOS on a Mac (because of Xcode) and Android is anywhere you have Android Studio.

Technically there is not a drag-n-drop for Flutter. But you can use Adobe Err-Cant-Think-Of-It org Figma or there is a 3rd Graphical Designer that you can export the drawings into Flutter code. And supposedly the auto code generation doesnt suck. I dont use those tools as I suck at them so I cant say for sure.

One benefit of Flutter/Dart is you can use whatever editor you want (within reason). I use VSCode but I know people that use Android Studio or VIM or NotePad++ or whatever. Both VSCode/Android Studio/IntelliJ editors have nice built in functionality that makes coding easier.

as for WIndows being “Alpha”… yeah… I would still say “Early Alpha”… Macos/Linux is still more mature. But that being said, Google is working hard at making Macos/Linux/Windows on equal footings.

And as an example. I wrote a simple App that works on both Macos/Linux for a friend of mine and he asked if I could do Android. The only thing I had to do was do different screens as the layout I designed for desktop would not scale/resize down to mobile nicely. then I have an inline if statement that checks for being on mobile and returns either the mobile screen or desktop screen. I can compile it for iOS but they dont have any iDevices.

I have consider getting a Pine64 Pro Book (think raspberry pi notebook the weight of a chrombook but with a real o/s on it) and doing flutter dev work when not at home on it. unless I am compiling I need almost no (cpu) power. but I have been good so far and held off on buying one.

@Rick.A yes there is a third party one but not an official one. Nothing that is supported by google.

#3 really doesn’t merit a check mark for Flutter. You flatly admit Flutter does not have a UI designer, and Flutter doesn’t use native controls at all.

I’m a big fan of Flutter, and Dart, but it will never produce truly native applications and even by September 2021 the desktop applications will likely still lack a lot of the integration with the native platforms that you get with Xojo, and most of the integrations that are available are plugins written by a random lone developer who may or may not provide timely support, and knowing how to fix or create plugins yourself requires knowing a fair amount about the native languages (Swift/Objective-C and/or C# and/or C++) and frameworks. It’s not as friendly as Xojo, not by a long shot, and won’t be for years.

That said, I’m placing my long-term bet on Flutter and Dart. It seems to be a considerably better option than continuing to bet on a small (very small) closed-source company that’s trying to support every platform in the world with only four developers*, a company with a decades-long track record of letting their desktop platforms stagnate while they repeatedly indulge in over-promising and dramatically under-delivering on everything else.

*Geoff’s contention that Xojo is appropriately staffed is a sick joke and everyone knows it. Given their wild ambitions, they’re understaffed by at least an order of magnitude.

1 Like

Nor true. I don’t see a “needs to be integrated” in that topic. So I filled the gaps. And Yep, the new engine allows mixing pixel perfect and native ones.

For example, you could do this if you wanted in Windows:

typedef MessageBoxNative = Int32 Function(
    IntPtr hWnd, Pointer<Utf16> lpText, Pointer<Utf16> lpCaption, Int32 uType);
typedef MessageBoxDart = int Function(
    int hWnd, Pointer<Utf16> lpText, Pointer<Utf16> lpCaption, int uType);

final user32 = DynamicLibrary.open('user32.dll');
final MessageBox =
    user32.lookupFunction<MessageBoxNative, MessageBoxDart>('MessageBoxW');

final result = MessageBox(
    0, // No owner window
    Utf16.toUtf16('Test message'),   // Message
    Utf16.toUtf16('Window caption'), // Window title
    0 // OK button only
    );

You could do that, but (a) you’d be writing native Win32 code, which is not at all the same thing as drag-and-dropping a native control onto a form in a UI builder, and then you’d have to write completely different native code on MacOS, and completely different native code on Linux, which requires you to know a fair amount about three different non-Dart languages and three different non-Flutter platform frameworks, and you just have to hope all the controls work roughly the same on all the platforms or else get into some tricky and tedious modifications; (b) this is merely a mechanism (and an onerous one at that) to inject an occasional native control into a Flutter app, and there will likely be issues with how smoothly the native controls interact with Flutter widgets, memory management in some cases, and so on.

C’mon, that’s not within a thousand miles of what it means to have native controls in Xojo.

And having a few very primitive UI designers tossed together by random third parties with dubious support, designers featuring a variety of interesting ways of kinda-sorta generating Flutter apps, is also not even remotely the same experience as using Xojo.

Yep. That’s why I do prefer using the “Flutter native” ones.

Is this a good thing?

1 Like

Yes, of course it’s a good thing. The Xojo UI builder is far more polished and completely integrated with the language, framework, and IDE. It’s obviously a much better experience than using a primitive experiment of a UI builder thrown together by some random third-party.

1 Like

I think they have 5
Travis, Greg, William, Javier & Paul
Otherwise totally agree

Oh. Good. Then they only need about 35 more to have a realistic chance of building an adequate development tool for MacOS, Windows, Linux, iOS, Android, and Web.

2 Likes

5 definitely doesnt leave a lot of room for overlap between team members expertise levels, framework familiarity, etc

More engineers have been needed from a long time IMHO

They have their reasons for not expanding the team but I cant say anything more

Well… Firstly Xojo is far from “polished” and have half dozen of half baked components, second there’s not just that website that uses a free code published on github as a helper for those needing it, you could play with it if you wished for and even write your own version. It’s open. For the side of “I prefer to use some tooling backed by a large company” Is Adobe good enough for you as a partner for such task? They are creating visual tools for Flutter. Third, it’s optional using such tools, you mostly don’t need them.