Hacker News new | past | comments | ask | show | jobs | submit login

The more fundamental question here is: why, given what we know of the market share of devices running macOS, would anyone choose to develop solely for macOS (and thus target Apple-provided APIs)?

Now, let's be clear. I am not insisting that there are no reasons why anyone would do this. If you believe (rightly or wrongly) that your audience/user niche is overwhelmingly macOS-based, that's one pretty good reason right there.

But ... yep, truth be told, I can't imagine any other good reasons. If you're developing native applications in 2022, targetting a single platform makes almost no sense unless you pre-define your audience as limited to that platform. You may be able to create a viable revenue model doing that, but for every user on your chosen platform, there's somewhere between 2 and 20 who are irritated by your decision.




If you were to ask Mac-focussed companies like Panic or Rogue Amoeba I am certain they would tell you it's because they as individuals enjoy the Mac platform, and the user base is large enough to make it work despite being a niche of a niche.

I think as a society we often focus too much on growth and maximising. It's okay to keep steady and focus on the things you like.

Personally, I'm very glad that there are still companies out there targeting one platform, even for the platforms I don't use. Unless there are enough resources to focus on native versions for each platform, multi-platform software is often full of compromises IMO.


Panic, Rogue (Bare Bones, Omni Group too) have built-in audience from ~3 decades of classic -> modern Mac development. I feel like it would be a lot different for a newcomer.


> It's okay to keep steady and focus on the things you like.

Absolutely, would never have it any other way.

Personally, I just want to believe in what I do, and if I believe in it, I don't want it restricted by platform. YMMV and that's cool.


Sure, I can totally appreciate that.

FWIW I think there’ll always be a place for cross-platform frameworks, and that there’s still a lot of room for improvement in the space.

Things like Electron have undoubtedly resulted in tons of valuable software that simply would not have existed otherwise—now we just need to address the caveats.


I love some of the Mac only apps, but it's undeniable that this 2010-like dream of building a native Apple software and the monetization model (selling it on the App Store) is almost entirely gone. I honestly think this was a first-movers pipe dream. Once the competition caught up and the industry matured, interoperability was going to dominate all other arguments.

Today we live in an entirely different world, and the big corps are still funneling money into keeping these ecosystems alive (heck, there's no other way). Yet, no developer want to learn 6 stacks, not even the big corps do this for their own apps for gods sake.

I will bet my left thumb that eventually GUIs will be predominantly made with web technologies, will run on all platforms, and will have native proprietary extensions. The web today even has a path to become language agnostic with wasm.


The reason software shops used to justify developing either Mac-exclusive or at least Mac native apps was because Apple customers tend to spend more money on software in general. And that was when Apple had an even smaller market share. I suspect it’s still true to some extent, but probably much less so than in the past. And almost certainly because:

- The App Store(s) drive pricing down

- Free alternatives are more prevalent, particularly because of Electron


One answer is that you can write a better app, and that can be a competitive advantage. For example, I bought Fork and not GitKraken, because Fork's native experience is so much better than Electron-based alternatives.

This doesn't preclude you from releasing the app for other platforms: Fork also has a Windows app, with separate UIs but presumably shared business logic. This is how cross-platform development used to be done. It's certainly more total work, but you don't hit a quality ceiling like you do with write-once-run-anywhere frameworks.


Consistency across apps on the same platform is directly opposed to consistency across platforms within the same app.

As a multi platform user, I prefer that Figma, Discord, Spotify and vscode always look and feel the same independent of which machine I'm using.


> This is how cross-platform development used to be done.

Not for at least 20 years. We've had Qt, GTK, WxWidgets for longer than that. Those GUI toolkits are how cross-platform developer "used to be done", and to a large extent still is.

Electron is not the only way to do cross-platform, and there are lots of reasons why it absolutely is not the best way. What it does have in its favor is leveraging the knowledge of developers who've only ever worked on webstacks. Not much else.


Another thing Electron has going for it is better built-in accessibility support, at least on Windows. wx is fine as long as you stick to the wrappers over native widgets; and there are caveats even then (e.g. having to use different wx classes to get a native list view on different platforms). Last time I checked, GTK is still inaccessible with screen readers on Windows and Mac. Qt seems OK; I haven't done a detailed evaluation lately, but I would still bet on Electron coming out ahead, particularly on Windows.


Yes, a11y matters and needs to be attended to for apps where it makes sense. Doesn't make a lot of sense for some things though (e.g. where the main app display is essentially a drawing canvas). Not sure how much better Electron could be in the scenario.


Native apps don't have to be exclusive.


You cannot run an application that uses Apple's *Kit APIs on anything other than macOS.


Obviously for native apps you have to develop different frontends for different OSes but you don't have to develop the whole app exclusively for one OS.


Case in point (the cross-platform app I've spent 20+ years developing): 500k lines of code. 190k lines of GUI code. So nearly 40% of the codebase is dependent on the GUI toolkit we use. Not only that, but the GUI part of the application is by far the most complex to develop, even though the rest of it is realtime, multithreaded deeply complex programming. The idea that we'd maintain more than one GUI "frontend" is completely absurd.


Developing native application is not targeting single platform. It means choosing a different set of tools and technologies used for development. Instead of relying on some cross-platform framework / module / engine you just rely on different stuff which is closer to the platforms you plan supporting.


If the tools & technologies are only available on one platform, as is the case with the overwhelming majority of Apple APIs (same for Windows), then I'm sorry, but selecting them is targeting a single platform.


They can exist because their "small" markets or audience will pay for their software. That simple.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: