Google Bridges Android, iOS Development With Flutter 1.0 (arstechnica.com)

Google has launched Flutter 1.0, the first stable release of its open source, cross-platform UI toolkit and SDK. "Flutter lets developers share a single code base across Android and iOS apps, with a focus on speed and maintaining a native feel," reports Ars Technica. From the report: Flutter enables cross-platform app code by sidestepping the UI frameworks of both Android and iOS. Flutter apps run on the Flutter rendering engine and Flutter framework, which are shipped with every app. The Flutter platform handles communication with each OS and can spit out Android and iOS binaries with native-looking widgets and scrolling behavior if desired. It's kind of like applying a "video game" style of development to apps: if you write for a game engine like Unity or Unreal, those engines are packaged with your game, allowing it to run on multiple different platforms. It's the same deal with Flutter.

Flutter apps are written in Dart, and the SDK offers programmers nice quality-of-life benefits like the "stateful hot reload," a way to instantly make code changes appear in the emulator. For IDEs, there are plugins for Visual Studio Code, Android Studio, and IntelliJ. Apps come with their own set of Flutter UI widgets for Android and iOS, with the iOS widgets closely following Apple's guidelines and the Android widgets following Google's Material Design. Flutter is designed to be fast, with its custom app engine running on Google's hardware-accelerated Skia engine. This means 60fps apps on Android and iOS and a path for 120fps apps in the future. This is a bigger deal on Android than it is on iOS. The Google Ads app is already built on Flutter, which means Google "thinks Flutter is ready for prime time," writes Ron Amadeo. There's a list of other apps built on Flutter, too. Amadeo goes on to suggest that Flutter may be the path to Android's replacement. "Flutter ships its own app engine on Android and iOS, but in secret, Google is also developing an OS called 'Fuchsia' that runs these Flutter apps natively," writes Amadeo. "With Fuchsia, Google would switch from the Android apps written in Java to Flutter apps written in Dart..."

Comments

Bloat

[Anonymous Coward]

Flutter apps run on the Flutter rendering engine and Flutter framework, which are shipped with every app.

My phone only has about 3 GB of usable storage for installing apps.
I'm so sick and tired of developers putting their own needs ahead of those of users.

Not native

[Anonymous Coward]

These things never use the native look and are always slow.

Re:Not native

[Anonymous Coward]

Plus the developer needs to cope with bugs inherited from two platforms and the framework itself, just as in html5-crap. If one is writing a game engine, it is likely better to do it on a C/C++ and just add some native glue code for GUI. And if the app is mostly GUI, it is less hassle to write it in environments native language.

Re: Not native

[cyber-vandal]

It's less hassle to keep two different codebases in two different languages in line?

Re:Not native

[Anonymous Coward]

Actually this compiles to native and uses the native look, running at about 60FPS. I've been developing in Flutter for about 6 months now and it works really well.

Re: Not native

[cyber-vandal]

I can't speak for this one but in Xamarin you have common code (which tends to be most of it) and platform specific code. It pulls them together at build time and generates an installable package.

I'm not sure how trying to build two identical apps in two different languages and trying to keep the codebases in line is easier.

Re: Not native

[Anonymous Coward]

Sounds like you didn't know how to do it properly. I've developed crossplatform apps since before it was a 'thing'. (Think C/Assembly before Qt) They always turned out BETTER because we spent less time porting and more time on the 'actual code'. Every single one was fantastic without exception.

Only way they could turn out poorly would be if the framework sucked or if the developers just don't know WTF they're doing. But then, if they know what they're doing, they should be able to propose a better way to get the same results.

Re:Not native

[Anonymous Coward]

I've been working with Flutter since it was announced at Google I/O this year. I've been very impressed with the performance. In my opinion, it's bit slower than a Swift based iOS app, but actually faster than a Java or Kotlin based Android one due to the fact that it's 100% AOT compiling and there's no JIT involved.

