22 ms·

Found this while evaluating options for moving away from React Native (which is not really working well for us). As much as I love Flutter/Dart, the big problem

by hliyan 8y ago

Found this while evaluating options for moving away from React Native (which is not really working well for us). As much as I love Flutter/Dart, the big problem: most of our users are on iOS, and Flutter being a Google project, seems to prioritize Android over iOS (RE: UI polish and runtime performance). Looks like we'll be sticking to native dev for a while...

sgt 8y ago
My view is simply that native is practically always better - if you have the resources to maintain two codebases. The biggest risk I see is that you're running two separate development teams (Android and iOS) with varying skills. On our last project, the Android code was of much worse quality than the iOS one (perhaps due to both tooling and Java null pointers; which can be attributed to poor development skills), so the projects did not match in terms of quality and sometimes even the way features behaved.
- fenk85 8y ago
  Which is what Kotlin solves, your junior devs would thank you for introducing it over Java
pjmlp 8y ago
I rather go with mobile Web for apps that should be web sites to start with, or native views with C++ business logic.
kitsunesoba 8y ago
IMO, every attempt thus far has approached cross platform entirely the wrong way. They’re all way too focused on providing deeply custom UI. I believe that it may better to instead abstract app navigation as its own separate thing, making it a setting in a config file (e.g. tabbed, hamburger, split-pane tabbed, etc) and restricting UI coding to individual screens, which would have style hinting abilities and could be built via any number of platform agnostic (and perhaps language agnostic) ways. All this would then compile down to native UIKit, Android SDK, UWP, AppKit, etc. So the idea would be you program your app’s individual screens, throw in some styling, select platform appropriate nav schemes (hamburger for android and tabbed for iOS for example) and hit compile to generate native per-platform project files+code. This sort of solution wouldn’t cover more complicated navigation schemes or use cases that actually require highly custom UI, but if you’re doing either of those you’ve probably outgrown any kind of cross platform solution anyhow. Realistically I believe this would work well for probably 80-90% of non-game apps and wouldn’t suffer many of the drawbacks that usually come with “silver bullet” style cross-platform setups.
- pjmlp 8y ago
  That is exactly what Office team and Dropbox are doing with their mobile apps. Microsoft used the term hamburger development at their CppCon presentations, with the meat being the C++ code and the bread for the native glue and views. :) Naturally one can use something else other than C or C++ for the library code, but then there is the additionall effort of adding yet another toolchain and debugging layer into the process.
- aaronbrethorst 8y ago
  Or you could abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend. I'm hoping that Swift becomes sufficiently viable on Android that I can reuse library code across iOS and Android sometime in the next few years.
  - kitsunesoba 8y ago
    Yeah, that wouldn’t be too bad. The main need when doing something like this would be a networking library that uses system provided networking (NSURLSession, etc) under the good rather than curl or something like that — not that curl or whatever else is bad exactly, but you’d be losing out on radio use optimizations among other things.
  - hliyan 8y ago
    > abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend Oddly enough, this is what we're going with...
  - fstephany 8y ago
    Looks like Kotlin gets the lead in this area with Kotlin Native. Jetbrains moves pretty fast and the integration works surprisingly well for something this young.
    - kitsunesoba 8y ago
com2kid 8y ago
What sort of issues have you been running into with RN? As of late, the spit and polish for React Native on Android has been getting better, with some features even being exclusive to Android here and there. Though personally I am super interested in Fabric, if they really do make native calls as easy and performant as they say they will it will make RN dramatically closer to native platform development.
- hliyan 8y ago
  Possibly unfair to point the finger at RN here, but we found that the amount and complexity of code involved in developing using RN + JS + Redux was much higher than when just using Swift (< 50%). We've yet to repeat the experiment with Android/Kotlin, but I'm confident we'll get similar results.
