The Persistent Gravity of Cross Platform

&gt; Inconsistencies both small and large had crept into our apps over time. From small things like password strength being different between platforms to larger things like differences in search results and entire missing features.<p>The solution that has worked well for me in the past, has been:<p>1. Keep all of your business logic and as much of the rest of your code as possible in platform-neutral C or C++: Something you can call into from all native platforms.<p>2. Write a very small layer of code using the native language&#x2F;frameworks to do the UI and interact with platform-specific APIs.<p>This has a few advantages: You get a single code base, for the most part, to maintain. You have the opportunity to implement as native a look-and-feel as you want, on each platform if you want. Most of your application is C or C++ so you don&#x27;t need a team with deep expertise in multiple languages. Most of your development <i>should</i> be on the business logic, right? This architecture also lets you easily add a command-line version of your product, for example to help with automated testing of your business logic. And finally, you don&#x27;t have to ship a huge, memory-devouring browser and JavaScript stack with your application--your users will thank you.<p>It&#x27;s not rocket science or anything to be terrified of! I think people too quickly dismiss cross-platform native because they imagine re-writing their application in 3-4 different languages, but it doesn&#x27;t have to be that way.

That&#x27;s a great article. I think I understand better the anger that certain people (often mac users) express when a product switches from a native app to a cross-platform app. I always thought it was about cost, and that the solution was to pay more. But it seems to be about the business thinking they know better than the user what a good user experience is. If you&#x27;re picking a platform for the consistency of user experience, I understand how frustrating (and patronizing) that can feel.<p>I want to apologize to the few people that I talked to about this here on HN. I didn&#x27;t understood your side.

It&#x27;s hard to justify my desire for awesome Mac-only apps without considering the spectre of future Apple lock in.<p>Electron has made it possible to use a lot of apps that otherwise wouldn&#x27;t have been ported to Linux work with no hassle, and for that I&#x27;m grateful. I have only recently been able to comfortably run Linux full time. My dev experience on Linux is effectively identical to what I do on macOS: Docker, VSCode, Alacritty, and Discord (to talk to my team). Of course Discord and VSCode are both Electron apps, and Docker just lives on the command line. Alacritty, on the other hand, is an extremely interesting example to me, as it is a true native program that uses cross-platform GPU acceleration through OpenGL. I feel that route is overlooked as a path towards compatibility for a lot of programs outside of games.

In my experience it&#x27;s the coordination and mental overhead between the platform teams that kills productivity.<p>I suspect that hiring and training cross platform developers, then having them own a feature across all platforms will significantly increase speed of delivery of that feature. These are typically called feature teams and they are most effective when there are backend developers on the team as well.<p>The trade-off is that now the new feature teams are not communicating between each other and coordinating on the common code between them, which starts affecting productivity.<p>In the end, regardless of how the new VP of engineering likes to split the teams and get praised for solving the current problem by introducing another one down the road, the trade off for increased size is loss of productivity due to synchronization overhead between the people involved.

&gt; “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?”<p>If this is the case though, why when I follow links to strong web apps like Twitter and reddit and Facebook, do I got plagued with “try the app! It’s better!” prompts?<p>I developed&#x2F;maintain 2 apps that both have native variants. So 4 apps total. And I often bemoan the duplicity and wonder if we shouldn’t unify them. But then I see that the web guys are still pushing me to use native apps. I find it very circular&#x2F;confusing.

This is a really really good article:<p><i>&gt; “What is it about enterprise companies that make so many of them abandon native apps, when they could surely afford to develop one app for each platform?”</i><p>Another way to think about the article&#x27;s thesis is that organizations never deal directly in simple &quot;costs&quot;, like &quot;Can I afford to spend X on Y?&quot; They always evaluate in terms of <i>opportunity cost</i>, &quot;Would I rather spend X on Y or Z?&quot;<p>Once you frame it like that, you realize that the choice between native versus cross-platform is, as the author states, often a choice between fidelity and velocity. And in today&#x27;s software environment where hardware and user needs change very quickly, velocity often wins.

Shipping a whole browser engine along with arbitrary Node.js dependencies doesn&#x27;t seem exactly a safe recipe for a password manager.

This hits the nail. Cross-platform as a cheaper option only comes true if the multi-platform feature delivers real value to the users --which is obviosly the wager that Agile Bits is doing. Otherwise someone else is bound to deliver a similar feature set either with a less price point or with better execution using native frameworks.<p>Counterpoint: multiplatform frameworks are web-based and thus are easier to learn and have more developer mindshare than native frameworks. But native frameworks are not that much more complicated these days and can use proprietary services: would you roll your own sync or use CloudKit?

