Because "time to ship", "availability" and "discoverability" are much more important concerns to many business than "consistency with the UI conventions of a given desktop operating system".
* "Time to ship"
Going the "native" way for desktops means doing specific work for Windows X, Windows Y, Windows Z, MacOs Whatever, than MacOs Whatever-Beta-Plus.
Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps.
The choice of leaving those problems to the Chrome team is _really_ tempting.
* Availability
Popular Desktop OS have not historically integrated "app stores" or "canonical way to install an app".
Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website.
* Discoverability
People don't care about your app. Really, they don't.
But they have chrome on their computer (it came preinstalled, and they need it for Facebook), so at least you get a chance to grow your user base if you manage to put a link to your website in your facebook feed, or, if they're high-tech users, as an ad on the top of their google search result (also knows as "the internet".)
The only exception, as usual, is games, because:
* they need to run native code and can't afford the dozen layers of inderection of a browser
* their users are dedicated nerds who will happily glue toxic chemical products to the CPU of their opened motherboards in order to get 1 more frame per seconds
* the install process of game exists, it's called Steam
> Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website.
Or just the limitations of permissions. A business team can adopt a SaaS unilaterally. Anything installed involves IT.
This is why the runtime libraries __have__ to be shipped by the OS vendor. It isn't good enough that Windows (or OSX for that matter) includes only stuff for it's OS. It should include a standard that is compatible with every other major platform too.
We don't even really get that with Electron either; all of those apps are 'fat' in that they ship the entire standard library for doing anything with 'Hello World'.
Ok, I guess "BU" here means "business unity" (I can't remember ever seeing that term), but I can't imagine what "SSO" could be that would crack-down on people signing on internet services.
Oh, ok, that makes sense. But there are a couple of fixes. You create the account with your corporate email. You just need the password.
And that part: you're potentially giving sensitive corporate info to the SaaS app, with your personal email, and you risk getting fired for that
If that one part is real, than SSO isn't adding any power to you (or to the DSO anyway). If it isn't, then the only thing SSO changes is the password one.
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.
> 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.
> 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.
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.
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.
>Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps.
Do you have examples? I'm not using many apps I guess.
* "Time to ship"
Going the "native" way for desktops means doing specific work for Windows X, Windows Y, Windows Z, MacOs Whatever, than MacOs Whatever-Beta-Plus.
Even using the "write one, use everywhere" framework entices such work, because of the dirty secret no one talks about : they don't really work besides simple apps.
The choice of leaving those problems to the Chrome team is _really_ tempting.
* Availability
Popular Desktop OS have not historically integrated "app stores" or "canonical way to install an app".
Asking them to "Install" stuff is great if they're nostalgic geeks like us ; but real people learned long ago that anything asking the right to "install" on their computer is malware from a shaddy gambling website.
* Discoverability
People don't care about your app. Really, they don't.
But they have chrome on their computer (it came preinstalled, and they need it for Facebook), so at least you get a chance to grow your user base if you manage to put a link to your website in your facebook feed, or, if they're high-tech users, as an ad on the top of their google search result (also knows as "the internet".)
The only exception, as usual, is games, because: * they need to run native code and can't afford the dozen layers of inderection of a browser * their users are dedicated nerds who will happily glue toxic chemical products to the CPU of their opened motherboards in order to get 1 more frame per seconds * the install process of game exists, it's called Steam