If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web?
As to "availability", desktop app stores have become more prevalent over time, not less - which means that if this actually were a contributing factor, you would see more developers and people using desktop software, not less.
And as to "discoverability", there's no mutual exclusion between a webapp and a native application - in fact, the two values add. Making both makes your application strictly more discoverable.
All of these reasons seem somewhat disconnected from reality. I'm pretty sure the reason is simpler: companies want to get the highest ratio of revenue/users to development costs that they can (regardless of the negative externalities toward users e.g. performance and UX), and the trifecta of Android+iOS+webapp (combined with the fact that consumers now accept web applications in lieu of desktop ones) allows them to do that.
> If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web?
In my experience at a FANG company, it turns out that building and supporting three separate code bases is (counterintuitively) faster and more productive than a unified code base.
We took a stab at this using Reactive Native and C++. It’s been a couple years at least since we did this, and so disclaimer: this might not be the case today. I am also no longer with that company.
The developers hated using RN. In 80% of the use cases, everything worked ok. The other 20% of the use cases consumed 90% of the teams time, and we effectively had to hire engineers who were experts in iOS, android, AND now react native. Meanwhile, the total amount of time to launch a new feature did not decrease.
Our C++ path had its own problems. Building dependencies across different architectures was a nightmare at times. My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down, and we quickly worked around the learning curve. This worked for us because we weren’t writing low level system code but just business logic.
When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own. This was frustrating enough that we experienced significant turnover, and we lost very valuable teammates.
In hindsight, we took both of these paths inorganically. These decisions were made by senior staff engineers and upper level management. It pissed off a lot of developers and lead to a lot of turnover. I have friends at that company, and they are again thinking about going back in the same direction.
> My organization didn’t really have C++ developers. Surprisingly this didn’t really slow us down
> When it came time to integrate into our iOS applications and several android applications, we again ran into build issues. We had many copy and pasted CMake scripts, which no one really understood and no one really wanted to maintain and own
Seems like the lack of C++ developers did slow you down. C++ developers knows how to make proper build scripts and wrap platform specific code to make their codebases portable.
Sure. What I was trying to convey was that we were able to quickly write business logic and test the logic for functional correctness. We had initially assumed that writing sleep plus pluswas going to be very difficult, big prone, and tedious. Surprisingly this didn’t slow us down. But building and integrating was extremely expensive.
Yeah, C++ isn't really that hard to write if you are experienced with unit testing in other languages. The big hurdle comes from managing the build system since it integrates with the language and there is no default way to just build and run things, this is very different from most modern programming languages. Which is why for team projects you shouldn't use C++ unless you have a person experienced with C++ who can set that up and manage it properly.
Indeed, for mobile, there are different scenarios : if your mobile app is the core driver of your service, than your problem is having them on play store and app store.
The "cross platform mobile" APIs are less than stellar,but maybe you can get by with one codebase. Otherwise two is just a requirement.
On the other hand, if mobile is just an afterthought, than a WebApps with a few media query is the reasonable choice.
> consistency with the UI conventions of a given desktop operating system
Desktop conventions sort of exist for macOS but definitely do not exist for Windows or Linux.
I won’t go into Linux because I don’t want to deal with that energy right now, but Windows is an absolute mess:
- WPF
- WinUI (2 and 3, totally different)
- WinForms
- MFC/Etc
- WebView2 (basically electron but being promoted as first class for some reason)
Even within Microsoft’s own apps they can’t agree on UI conventions (e.g. are things round or square - Maps and other built ins use both).
On web you have to totally create UI from scratch, which usually means bootstrap or your company’s design system. Turns out windows desktop is basically the same, because apps have to create their own look from scratch - even Microsoft’s own native apps (Office, Visual Studio, etc) don’t use out-of-the-box UI.
Of course for new work Microsoft is mostly using Electron or WebView2, which should be telling (Teams, VS Code, etc). On the developers side, they’re pushing blazor, which is relying on electron or webview2 for the desktop story.
> WebView2 (basically electron but being promoted as first class for some reason)
Rendering a webview using the OS should have much lower disk & memory overhead than bundling chrome + node. In theory, there's no reason it should be higher than the cost of a tab in a browser. I'd love to see some benchmarks though.
> If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web?
They often don't. Loads of companies ship on iOS first and Android later. There are also widely used frameworks for building your app in javascript so it is the same code on both iOS and Android just living in WebViews.
Touch is wildly different as an interaction paradigm compared to mouse + keyboard. So that's the reason for the mobile app.
You'll make your life much more difficult doing an Android app in a language that's not Java or Kotlin, or doing an iOS app in a language that's not Swift or Objective-C, so that's why most apps which are the same between Android and iOS are mainly web views.
> If "time to ship" is actually important, than why do most companies go to the work of making three separate codebases for their applications - Android, iOS, and web?
Because if you develop for the web and handle the REST/other APIs well, it can be trivial to work on the mobile frontends that connect the interfaces (whether on Android or iOS). It becomes more a matter of plugging the right pipes.
Whereas the backend for desktop apps across systems may be completely different; you may create more work to handle the idiosyncracies of different OSes.
As to "availability", desktop app stores have become more prevalent over time, not less - which means that if this actually were a contributing factor, you would see more developers and people using desktop software, not less.
And as to "discoverability", there's no mutual exclusion between a webapp and a native application - in fact, the two values add. Making both makes your application strictly more discoverable.
All of these reasons seem somewhat disconnected from reality. I'm pretty sure the reason is simpler: companies want to get the highest ratio of revenue/users to development costs that they can (regardless of the negative externalities toward users e.g. performance and UX), and the trifecta of Android+iOS+webapp (combined with the fact that consumers now accept web applications in lieu of desktop ones) allows them to do that.
reply