Ofcourse there is something stopping it: money. Resources are finite, resources spent on implementing the same features on 3 platforms instead of 1 cannot be spent on other things.

Both Slack and Discord can afford one good person, given that they employ many more and manage to do a UI refresh which mainly makes things worse. (Slack some time ago, Discord recently)

Also, it's not how portable things work. The shell may need some crossplatform work, but the behaviours and core of the app is the same.

This is not a money issue.

It's not an issue of not having the money to pay for it. But it is an issue about how the company makes money.

I say this as someone who loves the Mac, and goes out of his way to avoid electron apps, but in most cases, it doesn't make sense for a company to produce native Mac apps. Especially if that company is VC funded.

I worked in shops in the late 90s into the 2000s that produced cross-platform Windows/Mac programs. It was a lot of fun in many ways. But even the best-run teams with the best cross-platform stacks suffered from slower development times than they would have if they were targeting a single platform.

Even when like 90% of the code is cross-platform.

There are lots of reasons why. Some of it is due to platform differences. Sometimes the same feature couldn't work the same way across platforms. That meant either correctly doing extra design and planning ahead of time, or figuring out that you messed up and calling emergency meetings to figure it out. It meant extra work producing documentation that called out the differences. It meant training support staff on the differences.

Another issue was keeping all the teams on the same schedule. If you've got "one good person" working on the Mac side of things, and they get sick for a week, then either you ship the Mac update late or you delay every other platform.

Finally, there's always been a lot of churn on the Apple side. APIs getting removed. The platform moving to a completely different programming language. Toolbox. Carbon. AppKit. SwiftUI. Pascal. C. C++. Objective-C. Swift.

So a lot of teams went the route of trying to create their own cross-platform framework in C++, and focused their platform developers on just implementing the framework, so all the app work could be done by the cross-platform devs. The Mac people could thus isolate the app from the technology churn on the platform.

This never worked out. It almost always ended up being faster to write separate apps from the ground up for each platform, because the cross-platform framework would balloon into a monstrosity. You'd spend more time on the framework than any app, and somehow, you'd still lack functionality that the cross-platform devs discover they need for the latest top-priority feature coming down from management.

But typically, on the best teams, it wasn't just one person per platform. Because of the need for so much coordination between platforms, lots of time was spent in meetings, so you'd need at least a few people working on each platform. These are things you don't have to worry about when you're an independent developer working on an app that hits the company's API.

You might be temped to point out that this could all be avoided if you just had a server team write the server software, and one-person platform-specific teams that just wrote native apps that communicated with those servers. Sure, you still have to produce different documentation and support resources, but most companies skimp on those anyway.

You'd also have a bunch of apps with different features, shipping at different times, but they're all great apps, so that doesn't matter, right?

The result is that you'd come up with decently great apps for each platform. The project managers might even be able to recognize that they're cool, great apps.

But you'd still be like a cat bringing them a dead rodent. What are they supposed to do with this?

Admittedly, some of this has to do with how middle-level project managers justify their jobs. They spearhead features and make sure they get delivered into the product, theoretically increasing its value, and therefore the value they delivered to the company.

But it's not all that kind of bullshit. Sometimes it's essential to the company's bottom line, or to an attempt to improve that company's bottom line.

To use Slack as an example, at the start of the COVID lockdowns, Zoom usage shot up tremendously. Slack felt that this was a potential threat to their place in the market, and they introduced huddles. It took like a year, and Slack huddles are still worse than Zoom, but it was still probably good enough to retain some subscribers.

If it took a year with Electron alone, just imagine how much extra time it would have taken to plan and coordinate the feature across multiple platforms. Since it's important to the company, you can't just let the platform teams roll it out on their own schedule, or decide it doesn't fit well with the feature set they've cultivated for their platform. You need it out, you need it fast, and you need it to work the same.

Electron was the first cross-platform solution that worked well enough to make that a reality. It sucks in many ways. It doesn't follow platform conventions. But it's good enough that people can use it. And, bonus, the apps are all written in a language and an API that millions of Web devs are familiar with. No need to worry about the schedule slipping because one employee was sick.

In a fast-pased business, you need fast, universal turnaround on important functionality. It's more impactful to your bottom line than customer experience, even if that functionality is just some dumb BS like Discord super reacts or something.

  That argument would hold more power if there wasn't an existing native client for Slack and Discord, made by one person, with all the features I needed, working with absolutely no lag and minimal resource use, working on MacOS, Linux and Windows.

Did this 3rd party app have 100% feature parity with the original Discord/Slack app the moment new features came out? If not, what was the time delta between the two?

Why didn't the author continue development? It seems like it was on sale for $20? Surely because people value native app so much that he would have made more than enough money to continue development?

Can't speak for the author. I haven't seen the reasoning. The awareness of the app wasn't that great though. I only found out it existed right as Slack changed the organisation token/auth which never got fully implemented in Ripcord. There was only one post that got lots of attention on HN and that was before the pandemic. (With a pretty good reception, mostly around being light/not-electron https://news.ycombinator.com/item?id=19617699)

Can't speak to the feature compatibility completely, but testing it over a week or so I've not found anything missing at the time. I think the video calls got added after the development stopped and that never arrived.

Then Discord started banning third party / differently behaving clients, so that part got dangerous.

It did get good feedback on HN. Most people here love native apps. But the real question is, did people here actually support the developer and buy the app?

My guess is no. There weren't enough people who wanted to pay $20 for it. That should tell you how much people actually value native for this category of apps.

Do you realize that yourself, in your own reply, pointed out the fact that it is indeed and non-viable option.

As in it doesn't exist because there is no money in it because it doesn't change the company bottom line in any meaningful way that would warrant additional hiring. And it is not even viable for a single person with reduced running cost to make it a viable revenue stream because they would be too few people purchasing it; since as long as the (maybe worse but still largely viable) official electron option would exist there would be no point for a user to spend money.

The development has stopped, because it doesn't make enough money for even a single guy to justify spending time on it. At some point even if it's a passion hobby project, making software is actual work if you are bound to another entity roadmap...