For a first-class user experience on desktop and mobile, native development techniques are the gold standard for various reasons. But is it the only reasonable approach to build user-facing non-web applications?
Published on Wed, October 13, 2021
This morning I stumbled upon a tweet regarding Visual Studio for Mac and an article looking at Microsoft Teams. Two products Microsoft is actively working on ditching fundamental cross-platform building blocks.
The desktop client of Microsoft Teams is long known as a notoriously bloated, memory-eating beast. This is mainly attributed to the fact that it is based on Electron, the underlying cross-platform desktop runtime powered by Chromium and Node.js. Electron will now be replaced.
The criticism regarding Visual Studio for Mac does not revolve so much around its performance but the non-native look and feel it provides to its users. So the product team decided it was worth rebuilding the user interface and making it a first-class citizen for the Mac.
So far, so good. I think there is nothing wrong with both decisions. As a (former) user of both products, I can relate to the pain points. However, the more critical problems Teams suffers from stem from bad UX decisions made for the actual web application within the desktop chrome.
However, what’s interesting to me is the commentary:
x-platform apps never work over the long term.
(Source)
Zero. I have seen it work zero times long run. Still embattled on whether good strategy for early startups seeking to get off ground. But just paves way for pain later. Torn.
(Source)
My take: It is absolutely worth it. And it has been worth it in the two cases mentioned here, too.
Microsoft did with Teams what it always does – it copied a competitor (Slack), used their platform power to promote it, and made it a successful product. To doing so, they had to be able to move fast. I am using both products at the moment. Even though I still like the “personality” that comes with Slack, I have witnessed Teams moving ahead in many aspects over the last years (e.g., video calls). That would have been hard to achieve, if not impossible, if they had implemented the client fully native on all relevant desktop operating systems.
The story for Visual Studio for Mac is different, but the pattern is the same. Its ancestor is MonoDevelop, an open-source IDE that Xamarin picked to deliver an end-to-end user experience around its cross-platform software development kits. In 2013 they announced Xamarin Studio, which was basically a redesigned version of MonoDevelop. As the company got sold to Microsoft in 2016, I am convinced that Xamarin Studio was a highly valued asset in the overall package. After all, Microsoft did not abandon it, as it does with so many other products all the time. Instead, it rebranded it (again) to Visual Studio for Mac and kept investing in it until today.
So for both cases, the move towards a more platform-native implementation makes sense. Today. As made the decision to go cross-platform back in the day.
Even large enterprises like Microsoft have limited budgets for such products, especially if they only contribute indirectly or as part of a larger package to their revenue.
If you are starting out, you will naturally be constrained in resources as well. You probably will be for a long time, if not for the whole lifetime of the product you’re about to build and ship.
So try to consider all available options. Building things for multiple platforms in a fully native way isn’t free lunch. It’s actually costly and resource-intensive. You need specialized developers and designers. You will probably even want to have product managers with platform-specific UI and UX knowledge.
The market of mature cross-platform software development tooling offers a broad range of options for all kinds of flavors, believes, and budgets. Get started there. Then evolve as you go.