Should You Build For Windows, Mac, IOS, Android, Or Linux? Yes!

The holy grail of computer languages is to write code once and have it deploy effortlessly everywhere. Java likes to take credit for the idea, but UCSD P-Code was way before that and you could argue that mainframes had I/O abstraction like Fortran unit numbers even earlier. More modern efforts include Qt, GTK, and other things. Naturally, all of these fall short in some way. Now Google enters the fray with Flutter.

Flutter isn’t new, but in the past, it only handled Android and iOS. Now it can target desktop platforms and can even produce JavaScript. We haven’t played with the system enough to say how successful it is, but you can try it in your browser if you want some first-hand experience.

Flutter uses Dart and support for the Mac and Windows is considered alpha quality. If you know any traditional language like C++ or Python, you won’t have any trouble with Dart.

If you want to read about someone’s experience deploying something substantial with Flutter, here’s a full-blown app with a very detailed report. Will Google get it right? Certainly, they are big enough that they should. However, as anyone who has tried to deploy across platforms will tell you, it is much easier to solve the big problems than the little ones. You usually die from a thousand paper cuts on cross-platform projects, not from a single sword stroke.

Google says they want Flutter to target embedded devices, too. We are pretty sure they mean embedded in the sense of fairly powerful processors with a UI and an Internet connection. But maybe we’ll see other platforms in the future. After all, we’ve seen plenty of stripped-down Java virtual machines with the same goal. We’ve even dug into the intricacies of cross-platform programming, ourselves.

