3 ms·

You could make another app for Android. I think it's an unsettled question that one cross-platform app is a better business move than two independent apps.

ChrisMarshallNY 5y ago
There are use cases, where a hybrid system is the most useful path. These are usually cases, where the main product is a server-based service, and the apps are really fairly basic "skins" of the service. But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice. No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong. If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved. No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.
- krzat 5y ago
  > But usability is always reduced, in cross-platform systems. A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case. On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.
  - steve_adams_86 5y ago
    I’m not sure vscode (or JS for that matter) is necessarily slow anymore. I find the potential for speed in the JavaScript world often comes down to good design decisions. vscode performance issues have often been resolved with better design. These days it’s impressively snappy. Of course there are limitations and JS isn’t a top shelf performance language, but for most things with a UI it is pretty good now. Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example. By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.
- steve_adams_86 5y ago
  This is my experience with using React Native. I commented on it recently in another context, which was that my team of relatively competent people had a surprisingly hard time keeping the build and deployment pipeline happy. It was a lot of overhead. We essentially had to live with knowing we had low confidence in it, and there wasn’t much to do about it. Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc. But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right. You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools. We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things. I’m not particularly successful in software so who knows, I’m certainly not an authority.

ChrisMarshallNY 5y ago

There are use cases, where a hybrid system is the most useful path. These are usually cases, where the main product is a server-based service, and the apps are really fairly basic "skins" of the service. But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice. No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong. If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved. No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.

krzat 5y ago
> But usability is always reduced, in cross-platform systems. A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case. On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.
- steve_adams_86 5y ago
  I’m not sure vscode (or JS for that matter) is necessarily slow anymore. I find the potential for speed in the JavaScript world often comes down to good design decisions. vscode performance issues have often been resolved with better design. These days it’s impressively snappy. Of course there are limitations and JS isn’t a top shelf performance language, but for most things with a UI it is pretty good now. Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example. By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.
steve_adams_86 5y ago
This is my experience with using React Native. I commented on it recently in another context, which was that my team of relatively competent people had a surprisingly hard time keeping the build and deployment pipeline happy. It was a lot of overhead. We essentially had to live with knowing we had low confidence in it, and there wasn’t much to do about it. Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc. But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right. You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools. We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things. I’m not particularly successful in software so who knows, I’m certainly not an authority.