It's getting faster over time too. When I first started working with it, it was completely unusable on a GPU-less Android Things developer board I had. I tried recompiling yesterday. It's still slow (which is to be expected on a GPU-less developer board), but it's actually usable now.

Re:Not native

[brantondaveperson]

Its speed is only partially important though. Higher CPU usage, which it will certainly be demonstrating if its a bit slower than the native widgets, leads to shorter battery life and quicker device turnover. This is a bad thing, and we should fight hard against it. On mobile, efficiency is paramount.

What's the over/under till Googl Drops this

[Crashmarik]

The way they do just about everything else ?

Re: What's the over/under till Googl Drops this

[phantomfive]

Five years.

Re: What's the over/under till Googl Drops this

[Flavianoep]

More like "who is Dart?" I tink dat Dart is a title of de enemies of de Jedi, who joined de dark side of de force in de Star Wars franchise.

Origin Of Flutter

[SuperKendall]

"Flutter" is what the heart of your battery does when an app with the giant framework loads up.

Kudos for making software development sound erotic though with "stateful hot reloads". You'd pay a few hundred $ for that in Vegas and here it is free!

Re: Origin Of Flutter

[brantondaveperson]

Using Xcode isn't required - you can build and deploy iOS apps on the command line if you really enjoy that kind of thing. Xcode is just using clang and gdb under the hood - plus some signing and packaging tools and what-have-you.

However they seem to be in love with creating new languages to achieve platform and developer lock-in as much as the next vendor. Maybe even more so.

how about this Hyper Text Markup Language ?

[johnjones]