36 thoughts on “Should You Build For Windows, Mac, IOS, Android, Or Linux? Yes!

  1. “Google says they want Flutter to target embedded devices, too.”

    No, I’m sure Google means devices embedded in brains, so they not only can monitor every thought and action, but control them as well. Flutter is just an intermediate step.

    1. I created BridgeScript language ( ) the syntax is similar to C language and it does not have any built in APIs, it can run on any platform ( processor/OS) , you can try it on Windows as part of Visual debugger for free.

  2. problem with languages like this (historically) is they are not a one and done, its magic is done though interpretation or virtual machines. USCD Pascal on a (lets say) Apple ][ is a horrid experience in terms of performance… Likewise the rise of java on 386-Pentium machines left a ton of power on the table.

    With arm based devices you learn to accept the thicc layer of resource usage and with an interperted system like this only make simple applications. Add in the horsepower of X86 and more or less unlimited wattage to bully your way into code is having something that’s best example is a lipstick color changer on par with 1990’s hypercard to make me go


    and before some numbnuts tells me to think outside the box, to them I say show me more than a text and picture slideshow

    omg I just barfed a little

    1. It would be nice if there were some kind of close X scopes/expressions operator.
      Or close until scope depth < level.
      Or a way to tag parentheses.

      _() -= 9; // close nine
      _() *= 0; // close all
      _() = "_MyAppState"; // close until named scope is reached

      Although the last one would be longer than the character sequence is it meant to replace, it might be worth using just to reduce the brittleness of large piles of closing parens.

      Fun to imagine the possibilities anyway.

      1. The kind of bugs you could get from something very occasionally escaping a for loop because you’d misclosed a seldom-positive if/then incorrectly in mass-closing a whole bunch of brackets… I mean, I guess that’s already a problem but right now the compiler catches it, and the temptation to say oh well I closed 8 and I meant to close 9 so I’ll just close 9 instead would be very high.

    2. The purpose of these high level languages and frameworks is to enable rapid development of cross platform Apps that are analogous to the dime-a-dozen websites we have today. Similarly there’s plenty of no-code and low-code solutions to enable development of business processes and logic. You don’t need to be writing BLLs and BSLs in assembly, C or Rust.

      An example, if you were creating Shazam you wouldn’t use Flutter to implement your audio pattern matching logic, just the front end you need on all of your platforms. You’d implement your backend and lower level code in something lower level.

      You can be a drama queen all you want about it but not every developer is a Dennis Richie or Donald Knuth.

  3. Considering Google’s tendency to smother its babies in their cribs (, I think I’ll pass on putting any effort into learning and writing code in something that’s going to get axed two years from now.

    Why no, I’m not bitter about buying a printer solely for its Google Cloud Print support. No sirree…

    1. I with you there. It’s bad enough to be out some $$ on a personal purchase, but imagine incorporating this into a business process and Google pulls the plug. The stuff that persists is whatever gets them more information ant their track record doesn’t inspire confidence.

      1. Out what, for something that’s a firmware change away. At least my VoIP and printer device are both usable despite Google Voice and Cloud print being a change absent because they also embraced standards.

  4. “. We are pretty sure they mean embedded in the sense of fairly powerful processors with a UI and an Internet connection.”

    Why is that??? Rust is running on STM32M0 devices, powerful interpreted languages like javascript also run well on tiny ARM cores.

    No doubt you have forgotten or maybe you are too young to remember that interpreted languages like perl and TCL ran just great on Sun 3 workstations that were far less powerful than the $3 blue pill devices you can get on ebay.

  5. The (still small, under development) social networking site okuna was released to desktop as a flutter app by one of the developers after initial development on android, and it worked quite well. I hadn’t previously heard of flutter, but was impressed by its performance.

  6. Every time I see Google attached to ANY project my initial reaction is always: “I wonder how long until they add cloud based metadata collection as a requirement for functionality”. They are a data harvesting company, that sell ads.

  7. Google will deploy it . It’ll half-way work for awhile. Then just when enough people are using it to make it important, Google will abandon it. In the end that’s OK though, it turns out Google was using it to spy on the users. Good riddance.

    1. Well, that went south pretty quick. Who knows, maybe you just saved them years of development .
      I have to agree that Google doesn’t invest much in the free stuff. If there’s a way that it will support their future business then it will grow. I do see how they could use this to leverage existing IP to the new rumored OS that will replace AndroidOS.

  8. Well, there already are plenty of multi-platform libraries for existing languages, for example i can reach pretty much any device with a display that runs something more substantial than Jimmies GarageOS with libSDL and good old C. And even Jimmie might port libSDL to his toy OS one day.
    Why create another layer on top of all the other layers if one layer next to the graphics driver is more than enough?
    Why use interpreted languages when you can code in blistering fast almost machine language C? If i use an interpreter i want to so simple to use that i don’t need any boiler plate to do things. Check good old BASIC for an example. _That_ is simple to use.

    1. Obviously because of developer adoption, as there are only few C but thousands of js or soon to become dart devs. for them it is a way to increase adoption of dart, therefore a smart move to create a performant replacement for trainwrecks like react native. still google though.

  9. Qt falls short? Are you serious?! It runs on more platforms: all mentioned + iOS + MCUs and your Browser and support is not in alpha state. It is very powerful, has lots of extension libraries for all kinds of stuff, supports 3D graphics with different backends, video, audio, bluetooth, you name it. You use it with C++ 11/14/17 (20 even), which is a great language that lets you create stuff fast. It also comes with a great IDE if you want that supports deployment to target devices.
    How on earth is it falling short?

    1. I also like Qt. However, my gripe is that the author seems to imply that Java predates it, which it does not. GTK is also just as old as Java. I think it’s kind of weird to describe Qt and GTK as “modern efforts,” when both technologies were mature products since mobile existed.

      1. hmm java first released 1995 with AWT less than a year after GTK first released 1998 thats 3 years or a VERY long time.
        QT is also 1995 (I remember needing it to build KDE at the time).
        What all these fail with is when it comes to abstraction.
        Running a GTK app inside a QT env feels wrong as the abstractions are wrong. Java with the native look and feel still needed lots of cote to make it *act* native and the closer they get to the native env the bigger the uncanny valley.
        Common code for data and logic proper native for UI built by native who use the platform is always better

  10. There’s something that everyone hates but that runs everywhere: html css and javascript. It has pretty good engines everywhere (just compare to where we were in 2000), can adapt pretty well to different devices and has more documentation, libraries and developers than anything else, and you already have an engine running in almost every device you own. Yes electron takes a lot of resources, yes webviews come with their own little quirks, yes it’s dificult to have a native look and feel, but I think that solving these problems would be a lot easier than creating a whole new ecossystem with a new programing language.

  11. Haxe ( has been doing this for over a decade and really nicely too. Haxe targets different languages, but has middle ware libraries that target desktop (all three), android, ios, etc from one code base, such as OpenFL, Kha, NME, and so on. Give it a play.

  12. Flutter is set of different compilers, so resulting code is binary x86, arm, or js. UI will be painted on low level “canvas” implementation. So no VM as Java, fast and clean.

  13. “Hey
    .. let’s all f off on all the algos and EMBRACE ANTI-PATTERN TROPES!!!! we can keep reinventing the wheel before its complete 1000000 times..”

    He!, no. We are done. We knew the languages. We were the pillars. We gave you Python and Javascript. You couldn’t even handle…Plan 9!!!!

    Incomplete IDIOTS! You had the perfect synchronized OS.. but you wanted… more . You wanted Drama. And Stupidity. And Rust.. and more Challenges.. and threw out ALL the “cookbooks” you wanted unicode.

    F this NOISE and this dumb future. May you all type “hello world” until you collapse.

    P.s. Ground control systems still use Erlang to land the planes. You will probably be the permanent disappointment. Until the end. Of the days.

    Get over yourselves. Pulse Audio, Ruby on Rails and SystemD are STILL GARBAGE.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.