Nowadays the issue with app devlopment is not only having two OSes two develop for (and I doubt that Flutter is a real help here), the much bigger problem is user acquisition.
User acquisition got so insanely expensive for apps that there are few to none business models where you can justify or break even the user acquisition costs.
I disagree. Yes the web is also competitive but it's 100x easier for a simple reason:
The next site ia just ONE single click away. The next app is few clicks and a download away, even without any sign-up, an app install is a gigantic conversion breaker. This is not comparable with websites at all. Anyone who does new apps in 2017 must have a good plan.
We primarely discussed the user acquisition costs in this thread and I pointed out a huge conversion breaker in the acquisition funnel of mobile which just let the costs skyrocket. If users stick or not after being acquired is as important but another discussion (rentention & churn).
But the funnel till this point you mention is MUCH cheaper on the web than on mobile (where people also install and deinstall right away or never use that app). And this 'being cheaper' is the whole discussion around.
Of course there might be use cases which have a healthy CAC to LTV ratio. But almost none of them is B2C, except scammy dating apps and addictive fremium games. And some one-hit-wonder games which cannot replicate their success.
On the B2B side it's a bit better because of higher LTVs but all B2B apps have a web version where leads are generated anyways. So, mobile is just complementing but not in the user acquiring role.
But maybe you tell us if you are so lucky and have a, from a business-POV working, app which provides enough value and charges enough for it AND can acquire users for less than their LTV. Give us your example, we are curious to hear how you make money in the app stores (which is just hard to believe).
CAC > LTV = "not providing enough value", to my mind. That is, people are not willing to pay for it enough.
This, to my mind, also means that small paid apps indeed is not a reliable market. Either you need to go viral (a rare stroke of luck), or you have to complement an existing business of some sort (and it has a web site which is a powerful lead generator, this goes without saying).
So no, I don't have a good example, for these very reasons. When I will have executed on a a million-dollar idea (which is, of course, peanuts for a startup but could be a great side project), and it would happen to be in the mobile-only space, and won't be a freemium game, I promise to write a post.
Flutter looks pretty different from React Native on one side and Cordova/webview based frameworks on the other side. Flutter is not based on webviews, but is also not using the native widgets but instead rendering custom widgets.
To me, this is a little weird. One of the downsides of Webview based apps is that it's harder to align with the native OS look and feel. React Native solves this problem, but Flutter clearly has the same problem.
Fluter has two widget styles, "Material" and "Cupertino", but I agree it would be better if Cupertino was backed by UIKit (then you'd get accessibility, UIAppearance, font sizing, etc. for free).
I recently prototyped an app in both Flutter and React Native. React Native feels incredibly fragile. Half of the month spent on a React Native app has been spent fighting with React and finding the right combinations of node and npm versions. Update some component and everything can fall apart.
Flutter's developer ergonomics are so much better. Time to first-running code was faster, and time spent due to broken shit outside my control was way smaller.
Is this still the case that you don't accessibility (on iOS) if you don't use native widgets?
Isn't there a way to "publish", "expose" say text and other information to the system? I believe for example Windows has this, and Qt on the desktop can use it (although there were still complaints, that some really popular brand of braille reader was not working).
Simply curious, as long time ago I was heavy proponent of native only widgeting systems (like wxWidgets), but lately in favour of self-drawn one, but imitating the interface (like Qt).
(Disclaimer: I work on Flutter.) As skybrian says, accessibility support is work-in-progress. But if you try an existing Flutter app (e.g. the official Hamilton App) you'll note that most aspects of the app are accessible to VoiceOver, just not quite everything yet. We're actively working on improving our iOS and Android accessibility integration.
(disclaimer: I work on Flutter.) Flutter uses its own renderer based on Skia. Flutter essentially asks the OS for an surface to draw onto, and then Flutter draws all the pixels through Skia.
If you write a native app programatically, you replace all your localizable strings with NSLocalizedString(@"string to translate", @"message for translator") - or similar in Swift. There's also support for localizing strings that you supply in your plist config files, which are strings for things like telling a user why you want a certain permission.
If you use a lot of Interface Builder (IB), then your localization support stems from all the basic UIKit widgets having support for localization built into IB, and in that case you'll end up building custom components on top of your UIKit blocks, and localizing via IB.
One of the views in an app I work on (a Settings view) also uses some plists to generate the table, so we end up having a bit of code to generate the NSLocalizedStrings for the stuff that's not actually in the source code.
I wouldn't call "React Native" much more "native" than Flutter. Most of the widgets, while inheriting from UIView, are internal FB implementations. No system buttons, labels, navigation, animation, gesture recognizers, etc.
> To me, this is a little weird. One of the downsides of Webview based apps is that it's harder to align with the native OS look and feel.
I'd agree with that in 2014 but this has been much less of a problem since the last few years. The fast pace of mobile OS's have slowed down to a halt. IOS has pretty much the same looks since version 7, Android since version 5.
The metro/material/flat design fashion has been the best thing for cross platforms apps, be it desktop or mobile, any platform or any framework.
Flutter seems to be at the right place at the right time.
I didn't say it can not be done, but it is just harder.
I develop a lot of cross platform apps using Cordova. While this works pretty well, and indeed in recent years support for this is only becoming better, it remains that Webview based apps always feel just a tad off.
> Flutter is not based on webviews, but is also not using the native widgets but instead rendering custom widgets.
Yeah, I only just realised this after further looking into it today (when I last checked their site, they only had one page introducing the project). They try to spin this from a negative to a positive[1], by saying that they think they can guarantee the Flutter widgets quality and performance compared to native widgets, and it's on them (the Flutter devs) to make sure those widgets are up to date to the look and feel of the platform.
Which to me just seems like trying to solve a non-issue in the first place, not to mention depending on the Flutter developers to ensure their supported widgets remain up-to-date to the platforms standards and not deviate in any way.
Qt seems to have done a great job of this. There are occasional hiccups when OSX updates the look of their progress bars for example, but it never feels nearly as bad as Java Swing (when it's emulating the host OS) or wxWidgets (ironic, since they use native widgets like react-native).
So it can be done, but I imagine it isn't easy. Qt has years of experience doing it.
Counterpoint: Qt has done a terrible/non-existent job of this for iOS. Qt/QML apps look and feel pretty native on MacOS, and Qt & Qt Quick controls on Android devices look very close to Android native, but they've barely even attempted to implement iOS-looking controls. (It's bizarre how little interest they seem to have in supporting iOS. I don't know if it's because iOS doesn't have the styling APIs they need or what.) There is a third-party framework that partially addresses iOS issues (https://v-play.net/qt), but that's not an ideal solution.
For some applications (including the one I'm currently working on), you can get away with having nearly the same UI on Android and iOS, with just a little extra work to (for instance) give iOS users a more native-feeling navigation experience.
In regards to Flutter, I'm not sure if it's reasonable to expect the Flutter project to do a better job simulating native iOS widgets than Qt has been able to.
Are you sure that QT is not using native widgets? I always thought QT used native widgets and a quick search [1] seems to confirm this:
> Recent versions of Qt use the native style APIs of the different platforms, on platforms that have a native widget set, to query metrics and draw most controls.
Seems to confirm it, but doesn't. What that means is Qt uses the native style APIs to get the system styles (e.g., theme color, highlight colors, default fonts/sizes, etc.), so it can draw controls that look like native controls. But it's drawing widgets, not using native widgets. In many/most cases, users will never know the difference, but it is different.
Blind users definitley notice the difference, because Qt apparently doesn't implement the platform accessibility APIs quite right, particularly on WIndows.
Two anecdotes:
1. The TeamTalk (http://bearware.dk/) voice chat system is popular among blind people. Originally when it was Windows only, it was an MFC application. Then when it went cross-platform, the developer used Qt. But the Qt version was inferior for blind users, so the developer still maintains the MFC version just for them.
2. Rant from a blind programmer trying to develop an accessible cross-platform application with Qt: https://blind.guru/qta11y.html
On every major platform, it's possible for non-native widgets to be accessible by implementing the platforms' accessibility APIs. But Qt doesn't do this very well.
iirc it uses native widgets, the problem was that for some time QT used Carbon and stuff like scrollbars looked outdated until they added cocoa support because Apple stopped updating visually carbon
This gives you native performance, but the ease of development of a shared UI. Given that Material Design is gaining popularity on the web and iOS as well, apps made with Flutter won't feel entirely foreign either. And the Cupertino styled widgets will help, too.
Material or not I do think that mobile UI's on Android and iOS are starting to converge more and more. Lot's of apps look very similar on iOS and Android and it doesn't have to fail alien at all, if well executed.
I find the convergence typically by design on the part of the Designers, PMs, and decision-makers up top as opposed to their actually being a need for convergence. I often attribute this to a strong lack of diversity of teams whereby there are almost zero Android users on the design/product team leading to a unified look.
It can also be attributed to laziness on the part of the PM and/or designer. Or in general, clients opting for cheaper solutions when hiring an agency to build apps for them.
I say all this to point out that, Android users often get the short end of the stick when it comes to app design. Often there is a strong lack of consideration on what is a native Android app feel. No consideration for the use of back-buttons, menus and UI elements using bottom navigations or custom ones instead of native Material design... Generally convergence is made for all kinds of reasons that ultimately leave Android users alienated.
No, it doesn't seem crazy, but it's also not really what users want. Android users probably expect native Android behaviour, iOS users definitely expect native iOS widgets, anything else will feel quite off.
I guess it depends on the app. Google's own apps on iOS don't strike me as feeling very native. I would think they'll get closer to nailing the Android behaviour. In a way these toolkits fill a space like Electron on the desktop where the developer won't, or can't, for all in on a native experience.
As someone who built some mobile apps with web technology I can see how Flutter would have an appeal because going into the project you've already given up on the native experience. There are still (unfortunately?) a world of marketing-driven apps with the brand overriding design choices which would be suited to this. Tools like Xamarin probably have a lead for line-of-business apps inside companies due to the MS ecosystem integration, but I could see people choosing Flutter for these apps if it's easy to build and maintain apps.
None of this changes the fact that for best-of-breed apps in a public store you'll need to use the native toolkits.
This reminds me of switching from Windows to Linux in the noughties: one of the complaints about Linux not being 'suitable for average users' was the lack of consistency between GTK/Gnome and Qt/KDE applications, and a lot of effort was spend on compatibility layers and such.
When I looked at a friend's Windows XP installation, it struck me that pretty much every application they used had a different UI system: WinAmp, Firefox, Opera, Windows Media Player, MSN Messenger, ...
> Google's own apps on iOS don't strike me as feeling very native.
That is true, but does anyone actually like the feel of google's iOS apps? I personally think they're awful, but the content they present is so useful that people use them anyway.
Performance is not everything. I expect iOS apps to behave and look like iOS apps, not just run fast. Google's software looks like fisher-price third-rate crap on iOS.
This is very true when it comes to consumer apps, but in our experience businesses prefer a more unified experience for their users--it minimizes the training effort.
I wonder how much native look and feel really matters. Swing copped a lot of flack for not having native controls but I think this problem was miniscule compared to poor performance, bloated download and complex API. Web apps don't use native look and feel but have nonetheless been very successful.
An awful lot of apps use a map, and a static map in many cases isn't going to be enough. Likewise many apps will want to display video. Looks like they also have an issue open for webview support, which could be a problem too:
Looks like you could do the same for any view, so it's more that you can't have a subview which is a map or video etc, which isn't such a bad limitation (not ideal, but at least it's not impossible).
(disclaimer: I work on Flutter.) Hi, thanks for the feedback! Would you be willing to "thumbs up" this issue? https://github.com/flutter/flutter/issues/73 It helps us when triaging. Thank you!
Why is that Flutter does not have a web target? Everything is nice and fast about it, it's a shame that after building a cross mobile apps, you'll app to start the web app from scratch using another platform.
React Native doesn't either. Only via the third-party React Native Web project[1]. Which I'm sure something similar for Flutter can also be achieved if desired.
While it does not right now and I doubt the team ever will do that, it is open source. I'm sure the team will accept meaningful contributions. A meaningful contribution here could be to make the flutter backend system pluggable enough that 3rd party backends can be used without modifying core. Then a web, desktop or any other backend can be implemented outside of it.
I know for a fast that the core team is open to the idea of creating desktop backends but does not have the resources to do it. They'll gladly accept any contributions towards that.
Adding web as a target on top of the enormous complexity of ios/android is a siren song. These cross-platform codebases are already held together with popsicle sticks and bubble gum with just the two targets.
Of note is that Appcelerator did target all three simultaneously (as well as blackberry and windows phone), but eventually dropped web support.
Good point. I develop all my apps using Cordova and it really is a big win that I can run these apps right in the browser with little to no effort. It's pretty trivial now to develop a Progress Web App and package it up with Cordova for some visiblity in the App/Play store.
> We test on a variety of low-end to high-end phones (excluding tablets) but we don’t yet have an official device compatibility guarantee. We do not offer support for tablets or have tablet-aware layouts.
Thats a pretty serious, and surprising, limitation.
As far as I can tell, it's just something that will be added eventually. Given that Fuchsia OS applications are written in Flutter, and Fuchsia is meant for all form-factors -- phone/tablet/desktop, this is clearly something that is eventually going to be required.
In my experience with app development, having worked on multiple handset-to-tablet conversions as well as universal-upfront projects, it is a bear to add tablet in after the fact when it wasn't considered upfront.
And the opposite is also true, that if you do both along side one another, it really isn't that bad. I guess I'm just surprised they would be willing to tackle cross platform upfront (ios/android) but not cross form-factor (handset/tablet).
Anyone using this and have experiences to report? I'm thinking of using it for a project soon. Specifically, how does it compare with 2x native apps for Android and iOS. How was Dart as a language, and the bindings to different native SDKs? What problems did you encounter when building apps on both platforms?
I'm a consultant & I have recommended Flutter for third app now, business owners love it, specially love that they don't have to maintain two separated code bases for a single app and getting ride of buggy, slow hybrid solutions.
None of programmers knew what is dart / reactive, we did fast sessions learning by using ES6 and react, once that (and state management) is understood we switched to dart and programmers found it very similar and fun... however, some programmers said they have understood state but they didn't, made naive mistakes and app worked well anyway, tests couldn't catch them, my code review did.
Android programmers couldn't believe hot reload button, very welcome upgrade of gradle, they don't like how UI is built (used to xml), I agree it is confusing nesting all those functions, you have to wrap your mind around it, I believe introducing XML or JSX to flutter would be a mistake.
The only complains is third part plugins, we had to drop Flutter where ads or some third plugins is a must.
Flutter is not a complete solution, you still have to write some android / ios code to make your app works well.
I haven't done enough with Flutter to really report on it but I like it better than React and Android's API so far. I do feel comfortable enough with Dart to say that it is very familiar and easy to pick up. It's Java syntax mostly with modern features and much less boilerplate code. The concurrency model is the same one you find in distributed languages like Erlang, Golang, and Akka Java or Scala. The bad parts of Dart have nothing to do with the language. Oh, and functions are first-class citizens which is my biggest gripe with Java.
> It's Java syntax mostly with modern features and much less boilerplate code.
Exactly. Dart is a sort of rational and modern variant of Java/C# language family. It is excellent in handling async/await.
I find Dart Code extension for Visual Studio Code fairly useful for developing Flutter. Dart Code as well as IntelliJ supports for flutter hot reload.
I'll jump to flutter when
1). scala supports dart backend (just my preference)
2). flutter solves 'calling native libraries/sdks' better. (current 'message passing' seems so weak - I want to do video processing/etc)
but for other use cases, flutter seems nice (for 90% of app use cases?)
This would be lower priority than Tablet so we will have to wait some time until we see any desktop app support. Even Dartlang does not have OOTB desktop app development support. However, I have conceived ways of hacking up a Dart desktop app using Electron / Dartium.
The FAQ says Flutter has basic accessibility support. I wonder what's missing. If there's a Flutter-based app on the iOS App Store that uses some non-trivial widgets, I'd like to try it out with VoiceOver.
I use it now for my news reader, mainly because it was written in flutter, and I wanted to get a feeling as an user how it does it. It works well on my Android Pixel XL, haven't tried it on iOS yet.
Also it works on ChromeBook... throuh ARC - there were some glitches, but after the recent updates (in ARC itself) I haven't seen them.
Actually scrolling might be still broken (but again this was something ARC is responsible, as other Android apps on Chrome are broken the same way).
Do you think this is a better option than Apache Cordova? I've been starting to look at Cordova to build some pretty simple apps for business applications.
Does anyone have an opinion on whether Flutter would be a better choice? Why?
I also looked at Xamarin but that seems a little in-depth for what I need, which is basically some data-input screens (using standard Web-style controls) and then to upload the data to an API.
Go for it, as long as the app will always be simple and you don't have a high bar for the UX. Both Angular and React work well with Cordova and it's a great way to leverage existing web dev talent.
Make sure that the Cordova APIs/plugins cover everything you need, because writing custom plugins can be a major pain.
You won't have a lot of performance headroom, especially on Android where some unsolved V8 bugs and inconsistent GPU support on older devices will hold you back. If things start to feel slow and it's a problem for the customer you may need to look elsewhere.
Nowadays the issue with app devlopment is not only having two OSes two develop for (and I doubt that Flutter is a real help here), the much bigger problem is user acquisition.
User acquisition got so insanely expensive for apps that there are few to none business models where you can justify or break even the user acquisition costs.
I wish I could upvote this twice. Distribution is the biggest problem in mobile.
I'll add that even after acquiring a user, engagement, apathy, and not being a 24-hour uninstall statistic are close seconds.
I'm working on a solution that's currently in private beta but it should be in public beta in a few weeks.
It is no different than anywhere else, there are tons of web sites and packaged software to chose from.
The only thing is that the gold rush of the app stores is gone.
I disagree. Yes the web is also competitive but it's 100x easier for a simple reason:
The next site ia just ONE single click away. The next app is few clicks and a download away, even without any sign-up, an app install is a gigantic conversion breaker. This is not comparable with websites at all. Anyone who does new apps in 2017 must have a good plan.
I don't agree, just because it is a click away don't mean the user stays long enough, does anything meaningful or even returns.
We primarely discussed the user acquisition costs in this thread and I pointed out a huge conversion breaker in the acquisition funnel of mobile which just let the costs skyrocket. If users stick or not after being acquired is as important but another discussion (rentention & churn).
If they click on link and close the window without doing anything relevant, they weren't acquired.
But the funnel till this point you mention is MUCH cheaper on the web than on mobile (where people also install and deinstall right away or never use that app). And this 'being cheaper' is the whole discussion around.
Well it is a matter how much marketing money you have spent to make them click on the link in first place.
User acquisition is always what makes a project into a product.
Two key questions:
* Are you providing enough value?
* Are you charging enough for it?
We can spare this discussion.
Of course there might be use cases which have a healthy CAC to LTV ratio. But almost none of them is B2C, except scammy dating apps and addictive fremium games. And some one-hit-wonder games which cannot replicate their success.
On the B2B side it's a bit better because of higher LTVs but all B2B apps have a web version where leads are generated anyways. So, mobile is just complementing but not in the user acquiring role.
But maybe you tell us if you are so lucky and have a, from a business-POV working, app which provides enough value and charges enough for it AND can acquire users for less than their LTV. Give us your example, we are curious to hear how you make money in the app stores (which is just hard to believe).
CAC > LTV = "not providing enough value", to my mind. That is, people are not willing to pay for it enough.
This, to my mind, also means that small paid apps indeed is not a reliable market. Either you need to go viral (a rare stroke of luck), or you have to complement an existing business of some sort (and it has a web site which is a powerful lead generator, this goes without saying).
So no, I don't have a good example, for these very reasons. When I will have executed on a a million-dollar idea (which is, of course, peanuts for a startup but could be a great side project), and it would happen to be in the mobile-only space, and won't be a freemium game, I promise to write a post.
This looks pretty neat, Dart is a nice language.
Flutter looks pretty different from React Native on one side and Cordova/webview based frameworks on the other side. Flutter is not based on webviews, but is also not using the native widgets but instead rendering custom widgets.
To me, this is a little weird. One of the downsides of Webview based apps is that it's harder to align with the native OS look and feel. React Native solves this problem, but Flutter clearly has the same problem.
Fluter has two widget styles, "Material" and "Cupertino", but I agree it would be better if Cupertino was backed by UIKit (then you'd get accessibility, UIAppearance, font sizing, etc. for free).
I recently prototyped an app in both Flutter and React Native. React Native feels incredibly fragile. Half of the month spent on a React Native app has been spent fighting with React and finding the right combinations of node and npm versions. Update some component and everything can fall apart.
Flutter's developer ergonomics are so much better. Time to first-running code was faster, and time spent due to broken shit outside my control was way smaller.
Is this still the case that you don't accessibility (on iOS) if you don't use native widgets?
Isn't there a way to "publish", "expose" say text and other information to the system? I believe for example Windows has this, and Qt on the desktop can use it (although there were still complaints, that some really popular brand of braille reader was not working).
Simply curious, as long time ago I was heavy proponent of native only widgeting systems (like wxWidgets), but lately in favour of self-drawn one, but imitating the interface (like Qt).
It might be more challenging without native widgets but it looks like it's still going to be implemented:
"Flutter has basic support for accessibility on iOS and Android, though this feature is a work in progress."
https://flutter.io/faq/#how-do-i-do-internationalization-i18...
https://flutter.io/widgets/accessibility/
I don't think this is possible on iOS. I don't think it is currently possible to achieve VoiceOver support, for example.
(Disclaimer: I work on Flutter.) As skybrian says, accessibility support is work-in-progress. But if you try an existing Flutter app (e.g. the official Hamilton App) you'll note that most aspects of the app are accessible to VoiceOver, just not quite everything yet. We're actively working on improving our iOS and Android accessibility integration.
If you wrap native widgets it is.
I don't think this is what they are doing, which is what I meant. How are Flutter widgets drawn on the screen?
(disclaimer: I work on Flutter.) Flutter uses its own renderer based on Skia. Flutter essentially asks the OS for an surface to draw onto, and then Flutter draws all the pixels through Skia.
In such case, this is what I feared; I don’t think it is possible to implement proper VoiceOver support with the current public API.
You should file bug reports with Apple to enable that.
If you write a native app programatically, you replace all your localizable strings with NSLocalizedString(@"string to translate", @"message for translator") - or similar in Swift. There's also support for localizing strings that you supply in your plist config files, which are strings for things like telling a user why you want a certain permission.
If you use a lot of Interface Builder (IB), then your localization support stems from all the basic UIKit widgets having support for localization built into IB, and in that case you'll end up building custom components on top of your UIKit blocks, and localizing via IB.
One of the views in an app I work on (a Settings view) also uses some plists to generate the table, so we end up having a bit of code to generate the NSLocalizedStrings for the stuff that's not actually in the source code.
Accessibility is not localization.
I wouldn't call "React Native" much more "native" than Flutter. Most of the widgets, while inheriting from UIView, are internal FB implementations. No system buttons, labels, navigation, animation, gesture recognizers, etc.
> To me, this is a little weird. One of the downsides of Webview based apps is that it's harder to align with the native OS look and feel.
I'd agree with that in 2014 but this has been much less of a problem since the last few years. The fast pace of mobile OS's have slowed down to a halt. IOS has pretty much the same looks since version 7, Android since version 5.
The metro/material/flat design fashion has been the best thing for cross platforms apps, be it desktop or mobile, any platform or any framework.
Flutter seems to be at the right place at the right time.
I didn't say it can not be done, but it is just harder.
I develop a lot of cross platform apps using Cordova. While this works pretty well, and indeed in recent years support for this is only becoming better, it remains that Webview based apps always feel just a tad off.
> IOS has pretty much the same looks since version 7
This can only be said by someone with a very little attention to details. There are constant changes to how the OS looks.
"Pretty much" already allows for it changing in "details".
So the parent is right.
And judging from the kind of non-native look apps that are nonetheless immensely popular in the app store, few care that much anyway.
> Flutter is not based on webviews, but is also not using the native widgets but instead rendering custom widgets.
Yeah, I only just realised this after further looking into it today (when I last checked their site, they only had one page introducing the project). They try to spin this from a negative to a positive[1], by saying that they think they can guarantee the Flutter widgets quality and performance compared to native widgets, and it's on them (the Flutter devs) to make sure those widgets are up to date to the look and feel of the platform.
Which to me just seems like trying to solve a non-issue in the first place, not to mention depending on the Flutter developers to ensure their supported widgets remain up-to-date to the platforms standards and not deviate in any way.
[1] https://flutter.io/faq/#does-flutter-use-my-systems-oem-widg...
Qt seems to have done a great job of this. There are occasional hiccups when OSX updates the look of their progress bars for example, but it never feels nearly as bad as Java Swing (when it's emulating the host OS) or wxWidgets (ironic, since they use native widgets like react-native).
So it can be done, but I imagine it isn't easy. Qt has years of experience doing it.
Counterpoint: Qt has done a terrible/non-existent job of this for iOS. Qt/QML apps look and feel pretty native on MacOS, and Qt & Qt Quick controls on Android devices look very close to Android native, but they've barely even attempted to implement iOS-looking controls. (It's bizarre how little interest they seem to have in supporting iOS. I don't know if it's because iOS doesn't have the styling APIs they need or what.) There is a third-party framework that partially addresses iOS issues (https://v-play.net/qt), but that's not an ideal solution.
For some applications (including the one I'm currently working on), you can get away with having nearly the same UI on Android and iOS, with just a little extra work to (for instance) give iOS users a more native-feeling navigation experience.
In regards to Flutter, I'm not sure if it's reasonable to expect the Flutter project to do a better job simulating native iOS widgets than Qt has been able to.
The problema is not only the UI and affects Android as well.
For the majority of OS APIs there are no wrappers, beyond of what is available on the desktop + hardware sensors.
So basic stuff like file pickers or asking for permissions aren't even supported.
I tried it once back in 5.4 and gave up on it, going back to Java / C++.
https://bugreports.qt.io/browse/QTBUG-42491
Are you sure that QT is not using native widgets? I always thought QT used native widgets and a quick search [1] seems to confirm this:
> Recent versions of Qt use the native style APIs of the different platforms, on platforms that have a native widget set, to query metrics and draw most controls.
[1] https://en.wikipedia.org/wiki/Qt_%28software%29
Seems to confirm it, but doesn't. What that means is Qt uses the native style APIs to get the system styles (e.g., theme color, highlight colors, default fonts/sizes, etc.), so it can draw controls that look like native controls. But it's drawing widgets, not using native widgets. In many/most cases, users will never know the difference, but it is different.
Blind users definitley notice the difference, because Qt apparently doesn't implement the platform accessibility APIs quite right, particularly on WIndows.
Two anecdotes:
1. The TeamTalk (http://bearware.dk/) voice chat system is popular among blind people. Originally when it was Windows only, it was an MFC application. Then when it went cross-platform, the developer used Qt. But the Qt version was inferior for blind users, so the developer still maintains the MFC version just for them.
2. Rant from a blind programmer trying to develop an accessible cross-platform application with Qt: https://blind.guru/qta11y.html
On every major platform, it's possible for non-native widgets to be accessible by implementing the platforms' accessibility APIs. But Qt doesn't do this very well.
That doesn't confirm use of native widgets. It confirms use of native styles.
iirc it uses native widgets, the problem was that for some time QT used Carbon and stuff like scrollbars looked outdated until they added cocoa support because Apple stopped updating visually carbon
>Which to me just seems like trying to solve a non-issue in the first place
Writing code once is a non-issue?
This gives you native performance, but the ease of development of a shared UI. Given that Material Design is gaining popularity on the web and iOS as well, apps made with Flutter won't feel entirely foreign either. And the Cupertino styled widgets will help, too.
"Material Design" apps on iOS are as foreign as ever, don't fool yourself.
I hear this a lot from iOS developers but actual users seem fine with it.
To my eye Material applications on iOS looks like what applications should be doing - taking the HIG and improving on it in their own way.
Material or not I do think that mobile UI's on Android and iOS are starting to converge more and more. Lot's of apps look very similar on iOS and Android and it doesn't have to fail alien at all, if well executed.
I find the convergence typically by design on the part of the Designers, PMs, and decision-makers up top as opposed to their actually being a need for convergence. I often attribute this to a strong lack of diversity of teams whereby there are almost zero Android users on the design/product team leading to a unified look.
It can also be attributed to laziness on the part of the PM and/or designer. Or in general, clients opting for cheaper solutions when hiring an agency to build apps for them.
I say all this to point out that, Android users often get the short end of the stick when it comes to app design. Often there is a strong lack of consideration on what is a native Android app feel. No consideration for the use of back-buttons, menus and UI elements using bottom navigations or custom ones instead of native Material design... Generally convergence is made for all kinds of reasons that ultimately leave Android users alienated.
> One of the downsides of Webview based apps is that it's harder to align with the native OS look and feel.
Is this really a problem though? It doesn't seem crazy to want your app to just look the same on all platforms.
No, it doesn't seem crazy, but it's also not really what users want. Android users probably expect native Android behaviour, iOS users definitely expect native iOS widgets, anything else will feel quite off.
I guess it depends on the app. Google's own apps on iOS don't strike me as feeling very native. I would think they'll get closer to nailing the Android behaviour. In a way these toolkits fill a space like Electron on the desktop where the developer won't, or can't, for all in on a native experience.
As someone who built some mobile apps with web technology I can see how Flutter would have an appeal because going into the project you've already given up on the native experience. There are still (unfortunately?) a world of marketing-driven apps with the brand overriding design choices which would be suited to this. Tools like Xamarin probably have a lead for line-of-business apps inside companies due to the MS ecosystem integration, but I could see people choosing Flutter for these apps if it's easy to build and maintain apps.
None of this changes the fact that for best-of-breed apps in a public store you'll need to use the native toolkits.
This reminds me of switching from Windows to Linux in the noughties: one of the complaints about Linux not being 'suitable for average users' was the lack of consistency between GTK/Gnome and Qt/KDE applications, and a lot of effort was spend on compatibility layers and such.
When I looked at a friend's Windows XP installation, it struck me that pretty much every application they used had a different UI system: WinAmp, Firefox, Opera, Windows Media Player, MSN Messenger, ...
> Google's own apps on iOS don't strike me as feeling very native.
That is true, but does anyone actually like the feel of google's iOS apps? I personally think they're awful, but the content they present is so useful that people use them anyway.
I don't disagree, but they have reasonably good performance which covers a lot of sins.
Sure, they don't stutter and they serve a crazy amount of very useful information.
Performance is not everything. I expect iOS apps to behave and look like iOS apps, not just run fast. Google's software looks like fisher-price third-rate crap on iOS.
This is very true when it comes to consumer apps, but in our experience businesses prefer a more unified experience for their users--it minimizes the training effort.
I wonder how much native look and feel really matters. Swing copped a lot of flack for not having native controls but I think this problem was miniscule compared to poor performance, bloated download and complex API. Web apps don't use native look and feel but have nonetheless been very successful.
The real downside of using flutter is that you can't embed (or inline) any native widgets like video or maps.
Thanks. This would be a blocker for me so it's good to know. They have an issue open on it, but no progress so far it looks like:
https://github.com/flutter/flutter/issues/73
An awful lot of apps use a map, and a static map in many cases isn't going to be enough. Likewise many apps will want to display video. Looks like they also have an issue open for webview support, which could be a problem too:
https://github.com/flutter/flutter/issues/730
But then I found this, so perhaps there is hope if you can launch it in a new view:
https://github.com/flutter/flutter/tree/master/examples/plat...
Looks like you could do the same for any view, so it's more that you can't have a subview which is a map or video etc, which isn't such a bad limitation (not ideal, but at least it's not impossible).
(disclaimer: I work on Flutter.) Hi, thanks for the feedback! Would you be willing to "thumbs up" this issue? https://github.com/flutter/flutter/issues/73 It helps us when triaging. Thank you!
This is one of the blockers for me as well. It can't embed web pages inside Flutter widgets.
Why is that Flutter does not have a web target? Everything is nice and fast about it, it's a shame that after building a cross mobile apps, you'll app to start the web app from scratch using another platform.
React Native doesn't either. Only via the third-party React Native Web project[1]. Which I'm sure something similar for Flutter can also be achieved if desired.
[1] - https://github.com/necolas/react-native-web
While it does not right now and I doubt the team ever will do that, it is open source. I'm sure the team will accept meaningful contributions. A meaningful contribution here could be to make the flutter backend system pluggable enough that 3rd party backends can be used without modifying core. Then a web, desktop or any other backend can be implemented outside of it.
I know for a fast that the core team is open to the idea of creating desktop backends but does not have the resources to do it. They'll gladly accept any contributions towards that.
My point is the web frontend target is such an obvious one here. Specially given the dart to javascript compiler history.
I have very good experience writing UIs in HTML's canvas, look at my repos
https://github.com/netdur?tab=repositories
I say porting Flutter to web using canvas (both have similar APIs) is very bad idea.
this repo closes the gap in sane way https://github.com/yjbanov/butterfly
I don't understand what you mean. Please explain.
Adding web as a target on top of the enormous complexity of ios/android is a siren song. These cross-platform codebases are already held together with popsicle sticks and bubble gum with just the two targets.
Of note is that Appcelerator did target all three simultaneously (as well as blackberry and windows phone), but eventually dropped web support.
Good point. I develop all my apps using Cordova and it really is a big win that I can run these apps right in the browser with little to no effort. It's pretty trivial now to develop a Progress Web App and package it up with Cordova for some visiblity in the App/Play store.
> We test on a variety of low-end to high-end phones (excluding tablets) but we don’t yet have an official device compatibility guarantee. We do not offer support for tablets or have tablet-aware layouts.
Thats a pretty serious, and surprising, limitation.
As far as I can tell, it's just something that will be added eventually. Given that Fuchsia OS applications are written in Flutter, and Fuchsia is meant for all form-factors -- phone/tablet/desktop, this is clearly something that is eventually going to be required.
In my experience with app development, having worked on multiple handset-to-tablet conversions as well as universal-upfront projects, it is a bear to add tablet in after the fact when it wasn't considered upfront.
And the opposite is also true, that if you do both along side one another, it really isn't that bad. I guess I'm just surprised they would be willing to tackle cross platform upfront (ios/android) but not cross form-factor (handset/tablet).
So eventually it will be usable.
Anyone using this and have experiences to report? I'm thinking of using it for a project soon. Specifically, how does it compare with 2x native apps for Android and iOS. How was Dart as a language, and the bindings to different native SDKs? What problems did you encounter when building apps on both platforms?
I'm a consultant & I have recommended Flutter for third app now, business owners love it, specially love that they don't have to maintain two separated code bases for a single app and getting ride of buggy, slow hybrid solutions.
None of programmers knew what is dart / reactive, we did fast sessions learning by using ES6 and react, once that (and state management) is understood we switched to dart and programmers found it very similar and fun... however, some programmers said they have understood state but they didn't, made naive mistakes and app worked well anyway, tests couldn't catch them, my code review did.
Android programmers couldn't believe hot reload button, very welcome upgrade of gradle, they don't like how UI is built (used to xml), I agree it is confusing nesting all those functions, you have to wrap your mind around it, I believe introducing XML or JSX to flutter would be a mistake.
The only complains is third part plugins, we had to drop Flutter where ads or some third plugins is a must.
Flutter is not a complete solution, you still have to write some android / ios code to make your app works well.
I haven't done enough with Flutter to really report on it but I like it better than React and Android's API so far. I do feel comfortable enough with Dart to say that it is very familiar and easy to pick up. It's Java syntax mostly with modern features and much less boilerplate code. The concurrency model is the same one you find in distributed languages like Erlang, Golang, and Akka Java or Scala. The bad parts of Dart have nothing to do with the language. Oh, and functions are first-class citizens which is my biggest gripe with Java.
> It's Java syntax mostly with modern features and much less boilerplate code.
Exactly. Dart is a sort of rational and modern variant of Java/C# language family. It is excellent in handling async/await. I find Dart Code extension for Visual Studio Code fairly useful for developing Flutter. Dart Code as well as IntelliJ supports for flutter hot reload.
https://marketplace.visualstudio.com/items?itemName=DanTup.d...
Xamarin.Forms is another option to consider in this space.
I'll jump to flutter when 1). scala supports dart backend (just my preference) 2). flutter solves 'calling native libraries/sdks' better. (current 'message passing' seems so weak - I want to do video processing/etc)
but for other use cases, flutter seems nice (for 90% of app use cases?)
Desktop browser support would be nice too
This would be lower priority than Tablet so we will have to wait some time until we see any desktop app support. Even Dartlang does not have OOTB desktop app development support. However, I have conceived ways of hacking up a Dart desktop app using Electron / Dartium.
Flutter is also the name of a company doing vision based gesture UI that Google bought in 2013 and hasn't been heard of since.
https://en.m.wikipedia.org/wiki/Flutter_(company)
React Native vs Flutter https://groups.google.com/forum/#!topic/flutter-dev/49DpZm0x...
The FAQ says Flutter has basic accessibility support. I wonder what's missing. If there's a Flutter-based app on the iOS App Store that uses some non-trivial widgets, I'd like to try it out with VoiceOver.
https://flutter.io/faq/#who-uses-flutter mentions Newsvoice https://itunes.apple.com/app/newsvoice/id1208421834 which looks like it would use some non-trivial widgets.
From the FAQ:
>We are aware of apps built with Flutter that have been reviewed and released via the App Store.
Which apps? I'd like to try them out and see how they look and feel.
The Hamilton app seems to be an example: https://www.blog.google/topics/developers/it-must-be-nice-ha...
Newsvoice is another
I use it now for my news reader, mainly because it was written in flutter, and I wanted to get a feeling as an user how it does it. It works well on my Android Pixel XL, haven't tried it on iOS yet.
Also it works on ChromeBook... throuh ARC - there were some glitches, but after the recent updates (in ARC itself) I haven't seen them.
Actually scrolling might be still broken (but again this was something ARC is responsible, as other Android apps on Chrome are broken the same way).
thanks
Do you think this is a better option than Apache Cordova? I've been starting to look at Cordova to build some pretty simple apps for business applications.
Does anyone have an opinion on whether Flutter would be a better choice? Why?
I also looked at Xamarin but that seems a little in-depth for what I need, which is basically some data-input screens (using standard Web-style controls) and then to upload the data to an API.
Go for it, as long as the app will always be simple and you don't have a high bar for the UX. Both Angular and React work well with Cordova and it's a great way to leverage existing web dev talent.
Make sure that the Cordova APIs/plugins cover everything you need, because writing custom plugins can be a major pain.
You won't have a lot of performance headroom, especially on Android where some unsolved V8 bugs and inconsistent GPU support on older devices will hold you back. If things start to feel slow and it's a problem for the customer you may need to look elsewhere.
Looks really promising!
if it supported web site as well i would have clicked the link and check it out.
If you mean Web Development then you need to look at just Dart which is the foundation of Flutter without the widgets, UI and Web platform sugar.
Stop trying to make Dart happen. It's not going to happen.
Shame this comment isn't sky rocketing between others.
Why? What is your problem with Dart language? Ever used it?
I thought the point was for Google to ween the developer off Java/Dalvik - by making Flutter the native toolkit for Fuchsia.
useless