honestly can we not just use web app for GUI development like Steve Jobs evanglised when they first launched the iPhone ?
(native code if you must for OpenGL ES and specialist API's )

maybe if google actually contributed to cordova so we could use their "app" on something with a fast keyboard as well as mobile :

https://cordova.apache.org

Re:how about this Hyper Text Markup Language ?

[Actually, I do RTFA]

I just want to get apps out of my HTML. Why can't we have a way of communicating over the internet that's safe and static. That way, I don't have to arbitrarily run code from 100 included sites (any of which may get compromised) to read your damn article.

I'm all for SPAs like Facebook existing... and even running in the same browser. But I just wish they could have just been .js files navigated to (or whatever), so I can tell my browser not to go there unless it's whitelisted.

Re:how about this Hyper Text Markup Language ?

[lucasnate1]

You can already disable scripting. Your advised solution wouldn't change the real problem, which is people. Under your solution, all pages would end with '.js', rendering '.html' obsolete.

Re:how about this Hyper Text Markup Language ?

[DaveV1.0]

Except the most used sites now require scripting to be enabled for the sites to work

Re:how about this Hyper Text Markup Language ?

[DaveV1.0]

It is your kind of thinking that led to all the browser and web based security issues.

Re:how about this Hyper Text Markup Language ?

[lucasnate1]

And this will also be true under his system, that's my point. The problem is not one that can be solved technically.

Re:how about this Hyper Text Markup Language ?

[Actually, I do RTFA]

True. However, that would let someone like Steve Jobs kill ".js" like he killed ".swf" files. I mean, remember when every fucking webpage was just a giant swf? Until it became unsupported on iPhones.

Re:how about this Hyper Text Markup Language ?

[lucasnate1]

True. However, the only reason swf was killed was to replace it with something similar you can't easily block and limit.

Re:how about this Hyper Text Markup Language ?

[Immerman]

Sure it can - just make the dominant browsers completely incapable of running any scripts at all! No massive security holes that can be enabled by the user means no gullible users enabling massive security holes.

Of course that would also mean we'd lose access to all those incredibly useful sites that actually need scripting to function like... umm... let me think... Google Maps?

Please, explain it to me

[Dutch Gun]

if you write for a game engine like Unity or Unreal, those engines are packaged with your game, allowing it to run on multiple different platforms. It's the same deal with Flutter.

Thanks, Ars Technica (and Slashdot for the copy-pasta), for explaining to me how a software library works. I was completely mystified how they could pull off this wizardry otherwise.

Re:Please, explain it to me

[mattyj]

If you think the Unity or Unreal game engines are merely software libraries, you really don't know what you're talking about.

Re:Please, explain it to me

[Dutch Gun]

If you think the Unity or Unreal game engines are merely software libraries, you really don't know what you're talking about.

Well, I'm a professional videogame programmer, who also happens to specialize in game engine development. As such, I tend to assume I'm probably a bit more knowledgeable than most on this particular subject. What exactly do you think is packaged with an Unreal or Unity game to make it run, if not software libraries?

Oh, and I never said "merely". Game engines are beasts. There's nothing "mere" about them.

This is the failed MicroSoft strategy

[Actually, I do RTFA]

Microsoft purchased Xamarin, a native cross-platform engine, that could export to iOS and Android (and Windows Phone). They gave it to everyone for free. Yet, it still wasn't enough to make people to develop enough software for Windows Phone to make it viable in the marketplace. I tend to think Fuscia is going to suffer from the same lack of software.

A major difference is, unlike Google, MS supports their product line (you can still get Xamarin free). Whereas building an app on something that won't exist in 5 years seems silly. Also, Xamarin runs on .NET; this runs on Dart. I can find .NET programmers easily.

So, I don't think this is going to work. But I wish them luck.

Re:This is the failed MicroSoft strategy

[Zmobie]

I instantly thought the same thing. I really don't see any secret sauce to make people want to use this framework when Xamarin is free, supported, somewhat established, and from a large vendor that will be much more likely to continue putting time and money into it. Just because Google's army of "lets use eclectic shit because we have money to burn" programmers decided to develop something in it does not mean it will catch on with everyone else. They are welcome to try, but my gut says dead on arrival...

Re:This is the failed MicroSoft strategy

[Tough Love]

I instantly thought the same thing.

That's two of you, at least there's that.

I really don't see any secret sauce to make people want to use this framework when Xamarin is free, supported, somewhat established...

And not under the control of Google in any way, so even if it was a decent cross platform toolkit, about which I am highly doubtful, it is not of the slightest interest to Google. See, controlling 85% of all the smartphones in the world puts Google in a position to promote its own cross platform toolkit, engineered to its taste and controlled entirely by itself. No idea whether its good or not, if it sucks then Google will suicide it and try another one.

Re:This is the failed MicroSoft strategy

[Actually, I do RTFA]

See, controlling 85% of all the smartphones in the world puts Google in a position to promote its own cross platform toolkit

I don't see why Android's market penetration matters. They're trying to compete with Android with a new OS. That's the same position as Microsoft was in. I mean, maybe Google could sabotage Android to force people to move to Fuchsia, but I'm not sure that would work. More likely, it would cause an Android fork where Amazon or someone maintained it.

Fact is, (almost) no one cares about a Google phone. But a lot of people are committed to an Android phone.

Re:This is the failed MicroSoft strategy

[angel'o'sphere]

Xamari is not really cross platform.
If you ever had used it you would know that.

Developers want one code base, not a platform where you still need to code versus native SDKs/libraries/APIs.

Re:This is the failed MicroSoft strategy

[Zmobie]

Short of straight up banning anything not developed on their platform (which guess what! they only control half of the platform both sides are targeting) it really makes little difference if they own the Android platform. They would have to individually curate and remove anything not developed on Flutter or whatever shit they settle on because the entire point of these frameworks and compilers is to make it so the system is running compatible binaries that are basically the same as the native code (obviously not the exact same, but the point stands). This would turn into a useless game of whack-a-mole and potentially wouldn't even matter because they can't make every publisher turn over their source code and development strategies to check. Even if they put it in the ToS they would lose a lot of big players immediately and kill their own platform.

My exact point is Xamarin fills this need already and first to market is a powerful position. Microsoft can also promote the exact same toolkit with pretty much just as much gusto. Do you think developers are exclusively looking at new tools through Google platforms only or something? Consumer usage of Android literally has no bearing on this given Xamarin and Flutter are marketed to developers.

Re:This is the failed MicroSoft strategy

[Zmobie]

Not really sure what you think cross platform means, but Xamarin is for the purposes of comparison to the Flutter framework, which was what I was doing. If you somehow think Flutter is 100% cross platform on everything and not just "mostly" like Xamarin you're wrong. Now, I've not used Xamarin extensively, but my previous employer was using it to develop an enterprise level solution that was generally hardware agnostic so I do have familiarity with the high level capabilities.

If you mean certain pieces are not completely generic, obviously no framework is able to run both platforms 100% native from the EXACT same codebase as they have to be made generic and not all things in many of these types of platforms are analogous. If it were that easy the Windows/Linux problem would have been solved years ago.

From the comparisons, the main thing Xamarin has a short-coming in (some would argue it isn't a short-coming either) is the UI is not completely portable. Business logic and all the meat and potatoes basically are though which is way more important in my opinion. Flutter has some of the same portability, but from what I understand there is a way larger percentage of stuff that is not portable between the two. I also really think Flutter trying to make a generic UI is idiotic at worst and misguided at best, given a lot of software groups will/would likely be designing different UIs for each platform given the differences in the OSs anyway. Certain key functions are better used in different ways on each of the systems. If the model and controller are properly interfaced and abstracted anyway then it is much easier to just plug in whatever view is appropriate and not try to jam the square through the circle.

Re:This is the failed MicroSoft strategy

[angel'o'sphere]

If you somehow think Flutter is 100% cross platform on everything and not just "mostly" like Xamarin you're wrong.
No, I'm not.

In Flutter you write one single piece of code, and the GUI code is the same for iOS and Android. The single code base is not even "portable", there is nothing to port.

In Xamarin, you write C# code for the Android API and different code for the iOS API. While the C# code for BL is portable, I have as many code sets as I want to support platforms.

Business logic and all the meat and potatoes basically are though which is way more important in my opinion.
Not on a mobile platform where 90% of the code you write is GUI.

Re:This is the failed MicroSoft strategy

[angel'o'sphere]

I also really think Flutter trying to make a generic UI is idiotic at worst and misguided at best, given a lot of software groups will/would likely be designing different UIs for each platform given the differences in the OSs anyway.
And what exactly is preventing you from doing that? it is a GUI engine/library. It does not force you to use a certain widget if you think another one is better suited.

Re:This is the failed MicroSoft strategy

[Zmobie]

Not on a mobile platform where 90% of the code you write is GUI.

No. God no. I've written enough mobile applications before, it isn't even close to 90%, maybe 30% tops. UI is not the end all be all of development, it just seems that way if that is all you ever work with. The business logic and supporting code is way more important and a lot more costly to develop properly than UI ever dreamed. Maybe you have less exposure to C# designs styles, but everything is generally done in generics and binds in actual libraries later (sometimes compiler config, other times at run time). If the design is applied properly very minimal code has to be written in the UI itself (MVVM or MVC anyone?). I'm not sure what mobile applications you have been exposed to, but we must have vastly different design philosophies and/or experiences.

Re:This is the failed MicroSoft strategy

[Zmobie]

That is the point though. If they are going to have different UI implementations for each OS what exactly did being able to have the same one used accomplish for someone? Hence why I really don't see an advantage. This reminds me very much of when people used to use Infragistics constantly and it was the most painful thing to work with, but the original thought was that it could keep everything standard when it really didn't need to be standardized.

Re:This is the failed MicroSoft strategy

[angel'o'sphere]

Sorry,
I talk about lines of code to write.
Not about complexity of "business code" or its importance.
Depending on platform the most lines of code is: GUI.
Depending on infrastructure, it is communications.

Business logic, regardless how complex, is a piece of cake.

Why do you think people focus on one platform? Because rewriting the UI code, depending on how strange the API is: is a pain in the ass.

Re:This is the failed MicroSoft strategy

[angel'o'sphere]

With Dart and Flutter, you only have one code base, that runs on both iOS and Android, and AFAIK on most desktops.

Re:This is the failed MicroSoft strategy

[Zmobie]

I disagree, but you are welcome to your opinion. I still wouldn't say lines of code is that big of a percentage of the codebase, but if that is your metric it might be a bit higher (45% I would hazard a guess). UI is significantly more boring to me as most of it is just setting up the relative calculation formulas and a lot of tediousness. Initial UI/UX design is more involved, but not exactly that technical either. In my experience a significantly less experienced and less costly dev can work on the UI and get it done exceptionally well, whereas if you have the same less experienced devs writing your baseline business logic and core code that application will be complete garbage regardless of how pretty the UI might turn out (I've watched it unfold a few times and then the codebase get thrown out entirely later on).

My design philosophy and experiences would make me stick to my original stance that Xamarin is much more well suited to creating these cross platform applications, but I can see your side of the coin as well. Time will tell who is ultimately right, but I would still remain cautious about Flutter given the landscape of dead services and frameworks Google has killed in just the last few years.

Re:This is the failed MicroSoft strategy

[Zmobie]

You would still have essentially the same with C# and Xamarin though albeit there would have to be a final abstraction layer where the Android and iOS calls deviate. The thing is, it would be no worse than implementing abstracted providers for data sourcing and would likely be much easier (probably a lot of 1-3 line methods implementing the specifics).

Call me skeptical but I am not impressed with Flutter as of this writing. For now I'll merely agree to disagree.

Re:This is the failed MicroSoft strategy

[angel'o'sphere]

My point of view is basically always: I have to do all my self.

Obviously if you have cheap programmers who do the UI for you, that is different.

Re:This is the failed MicroSoft strategy

[iserlohn]

Flutter draws on a canvas and doesn't actually use native widgets, only emulating the native look. It's a lot faster than Xamarin or React Native with less platform specific customisation needed.

Why not Qt?

[Gravis Zero]

Qt allows you to develop native applications with a single codebase for a whole host of platforms, including all the smartphone platforms you can think of and even include video acceleration. Even better is you don't have to learn a some bullshit language that Google will ditch in a few years because it's a C++ framework.

Re:Why not Qt?

[should_be_linear]

Since it is C++ framework, you need to learn at least one bullshit language.

Re:Why not Qt?

[TheDarkMaster]

Qt is not "shinny and new" enough for millennial programmers.

Re:Why not Qt?

[DaveV1.0]

Yeah, because javascript, dart, python, etc. aren't bullshit languages,

Re:Why not Qt?

[dannydawg5]

Qt requires a stupidly expensive all-in-one commercial license ($5k/year) to build a proprietary app for the mobile app stores.

The free LGPLv3 used by desktop apps is not compatible with mobile apps because the stores apply its own legalese that prevents you from adhering to all the LGPLv3 clauses.

Re:Why not Qt?

[Rob Y.]

QT really needs a new sugar daddy. It was looking good when Nokia was a viable company and wanted to use QT as the basis for it's great new phone platform. If that had succeeded, QT might have ended up being truly free in all cases. I think it was Nokia that set it free on the desktop.

Maybe IBM, with its billions to spend on the likes of Red Hat, should buy Trolltech and finish the job of setting QT free. Unfortunately, nobody develops new apps for the desktop any more, so QT is less useful than it could've been if it had been free back when single-source Windows/Mac/Linux development was a panacea. And maybe the mobile version of QT could still be viable in that role for Android/iOS. But given the choice between C++ and Java, I'd take Java most days. Given the choice of something less crazy complex, though, I'd take that.

Cross-platform ad code

[AHuxley]

Always first with the ads for the real customers.

Old news! Cordova/Phonegap rip-off

[Anonymous Coward]

I have been developing native looking & behaving apps for ten years using JavaScript an HTML.

Flutter is just a cheap attempt to get devs to use Dart, a language that's dead in the water since launch.

Re:Old news! Cordova/Phonegap rip-off

[Anonymous Coward]

actually it's not. StackOverflow stats already show it being quite popular. I've been using it for about 6 months now and it's really good. And no it's not a cheap rip-off because Flutter is NOT HTML5/JS but native apps. And Dart is really easy to use.

Re:Old news! Cordova/Phonegap rip-off

[Arkham]

actually it's not. StackOverflow stats already show it being quite popular. I've been using it for about 6 months now and it's really good. And no it's not a cheap rip-off because Flutter is NOT HTML5/JS but native apps. And Dart is really easy to use.

The interesting part here is the statement that flutter produces "native apps". I think that's true in the sense that the code is compiled rather than interpreted, but it's false in that none of the UI widgets are the "native" ones provided by Apple.

I've used Phonegap, Cordova, Corona, djinni, Xamarin, Appcelerator Titanium, Ionic, Sencha Touch, and React Native (and probably some others). All of them suffer in different degrees from the same thing. For most of them, they're using pseudo-native UI that looks like native until you use it, then you can tell it's painting widgets on a canvas or in a web view that just simulate the native ones. In a couple of cases (Xamarin, React Native), they do cross compile to native widgets, but you still end up creating bindings and bridges for every incremental release that adds something while you wait for the framework to catch up.

Honestly, if I were seriously going to develop a cross-platform app today (and I do), I'd either go all native, or else write the core business logic in C++ and create bindings to a native UI. We've seen this work in the market (Dropbox), as long as your development team can do C++ well enough.

iPad support

[DutchDopey]

I see no ipad support. Probably one of the things why you still would be developing native on iOS (swift/objective-c) is because of ipad support.

Re:iPad support

[Anonymous Coward]

It definitely has iPad support. You can build out different screens and layouts using the MediaQuery class. I've used that myself to also do different layouts for landscape and portrait.

Libraries

[kbg]

There are major problems with this. Even tough Java isn't the greatest programming language (but then again no programming language is). The greatest benefit of using Java is that there are now gazzillions of libraries and utilities to do everything under the sun, no matter what you need to to do you know there exists some library available to do it, so you don't have to code absolulety everything from scratch. If you switch to a spanking new language it takes probably a decade or so for the community to get up to speed with available libraries and that is only if the language is popular.

I hate all these new languages that are popping up, because there is nothing special about them, anyone can make a new programming language, that isn't the hard part. But the actual value of a programming language is in the availability of pre written solid working code that you can use in your projects.

Flutter == Last chance for Dart.

[Qbertino]

Dart was one of the interesting transpiles-to-JavaScript things of the JS hype of the last 10 years, but it lost out to typescript like all the rest. The Flutter toolkit is Darts last chance of serving in a potentially viable ecosystem before it drops of the radar. ...
I'm not holding my breath. Although Dart has some really cool things. An own VM for own runtime niceties and a trivially ready mechanism for pseudo-concurrency and multi core programming that you can instantly grasp and use after reading the description for the compute() function.

If you like checking out awesome new PLs just for kicks, Dart is smack center in your ballpark.

Been there, done that.

[BenJeremy]

Adobe did this with Air (ActionScript and Flash technology), and as the summary states, Unity, Unreal, and many other game engines also do this. Xamarin also does this (much the same way as Unity, with C#/IL as the layer closest to "the metal")

You can make very serious apps with Unity, by the way... they don't have to be games - plus you get a pretty rich ecosystem of code (C#), support (Asset Store), and training.

Why do big companies constantly try and re-invent the wheel, when the existing ones work quite nicely?

Re:Been there, done that.

[iampiti]

Because it's not THEIR wheel and they think they can make theirs better and control its design.
Being serious I think it's mostly about control

First-party script only

[tepples]

I think the intent was to forbid loading script from a different domain.

Why does PhoneGap exist?

[tepples]

honestly can we not just use web app for GUI development like Steve Jobs evanglised when they first launched the iPhone ?

That'd be fine if Safari for iOS were quick to support emerging web standards, particularly those aimed at platform integration. But if that were true, there'd be no need for things like PhoneGap/Cordova. Heck, it took six versions just to support <input type="file"> from HTML 3.2 (1997). This and other features appear to have been left out or delayed on purpose, with the intent to drive web application developers toward a native application on the App Store, with its periodic Mac hardware replacement to run the newest Xcode version, $99 per year annual fee, and 30% commission payable to Apple.

GPLv3: Provide the object code files

[tepples]

App stores plural, or just iOS? As I understand it, an Android app developer can satisfy the "Installation Information" requirement and other GPLv3 requirements by making the application's object code files available to licensed users for relinking with a modified version of the library to form an APK file suitable for installation on any Android device that supports adb install. This should work for any Android app that isn't a subscription video streaming app, a single-player microtransaction-driven game, or something else designed to enforce digital restrictions management against its end user.

Re:GPLv3: Provide the object code files

[dannydawg5]

Doesn't matter. If 1 major store says no, that kills it.

There is no point in using a cross-platform toolkit if you can only target 1 platform. Might as well go fully native.

Re:GPLv3: Provide the object code files

[tepples]

There is no point in using a cross-platform toolkit if you can only target 1 platform. Might as well go fully native.

If you'll be shipping one app on Windows, macOS, X11/Linux, and Android, there's certainly point.

Re: GPLv3: Provide the object code files

[astrofurter]

His point is, Apple and Big Brother Google have very significant monopoly power. If even one of them denies your app - for whatever arbitrary reason they invent, with no recourse to a fair court - your app is fucked. And maybe your whole business too.

So if using a certain library gets your app automatically denied access to the market, no one is going to use that library.

Re: GPLv3: Provide the object code files

[tepples]

How is it not a valid business decision to decline to serve some platforms? Nintendo doesn't develop for Xbox One, for instance. I can think of a few other applications that are on Android but not iOS as well.

Embarcadero already does this with C++ and Delphi

[Anonymous Coward]

Delphi (objective pascal) works well, and their C++ option is pretty good. Everything works out of the box, even bluetooth on both desktop and mobile (unlike Qt). Check out https://www.embarcadero.com/coderage-2018 to get an idea, you build the UIs like you used to in MFC/VB/WinForms has JSON support and will let you build cross platform applications that work with a better license than Qt. I think Embarcadero has really turned it around from what it used to be and you can get a good looking application running on either multi device (FMX) or windows only (VCL).

I also can see why Dart looks so good, easy for JS developers to transition to, I ran flutter for an android application and it was not bad. However, building the layouts is like going back to SWING where all the UI is built on code (rather than the give the XML to the UI/UX guy to do so not it is all in the programmers hands). The language is somewhat similar to Haxe and ActionScript (much better than JS). But I am not sure about the support for device sensors and bluetooth in Dart. Also the fact that last year Google was all about Kotlin and now is left in the dust?

Xamarin is cross platform, but you are building specific UIs for each platform, and their bluetooth and sensors layer is very quirky (and sometimes not so platform independent). MS has also screwed developers before, and I have felt a bit burned by them (even though I do really like Visual Studio). I tried it a few times, and honestly it was a headache every time but for the simplest of cases... the only pro about Xamarin is for using MonoGame to target cross platform (but Unity now is making game dev easy for just about anyone... is it even that relevant anymore?).

You can argue as well for electron, a glorified web browser local to your machine, so that is a desktop application for web developers... if you make it for mobile it would work too right? VS Code is written in electron and so is Skype now (it was in Delphi at one point for the windows client). But this is not mobile and beyond scope.

Unity is great for game or simulation development... if you are building an application on it you might know when to use a game engine and when to make an application.

I think what I (most of us) want is a few good options for development in mobile and desktop environments that is not python or JS, works well, and performs good in a typed language.

JavaDart?

[RogueWarrior65]

Remarkably similar to Avodart which is a drug for treating enlarged prostate. Coincidence? I think not.

Great name

[jwymanm]

They should name all of their products Flutter. mw: chiefly British : a small speculative venture or gamble. Synonyms: Noun adventure, chance, crapshoot, enterprise, flier (also flyer), gamble, speculation, throw, venture

Great concept, Not ready for prime time...

[Anonymous Coward]

Just because they announce it as v1.0; doesn't mean it is ready for usage right now. (or ever???)

The github repo is full of common crash situations that haven't been fixed (and might not ever be, if you understand the reason why it crashes). Several of them is directly related to their inability for the app to access or be accessed by anything synchronous properly. Since they can't actually handle _any_ of the sync api's properly from either iOS or Android, this limits a chunk of apis, callbacks and delegates that it can use properly. The android SaveState and LowMemory being two that cause them the majority of their issues that are sync. Right now it frequently crashes just grabbing a image from the image picker on android, i.e. using an intent to access anything external to the app. Also anything that can cause the device to be in low memory situation (user running a game anyone?) can easily cause your app to get killed and won't resume properly.

Developer in charge of Flutter has the "My way or the high way" attitude and it doesn't matter how many people show that support for these api's are needed (nor how many crashes are directly caused by the lack of this support). He doesn't like Sync support and so he veto'd the sync api PR over a year ago. One developer even walked him through the entire lowmemory notification stack with links to the ASOP source code; didn't make a difference last time I looked. He has no good answer on how to support any of these API's, but he is still unwilling to add the needed support. So at this moment the users of the flutter framework will suffer from things that all other frameworks can handle properly, and not be able to do anything about it...

I wouldn't trust my apps on a framework that intentionally breaks compatibility with OS standard API calls; with no way to work around it. So not ready for prime time... Probably never be ready for real application usage, and then it will be killed by Google because of lack of developers. Gee, who could see that coming...

Re:Why Android?

[dgatwood]

The first in that space was the Newton, released almost 14 years before the iPhone, when used with a modem card attached to a cheap cell phone.

Wasn't Java supposed to be Write Once Run Anywhere

[filesiteguy]

I seem to recall hearing this story time and again. First there was the promise of Java. I've continued disliking it since I tried to load the JDK in the late '90s. Then .NET (a.k.a. Microsoft Java) was going to solve all of our cross-platform issues. Then Android -we can all code in Java but using the Android libraries. Finally, the Windows team bought de Icaza's Xamarin (formerly Mono) and have done...?

Please wake me when it is over.

Re:Why Android?

[dgatwood]

Yeah, but the point is that the overall interface design started way back then. Palm copied it into a smaller form factor, and PocketPC copied it from them. So although iOS wasn't first, Apple was.

Codename One is a proven WORA tool for Android/iOS

[AirHog]

Codename One ( https://www.codenameone.com/ ) solved this problem several years ago.

I've built several apps with their system.

Debugging in the simulator is lightning fast. Their build farm saves hours of work setting up tools. And it is the closest thing you'll find to WORA for mobile since they provide interfaces to access native functionality and map to it on your behalf.

Best of all, their free tier lets you write small- to medium-sized apps for free!

Flutter 1.0 is finally

[jimmierwilliams]

It is the latest crush of every developer. Learn what are the top features of this new app framework.