7 ms·
As a native mobile developer of several years, I've always been somewhat skeptical of the various cross-platform solutions that have emerged over the years. Th
by roughike 9y ago
As a native mobile developer of several years, I've always been somewhat skeptical of the various cross-platform solutions that have emerged over the years.
The WebView-based solutions weren't fast enough and sometimes behaved differently across devices because of different WebView versions. With React Native, the impression was far better because the performance actually can be quite good. But it's still hard to abstract the UI layer away when even the native Views on Android behave differently across devices and Android versions. I had to use almost a half of a day for fixing invisible drop-down menu items on some specific Samsung device on Android 4.1.2. Not to mention when you have to abstract the UI for both Android & iOS, which brings its own set of problems. It's one of the reasons why such a fundamental thing as navigation has been so hard to get right.
I feel Flutter is the first cross-platform SDK that gets something fundamentally right. Since every pixel on the UI is rendered by the framework, we as developers have better control of everything. It's going to have much better performance because there are no bridges between native and cross-platform land. Additionally, Samsung can't fuck up our UIs: once the UI works, it works the same on every device.
As a bonus, they also keep tremendous care of their codebase and they have the best documentation I've ever seen. My really simple, quick 4-line fix didn't go through until I wrote 30 lines of automated tests to go with it. After all, Flutter is going to be the native SDK for developing apps for Fuchsia, and I think Google has learned not to repeat the same mistakes that happened with Android again.
- discreteevent 9y agoIn fairness Qt also gets this right: It renders every pixel and it has a fast rendering architecture. Having used Qt, flutter is very attractive to me for the case where you have to work with a team. It can be hard to get together enough people nowadays who will want to work with even a little C++. The Qt libraries make it very easy IMO (most stuff is ref counted) but not everyone is going to buy that.
- mherrmann 9y agoI use the PyQt Python bindings to Qt for exactly that reason(?) It works very well for my file manager [1]. [1]: https://fman.io https://fman.io
- roughike 9y agoQt is one of those things that I've heard of before, but did not know was still used for mobile development today. The monthly commercial license fee is a bit of a downer though. I feel that a lot of software development agencies (my workplace included) are just not gonna bother with it and just use something free instead. I agree about the C++ point with you. I have to confess I'm also one of those people who generally want to do things on a higher level. Would definitely give Qt a try if it was free for commercial purposes though.
- ameliaquining 9y agoThe free license for Qt is the LGPL, which, although more restrictive than a fully permissive license like BSD or MIT, is still suitable for many commercial applications. (You can't ship proprietary modifications to Qt, but you can ship a proprietary app that includes Qt as a dependency. Your app can use a modified version of Qt if you open source your modifications.)
- symlinkk 9y ago> It renders every pixel I thought Qt was "native"? That's what's parroted around here when comparing it to Electron.
- lilactown 9y agoIt's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. But it does not interact with native APIs; it re-implements the native platform's look and feel.
- symlinkk 9y ago> It's native in the sense that it doesn't bundle an entire Chrome browser runtime with it. So it's not native.
- zokier 9y agoLive and learn. https://www.quora.com/What-do-software-engineers-mean-when-they-talk-about-native-code-and-how-it-might-be-faster-than-other-code https://www.quora.com/What-do-software-engineers-mean-when-t... > Native (machine) code is code that is ran directly by the processor, in contrast to code that runs on a virtual machine or through an interpreter.
- symlinkk 9y agoYou're applying the word "native" to the wrong thing. "Native" in the context of GUI frameworks doesn't have to do with code being interpreted vs compiled. It means the framework creates UI using the toolkit that ships with the OS you're targeting. It means Cocoa on MacOS and UWP or WPF or WinForms on Windows. It means when you scroll past the end of the text in a textbox you get a bouncy effect on macOS just like every other Mac application, because it's ultimately calling the same function that every other Mac application calls. If someone made a JavaScript library that wrapped Cocoa and UWP, it would be called a "native" toolkit, because it wraps the controls that are shipped with each OS. That's why React Native is called what it is - it's actually creating dialogs and views on iOS with the same functions you would call if you were doing it in Swift.
- vvanders 9y agoThere are pros and cons. One of my big concerns around something like Flutter is accessibility. When you render everything on your own you lose the ability to hook into system-level frameworks for accessible content discovery. Their FAQ mentions it briefly but looking at the API support seems pretty sparse.
- roughike 9y agoAt least on Android, it turned out that if you claim that specific portion of the screen is, for example, android.widget.ScrollView, the system believes it. This can be verified with the HierarchyViewer. Some people in Flutter's Gitter group were confused because of this, since they thought Flutter doesn't draw its own widgets. While in fact it was the early accessibility implementation.
- sethladd 9y ago(disclaimer: I work on the Flutter team) 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!
- Illniyar 9y ago"Since every pixel on the UI is rendered by the framework" This is a deal breaker for me. It's not about the ui feeling a bit off - the drawer going over instead of pushing things or some such, it's about losing the integration with the native OS. For example the android version of the gallery app shown elsewhere doesn't adjust to font size changes (which can be done at the system level), won't make a sound when clicking things if sound on tap is set, has no accessibility support. Rather then marking the entire word double tapping on a word in an input-text does nothing, long pressing on the input opens a non-native menu with cut/paste/copy while a regular input has share and translate (at least for me). And this is just a minute of tests, it probably fails to integrate into the larger ecosystem in a gazillion ways - many of them you'll find out when users complain about it once you go into production. This was tried before (for instance Java's swing vs SWT) it almost always results in eventually outdated slow interfaces that are a pain to migrate to newer technologies.
- sethladd 9y ago(disclaimer: I'm on the Flutter team) 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 https://github.com/flutter/flutter/issues/12311
- bjano 9y agoI also use a cross-platform framework that "renders every pixel". The two major problems I had are the lack of native input and the integration with native ad SDKs. I solved the input with overlaying a native input view on top of everything but it's very clunky and have to be careful to keep it the topmost in the view hierarchy. I haven't found a solution for native ads. Most of the other things are relatively easy to solve if they come up as actual problem.
- pavlov 9y agoI don't like the approach either, and the point about accessibility is an important one that's very much non-trivial (but developers often ignore it completely at first). It's like making a web page that renders everything inside Canvas elements. If that doesn't seem like a good idea to you -- why would you build your mobile apps that way?