Fruits of my recent search for a cross-platform ui toolkit.

Brian Sturgill c.brian.sturgill at gmail.com
Mon Dec 18 20:10:54 UTC 2023


Primary Criterion: Must work on Linux, Windows and MacOS desktops.

I want to use this to make open-source desktop apps.

--

# What I believe about cross-platform UIs as of 2003-12-18.

Cross-platform and cross-language:
    wxWidgets: (Windows, Linux, MacOS, *BSD)
        https://www.wxwidgets.org/
        Uses native controls, bindings in a huge number of languages.
        It lags on mobile, iOS in progress.
        Apps feel dated, even though wxWidgets take steps to use latest
            controls on Windows.
        Linux toolkits support is great, but alas, those toolkits are also
            looking dated.
        Haven't done recent measurements, but is rather fat (disk/memory)
            unless you are using it directly in C++.
        Basically you have a language, wrapping a huge toolkit, which
            wraps native controls. It kind of has to be fat.

Dart only:
    Flutter (Windows, Linux, MacOS, iOS, Android)
        https://flutter.dev/
        Does not use native controls.
        Most modern looking of all the options.
        Has the smallest runtime to lug around.
            (Still not that small - 20M on Linux).

Dotnet only:
    (These obviously have to deal with the rather large .NET runtime.)
    Avalonia (Windows, Linux [Gtk], MacOS, iOS, Android)
        https://avaloniaui.net/
        Does not use native controls.
        If you liked Microsoft's WPF, you want to look at this one.
        Alas, doesn't seem to be nearly as popular as I think it should be.
    Microsoft MAUI (Windows, MacOS, iOS, Android)
        https://dotnet.microsoft.com/en-us/apps/maui
        MacOS "support" is really just for iOS app on MacOS.
        Uses native controls.
        Windows support is said to be buggy. (Shocking, really.)

Python only:
    (These obviously have to deal with the huge Python runtime.)
    (Remember that Windows and maybe even MacOS will need Python to be
installed.)
    (One would have to seriously consider using venv for app distributions.)
    Kivy
        https://kivy.org/
        Does not use native controls.
    BeeWare
        https://beeware.org/
        Does not use native controls.

Java VM:
    (These obviously have to deal with the rather large Java/Kotlin/Compose
runtime.)
    JetBrains/compose-multiplatform (Windows, Linux, MacOS, Android)
        https://github.com/JetBrains/compose-multiplatform
        Is Kotlin based (from JetBrains). Uses Google's Jetpack Compose.
        iOS support is in alpha.
        This toolkit has not really taken off yet, but it could.
        I am not certain, but it seems not to be using native controls.
        However, it appears you can use some native controls with the
        toolkit.

     There are a number of older toolkits, AWT, SWT, etc. but none seem
     to have really gained traction.

Notes:
    Native controls yea, or nay?
    Native controls behave exactly like the user expects and blends in well.
    Not using native controls reduces bloat, gives pixel perfect accuracy
    across platforms and often is faster. (Native controls sets have gained
    bloat with time.)

    Most popular for mobile is 1) Flutter, 2) MAUI.
    React Native, Phone Gap, and Cordova are being left behind.

    I personally (for my open source desktop app work) am going with
Flutter.
    My second choice would have been wxWidgets, not sure what language
though.

    I will be using Material Design with Flutter as most people have seen it
    and it doesn't look like any of the native platforms. Looking _like_
    native when you're not, often leads to confusion.

    I don't consider JavaScript things here. They are all quite bloated.
    Their popularity has decreased rapidly in recent times.
    Electron is still the leader here if you want to go that route.
    (Before going there, take a look at the memory footprint of VSCode or
Atom.)

    Also, not included is React Native which is complicated.
    It isn't really "native" in any meaningful sense.
    It was heavily used for a while but has been declining.

    I am only considering open source solutions here, so Qt is not
    included (not free outside of Linux).

-- 

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nclug.org/pipermail/nclug/attachments/20231218/f271ff87/attachment.htm>


More information about the NCLUG mailing list