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

It's a hard UI problem. The Mac sandbox overcorrects to requiring capability resources for all file accesses, while on the other extreme we have e.g. Windows UAC which trains users to roll their eyes and click through.

But Apple doesn't enjoy the luxury of solving this problem in a nuanced way, because Mac apps are not acting from a position of strength. I suspect you aren't downloading lots of Mac apps today, and the reason is not insufficient sandboxing, but instead the limited selection, annoying install experience, etc. These are the problems that Apple must fix first.

> Perhaps the emergence of Electron is a wake up call for Apple and Microsoft, there is clearly a demand for creating applications with web technologies

34 years ago, the Mac was new and generated developer excitement. But Apple was afraid the Mac would be dragged down via shitty DOS ports of apps like e.g. WordPerfect. Apple's response was to set a high bar via first-party "killer apps" like MacWrite, which would embarrass any such DOS ports. It worked: the Mac set the desktop publishing standard for years, decades even, and arguably still dominates.

Yes, there's a demand for developing apps with web technologies, but embracing that is a losing strategy for Apple. Why should I buy a Mac to run web apps that run equally well on a Chinese Chromebook? That's ceding any software advantage.

Instead Apple should leverage the Mac's unique software strengths. Aggressively evolve the Mac's unique "UI vocabulary" and application frameworks. Empower, not punish, the dedicated and passionate developer community. Ship love to the userbase (perhaps the only one in existence) that's willing to open their wallets for high-quality desktop software. And yes, tolerate web-tech apps too - but embarrass them!




Can you elaborate on the "annoying install experience?" I find that is completely opposite, most apps are drag and drop install (and finish their set ups on first launch, if any). Others are a very simple to click through installer. I find the installation experience to be much more .. annoying in windows sometimes. In OS X most apps are installed by dragging and dropping (well, not even required) to /Applications (usually by a folder aliased right to the right of it) and getting a "Installation Progress" in the form of how long it takes to copy data to the disk out of a compressed dmg. In Windows, most installers I run into still do the near straight run to 99%, then sit there for however long the actual installation took, or circles back 15 times.


I believe they are saying installing from the Mac App Store is an annoying experience, which I agree. It’s an inexplicably slow and clunky piece of garbage. It’s almost impressive how bad it is for a “first party” application.


That's because the Mac App Store was spawned from iTunes, which has to be the shittiest piece of garbage to ever stain the hard disks of Macs.


Best case, installing a non-MAS app involves downloading and extracting a zip file, mounting and then copying from a disk image, and then clicking through the "application downloaded from the Internet!" dialog.

Yes it's still much better than the typical Windows installer experience, but zero-install web apps are now setting the bar.


We're not talking about simple, zero install web apps here. We're mostly talking about Electron apps, which are "web apps" but still downloaded in the traditional sense though.


From a developer stand, why advantages do I get from making a native Mac app compared to a web app or an Electron app?

Web apps in the browser are OS-Agonstic and Electron apps can be easily made cross-platform.


The answer is quality. As a Mac user I always prefer a native Mac app to some cross-platform app, even one with nominally more features.

More specifically:

1. Superior performance. Native apps are just faster. They launch faster. They use an order of magnitude less memory. Multithreading via GCD is much much nicer than Web Workers. Large files are better supported. You can have very large tables. etc.

2. They properly implement Mac UI idioms. By comparison even the nicest Electron-like app (VSCode) violates many longstanding expectations: it doesn't properly highlight the menu bar when typing a key equivalent, menu items don't disable properly, the text highlight color is wrong, text selection anchors incorrectly, no column selection, text drag and drop is badly broken, undo doesn't know what it's undoing, undo coalesces incorrectly, hell even arrow keys sometimes go the wrong way. It's an island app doing its own thing.

The theory of the Mac is to establish a set of UI conventions. When you launched a new app, you would already know how to use most of it, because it was a Mac app. It looks and behaves like other apps, so you feel at home already. And as a developer, you get the right behavior now and in the future, for free.

But if every developer builds a cross-platform app with a custom framework and appearance and behavior and UI, then the OS loses its role in defining the platform conventions. In that event, what's the point in having more than one OS?


I fully agree with you. I love 3rd party Mac apps that look and act like Mac apps (Like Sequel Pro) but you still didn't answer my question.

From a developer point of view, it's just better to make a Web App or a Electron App that will be used by everyone irregardless of their OS. Not only it's less of a hassle to develop but also guarantees that more people are gonna use it.


I doubt that Web Workers vs. GCD makes a difference in user-visible performance. Parallelism matters more for domains that are the responsibility of the platform: image decoding, media playback, vector graphics, etc. (Web browser engines are starting to run away from the Mac system libraries in some of these areas, by the way: Skia and even Cairo/Pixman significantly outperform Core Graphics in many cases at this point, for instance.)

I'd also argue that VS Code isn't much worse off than most native code editors. Most code editors outside of Xcode don't use NSTextView and so have to implement all of the behavior themselves anyhow. For example, as far as I'm aware Sublime Text pretty much implements just as much of the core editing logic as VS Code does.

I'm not denying your complaints, of course--they're valid--but I don't think the gap between native and Web/Electron is as big as you're implying.


3.native is easier to develop (swift vs javascript, cocoa vs dom) and has a more robust result.


Don't know where this is coming from because in my experience developing for the web is much easier. There is tons of up to date documentation out there.

Whereas developing Mac apps seems to rely on a set of arcane knowledge and having been in the scene for years. The documentation for AppKit is vastly outdated and there is almost no blogging/tutorials scene so as a newbie you are basically going to be going through a lot of trial and error.

And then most of the documentation you will find is in ObjC while everyone around you is telling you to develop in Swift, but then Swift changes every few months. You open up a project from a few months ago, it doesn't compile anymore, and you basically have to work at Apple or be a dev god to fix it.

So.... native is easier to develop for? No way.


The trade-off is that they’re much shittier to use. Faster to develop, worse experience.

That’s an okay decision to make if it fits your product and market needs, but it’s important not to forget the cost.

Native apps perform better, integrate better with other system services, are more power efficient, use less storage space… usually technically superior in every way, with the exception that that are less portable and in some cases more time consuming to build.


So, they are more work for developers, but are technically superior for users (native UI, performance, battery life, etc.)




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

Search: