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.