divan 8y ago
Do you have any concrete examples of the effects of this "prioritization" or it's just speculation? I use Flutter almost exclusively for iOS and I haven't seen any difference in development or user experience so far.
- hliyan 8y ago
  UI polish and runtime performance, as I've mentioned. I said "seems to" because I only see the effects: the Cupertino widgets, and the marked performance differences on Android and iOS (see the Alibaba article). I don't know whether this is purposeful or a side-effect of something else.

by hliyan 8y ago

sgt 8y ago

My view is simply that native is practically always better - if you have the resources to maintain two codebases. The biggest risk I see is that you're running two separate development teams (Android and iOS) with varying skills. On our last project, the Android code was of much worse quality than the iOS one (perhaps due to both tooling and Java null pointers; which can be attributed to poor development skills), so the projects did not match in terms of quality and sometimes even the way features behaved.

fenk85 8y ago
Which is what Kotlin solves, your junior devs would thank you for introducing it over Java

pjmlp 8y ago

I rather go with mobile Web for apps that should be web sites to start with, or native views with C++ business logic.

kitsunesoba 8y ago

IMO, every attempt thus far has approached cross platform entirely the wrong way. They’re all way too focused on providing deeply custom UI. I believe that it may better to instead abstract app navigation as its own separate thing, making it a setting in a config file (e.g. tabbed, hamburger, split-pane tabbed, etc) and restricting UI coding to individual screens, which would have style hinting abilities and could be built via any number of platform agnostic (and perhaps language agnostic) ways. All this would then compile down to native UIKit, Android SDK, UWP, AppKit, etc. So the idea would be you program your app’s individual screens, throw in some styling, select platform appropriate nav schemes (hamburger for android and tabbed for iOS for example) and hit compile to generate native per-platform project files+code. This sort of solution wouldn’t cover more complicated navigation schemes or use cases that actually require highly custom UI, but if you’re doing either of those you’ve probably outgrown any kind of cross platform solution anyhow. Realistically I believe this would work well for probably 80-90% of non-game apps and wouldn’t suffer many of the drawbacks that usually come with “silver bullet” style cross-platform setups.

pjmlp 8y ago
That is exactly what Office team and Dropbox are doing with their mobile apps. Microsoft used the term hamburger development at their CppCon presentations, with the meat being the C++ code and the bread for the native glue and views. :) Naturally one can use something else other than C or C++ for the library code, but then there is the additionall effort of adding yet another toolchain and debugging layer into the process.
aaronbrethorst 8y ago
Or you could abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend. I'm hoping that Swift becomes sufficiently viable on Android that I can reuse library code across iOS and Android sometime in the next few years.
- kitsunesoba 8y ago
  Yeah, that wouldn’t be too bad. The main need when doing something like this would be a networking library that uses system provided networking (NSURLSession, etc) under the good rather than curl or something like that — not that curl or whatever else is bad exactly, but you’d be losing out on radio use optimizations among other things.
- hliyan 8y ago
  > abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend Oddly enough, this is what we're going with...
- fstephany 8y ago
  Looks like Kotlin gets the lead in this area with Kotlin Native. Jetbrains moves pretty fast and the integration works surprisingly well for something this young.
  - kitsunesoba 8y ago

com2kid 8y ago

What sort of issues have you been running into with RN? As of late, the spit and polish for React Native on Android has been getting better, with some features even being exclusive to Android here and there. Though personally I am super interested in Fabric, if they really do make native calls as easy and performant as they say they will it will make RN dramatically closer to native platform development.

hliyan 8y ago
Possibly unfair to point the finger at RN here, but we found that the amount and complexity of code involved in developing using RN + JS + Redux was much higher than when just using Swift (< 50%). We've yet to repeat the experiment with Android/Kotlin, but I'm confident we'll get similar results.

divan 8y ago

Do you have any concrete examples of the effects of this "prioritization" or it's just speculation? I use Flutter almost exclusively for iOS and I haven't seen any difference in development or user experience so far.

hliyan 8y ago
UI polish and runtime performance, as I've mentioned. I said "seems to" because I only see the effects: the Cupertino widgets, and the marked performance differences on Android and iOS (see the Alibaba article). I don't know whether this is purposeful or a side-effect of something else.