Hacker News Reader

Comment by robterrell | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com