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 goe

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.