Thanks for your feedback! I opened https://github.com/flutter/flutter/issues/12438 to track the "not playing a sound when tapped". We're currently working on improving our accessibility support.
Thanks for the feedback! We are working on improving our accessibility now, which is required for our business-critical Google users and others. For example, you can follow this issue if you're interested: https://github.com/flutter/flutter/issues/12311
Thanks for the feedback. We're currently exploring how to do inline video, which we think will teach us about techniques for inline maps. These are very top requested features. Stay tuned! :)
We're working on accessibility right now, it's incredibly important to us and our users. A big driver here is Google's usage of Flutter. There are business-critical teams at Google right now using Flutter, and they can't launch until a11y is finished. So we're working to finish and ship it. Stay tuned!
> What do I see when I'm running an older native version?
You will see exactly the pixels that your designer intended and your developer coded. :) Apps built with Flutter ship the renderer and framework inside the app, which helps ensure consistency and fidelity across devices, OEMs, OS, and platform. This is particularly important for brands that want a brand-first design delivered consistently to all their users. Hope that helps!
(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!
(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.
Notice how we're auto-inserting "synthetic" comments to clearly mark the closing parens/brackets. So far, the feedback has been very positive, it helps improve scanning and reading the code.
One of the reasons we picked Dart was that is compiles to ARM (native) code. Dart has been pretty efficient for the project so far, but we haven't yet looked very deeply at battery life. Something to keep an eye on!
It's true that Dart is an optionally-typed system, and that type annotations are ignored at runtime. That may seem scary at first, but we built an analyzer that statically analyzes your program and gives you feedback (errors, warnings, and hints).
Dart is used at Google to build very big and complex apps, and our engineers use the analyzer in their build/CI systems to check their program. The analyzer is also wired into their IDEs. So they get feedback if a method doesn't exist, or you are trying to pass a variable into a method that is expecting something else.
The Dart team is also working on an optional analyzer feature called "strong mode", which does even more static checking. In strong mode, you can't write code that is incorrectly typed (but, you can still write code that is dynamically typed, if you want to).
Our experience, at least internally, is that as your program matures and grows in complexity, developers appreciate the extra checks provided by strong mode. The win is that it's something you can turn on later, when you're ready. Early on in the program's development, you are probably refactoring a lot and you don't want to bother with strong mode. This scalability is a win for us.
Yes, strong mode is something the Flutter team uses to help check their code.
Dart is pretty cool this way: you can scale up or down how much "typiness" you want. As your program matures, you can dial up the static type checking. Hence: strong mode.
Thanks for your feedback! I opened https://github.com/flutter/flutter/issues/12438 to track the "not playing a sound when tapped". We're currently working on improving our accessibility support.