What It Was Like to Write a Full-Blown Flutter App
medium.com
medium.com
The use of widgets saves a lot of time, leaving one to focus on connecting everything together. It's also easier to learn than React Native (for me at least).
The current downside for me has been the lack of maps (I'm aware of current efforts). I also hit a weird Firebase Messaging bug that leads to an infinite loop of the app opening itself [0].
I agree with the author regarding the strong Firebase push. The community doesn't yet seem large enough, so outside of wine of the Google supported plugins, it's sometimes a struggle.
I am building a second app in Flutter, using the new Material stuff that Google announced this year.
But it actually makes sense on a closer look. Dart on the server is not officially supported, as the primary focus of Dart is use as a client-side language, so it would be a bit confusing for the Flutter documentation to recommend using Dart for a backend.
That being said, I think Flutter is a great platform for quickly building apps, and getting consistent behavior across different vendors. I think that it can only continue to get better.
It is more nuanced: Dart on the server side is supported, but the development focus is on the client-side stories (Flutter and Angular).
Google's Dart team develops e.g. the Dart VM which is great for server workloads too, they do provide some server-side libraries, but they themselves don't work on third-party database drivers (for now).
Think of it as the question of focus: they want to focus on the client-side story, get it right, and then deal with the rest. Spreading thin won't help either.
To me , dart on the server , with their agent / isolate based concurrency as well as async await language support, provides ( in theory ) one of the most exciting environment to develop backends on.
But Google's Dart team is not actively involved in developing e.g. the Postgres driver, it is done by an independent company who is building their stack on server-side Dart.
Btw. I agree: the isolate-based concurrency + language tools is really great for server-side Dart apps. I use it in a highly concurrent data setup, and I wouldn't switch to other language.
From Google's point of view, we would all be using it.
What gives you that idea? The Dart VM is listed on the platform page for command line and server side programs. https://www.dartlang.org/guides/platforms
The focus of Dart 2 and beyond is the client side [0].
You can definitely run Dart in the VM, but beyond the HttpServer API, server-side support is mostly a community effort.
My point isn't that this is a bad thing, it's that it makes sense for Firebase to be promoted because Dart doesn't have _official_ server-side support.
[0]: https://medium.com/dartlang/announcing-dart-2-80ba01f43b6
Analogy: JavaScript is focused on the client too, but people also use it on the server.
I do agree they have pivoted to a more client-sided branding though.
Unfortunately, even Flutter requires it when building the production-ready Android version of the app. Perhaps it's time Google switched to their own Bazel as the default for building Android apps. As a bonus, the syntax is a lot lighter than Apache Groovy's.
I don't know Gradle, I'll try when I have free time. I have one project which can be better off as a Java API app (based mostly on Intents). WRT Flutter, I have not experienced any performance problems with it so far; though I haven't built a "production-ready app" yet. But given it'd mostly be a rare task, that'd be bearable.
WRT Macs, well, I use a Unixy laptop since time immemorial, one way or another (stuff I spent >1yr with: Ubuntu, Arch, FreeBSD, Xubuntu, and finally and currently Debian; in that order), and being quite content with what I have at hand, I'd be reluctant to switch anyways. But AFAIK the App Store is where the money is, so I want to get in to it ASAP.
I'm in a rare situation where I'm a long time amateur/semi-professional programmer, but I study and plan an academical career in humanities. I need to write up a couple apps to help interacting with documents (what's available on mobile is basically sub-par), so I'll code them up anyways, but I'd be glad if I could share them FOSS but also get some amount of money from the app stores. Even a hundred or two hundred dollars a month would help as a serious amount to complement scholarships or loans as I do masters and a PhD. And I'd be ecstatic if I could avoid scholarships or loans! And flutter would render possible writing such cross platform apps and maintaining them while studying, whereas learning, writing and maintaining two codebases, and spending money on premium hardware up front would be a very big obstacle for me, and also unmaintainable in the long run (I can't write a thesis and maintain compatibly two distinct codebases with such diverging paradigms, let aside multiple apps).
So I guess I'll end up in some time with a setup similar to yours, which I think is optimal: use my favourite setup, test on target platforms. A bit like cross-compiling.
edit: grammor
I don't often hear about the true accounting of time spent learning and grappling with the limitations of cross-platform frameworks, including debugging and workarounds, versus just using the platform vendor tools.
It just sort of seems like it's assumed that it's a huge time waste to maintain separate codebases. But I wonder if you gain other advantages that might outweigh it, like not having to "fight" the intermediary layer and getting first-class access to the underlying APIs, platform features and debugging tools. Thoughts?
I am writing the same app in both Flutter and Swift/objc simultaneously, and I will grant that I am much better iOS dev than Android. The previous version of the Android app was written in Java.
Honestly, Android dev for me is very not fun, there is so much mental load that is probably necessary for large apps but for me it’s just a time sink. Flutter on the other hand gives me Material widgets our of the box and easy declarative layouts. I will say this is my first experience working in the react paradigm and it’s been a learning curve. Flutter is super fun to play with though and making user interfaces is actually pleasant.
I decided to also write the new version natively on iOS because some of the most important parts of the app for me are the Today Widget and Watch Complication. Now with Flutter you can add this manually in swift or objc or whatever, but they can’t talk to Dart code. So I would have to essentially write the networking client code twice. That, and the iOS widget support just isn’t good enough for me in Flutter.
So I am using Flutter to develop and Android version of my app, while keeping the option that it could eventually become a full cross platform version someday if I choose.
Also if Dart ever gets extensions like Kotlin and Swift that would be a game changer for me, since I use generated specs for my API schemes.
Maybe these dual platform frameworks are fine for something like a company internal app where it’s okay if you don’t get everything “just right”. But otherwise I’d rather just go pure native, even if it means alienating half my user base or spending 2x resources. It’s worth it in most cases IMO.
Granted I’ve only spent a couple weeks with React Native about a year ago, so maybe I just need to give it another go.
Treating Dart and Flutter as one 'SDK/Language for Apps' made it a lot easier to avoid the uncanny valley effect I had with react native vs normal react.
Maybe it's possible to do with a pc running chromium os.
Termux would probably also be mostly usable in Fuchsia, WSL or Aix.
So, I just got that excitement from having something cool to learn.
I'm perfectly happy with the nesting of simple elements. Having a single 'Container' also handle various layout rules is what makes all the positioning options of CSS difficult. Similarly for constraint systems. Composable, single function components are easy to learn and use. I'm just presuming that it has good runtime characteristics and haven't run into any issues yet.
The problem with React Native is that the complexity is higher, routing/navigation a mess on iOS and the dev experience is nowhere near as fast or polished as Flutter’s.
My strong suggestion is to invest a week with your team to learn React Native and then spend a week with Flutter. A week is enough to pick them up.
If so, why not Ionic?
Probably 6 months ago flutter wouldn't be on this list but Google has surprisingly shown strong support
Why not Xamarin? It also has the backing of a top software company.
I prefer not to think of myself as an X-language programmer. And yes, when I was developing mobile apps, I did it solo. I preferred to choose the right tool for the job, and learn a new language if needed.
And I think Xamarin is better than React Native or Flutter, because Xamarin makes it easy to use each platform's full set of native widgets in the native way, while still sharing non-UI code. In contrast, React Native does use a subset of native widgets, but doesn't give you access to the full set of them (at least out of the box), kind of like the old Java AWT. And like Swing or JavaFX, Flutter throws out the native widgets entirely.
Xamarin is terrible to work with, and if AngularDart shares code with Flutter then it might be interesting to replace angularJS + Xamarin with dart.
I only clicked this article because I a Danish municipality programmer, I follow, comment on flutter, on one of the Microsoft news portals though, so the community is definitely a lot smaller than the Xamarin.
IIRC, Flutter started at Google.
There are a couple of notable exceptions but the list of abandoned developer tools coming out of Google is far longer.
Given you're doubling down you're taking a massive risk as a business. As an employee you also risk making yourself unemployable going all in on Dart and Flutter.
i had not thought about this right in the past. i hadn't factored in the reality of needing to maintain two separate UI trees, one with Material Design widgets and one with Cupertino widgets. this makes me think one of the really big advantages i thought Flutter had -- a unified UI -- is not really realistic.
i must be misunderstanding this