There is absolutely no reason we can&#x27;t have a very good lightweight native UI compatibility layer.<p>Look at this heroic effort by a single developer:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;andlabs&#x2F;libui" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;andlabs&#x2F;libui</a><p>It&#x27;s not there, but it&#x27;s probably too big of a project for one person.

Often the choice is between a cross-platform app vs a native Windows application only. That is because Mac users are of course important, but maybe not enough to pay for a separate native Mac app.

I worry that everyone is trained for web, no one is trained to write native apps outside of phones, and so the problem will become harder to correct.

The confusion factor here is that &#x27;cross-platform&#x27; has become fairly synonymous with &#x27;Electron&#x27; (if desktop is one of your targets). It is possible to build cross-platform stuff that is performant. In the past I used wxWidgets for the classic Enterprise app that was cross-platform between Windows and Linux. The UI wasn&#x27;t the prettiest thing in the world (you regularly end up with dated looking widgets) but it was snappy, and the UX was good.<p>It&#x27;s continuously astonishing to me that there isn&#x27;t another workable UI platform that doesn&#x27;t require bringing a whole browser. Or is the HTML&#x2F;CSS&#x2F;JS UI the killer feature because you can share things with the browser implementation (or share skills with a browser frontend team)?

As long as there are platforms with enough market cap, there will be a need for cross-platform. And the easiest path wins. ElectronJS is the easiest path. My company relies on it.

The article seems fairly confusing to me.<p>First, I&#x27;m not even sure I understand what the author means by &quot;cross-platform&quot;. At some point, he mentions Figma and Slack. What platforms are we talking about? Does cross-platform mean &quot;web-based&quot;? Lots of people use Figma&#x27;s web incarnation ... is that cross-platform? Or is it cross-platform in its &quot;native&quot; Android&#x2F;iOS apps? More people use Slack in it&#x27;s app-based incarnation (probably), but those are not implemented with the same tools as the desktop version(s).<p>I suspect the article suffers from the myopia often on display here at HN, in which essentially all software development involves some datastore, a means of entering data (often by one set of users) and a means of display the data in various ways (often by a different set of users). This used to be called &quot;application development&quot; in the 1980s, and these days there&#x27;s a lot of writing about s&#x2F;w development (and a lot of comments about that writing) which seems to be based on the idea that this the ONLY kind of s&#x2F;w development there is.<p>This vision excludes most &quot;creative&quot; software, all gaming software, most development tools, a great deal of technical&#x2F;scientific computation, a large amount of automation software, and all actual computing platforms (kernels &amp; user-space environments).<p>Those of us who have been doing native desktop application development for decades have an entirely different take on this stuff from people for whom &quot;cross-platform&quot; means &quot;web, android and&#x2F;or iOS&quot;. We&#x27;re not &quot;more right&quot;, but we know about toolkits that work on macOS, windows and linux (gasp!). We&#x27;ve been compiling our software on multiple platforms for a long time, not relying on interpreters and VMs. We&#x27;ve had to grapple with packaging and runtime library questions for longer than web browsers have existed.<p>Electron has got a group of people excited because it appears to move web-based development approaches onto the desktop, which is a totally different model than the one taken when using a cross-desktop-platform toolkit. It doesn&#x27;t add to the list of such toolkits, it creates a totally different approach to tackling the problem, with the promise that the result could also be used for a web-based version, somehow.<p>In my case, having been developing a &quot;creative&quot; application for 20+ years that runs on windows, macOS and linux via a cross-platform GUI toolkit (and C++), switching to a model that included web front ends (e.g. Electron) let alone mobile platforms, would be even more disruptive than just switching to another of the existing desktop cross-platform GUI toolkits, and in that sense, it&#x27;s essentially a new development process entirely.

Cross-Platform versus Native is a false choice.<p>It is perfectly possible to do both.<p>You don&#x27;t have to use something like Electron or even Qt to make cross platform apps or games.

I can&#x27;t help but believe that the native vs crossplatform tradeoff will eventually go away when someone does a good enough crossplatform library...<p>Video games are cross-platform and polished and fast and they have been so for a while now.<p>When someone comes up with a Unity for desktop applications, that&#x27;s when this problem is going to go away.<p>I hope Sciter.Js is going to be it.