The best part of this article is this comment from Plume:
> This has always been wrong, because it completely discounts the advantages of the web. Cross-platform compatibility makes an app greater. No installation makes an app better. Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater. Automatic updating makes an app greater. Being able to open the app I normally use on my desktop on my phone in a pinch makes an app greater. Not locking me into using a Mac makes an app greater.
I'm all-in on the Apple ecosystem, but collaboration and universal access on all platforms and automatic updates are considered table stakes for growth-focused products (edit: most products that normal people care about) these days. The cost-benefit analysis of using Mac apps when I have to collaborate with people so often just doesn't pencil out in favor of native apps for most of the things I do. The few places where it does are things like Notes, which is a first party app that all Apple users have, but even then it's a pain for people on other platforms to collaborate.
Forgot about all the Unix stuff. That part is easy to fix if they care about it. If Apple still wants the Mac to succeed as a native platform, they will have to solve enough of these problems for their developers that the Mac is a competitive native platform to the web. I don't really see a way forward for that strategy except building some sort of cross-platform UI toolkit, whether that means web apps run natively on the Mac or Mac apps run natively on the web and other platforms or what. Microsoft has been working fairly aggressively in integrating Windows with Android apps and building a new cross-platform app toolkit. Without progress on this front, I predict continuing decline of the Mac as a developer platform.
> Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater.
Web apps usually only lets you share within the app. You can't use the data in ways not imagined by the developers, and you force the app onto those you want to collaborate with.
> Automatic updating makes an app greater.
Not really, no. It usually makes me worried the developers will pull the rug out under me.
That's an argument against having to sign up to use something, not against that you don't have to install something...
> Web apps usually only lets you share within the app. You can't use the data in ways not imagined by the developers, and you force the app onto those you want to collaborate with.
Sometimes, that's true yeah. But sometimes, they offer APIs. Semantic Web tried to connect websites with each other even more. If not, they tend to be trivial to scrape. I think what the author is aiming for though, is that because it's not an native app, anyone with access to a browser, can usually access the application too.
> Not really, no. It usually makes me worried the developers will pull the rug out under me.
Indeed this is one of the biggest drawbacks and benefit of the web. It always moves forward, but it always moves forward, even when I don't want it to. There is nothing worse than a redesigned web application that is worse than it's predecessor, which tends to happen a lot.
We need something in-between. Something that maybe defaults to always being on the latest version, but when the user wants, allows them to use an older version. Just like native applications (mostly) do.
> We need something in-between. Something that maybe defaults to always being on the latest version, but when the user wants, allows them to use an older version. Just like native applications (mostly) do.
But there's no fundamental reason web apps can't do this. Basecamp still offers Basecamp 2 to existing customers. It's just that most companies don't want to go to the trouble of stabilizing their internal API (or keeping the old version around for ever), and so far the market hasn't penalized them for it. As native apps develop more connected capabilities, older versions of them will start to succumb to bitrot as well.
Not to get "stereotypically HN" on you here, but this is one of those things that the majority of package managers on Linux have figured out. Having multiple versions of the same package is a pretty huge requirement for anything that wants to masquerade as a server OS, which is why most package managers will let you downgrade and pin packages to versions that you want for whatever reason. Of course, this comes with it's own caviats; pinning system packages can really mess up your OS, and of course there are some Electron apps that enforce minimum client versions.
For those most part though, it's a good solution. As long as people know not to downgrade/pin packages they aren't sure of, it's a good-enough fix for the majority of use-cases. You could even idiot-proof it by hiding certain software, that's neither here nor there.
It's not at all obvious to me how Linux package managers have figured out the problem of versioning web apps. They've figured out the problem of versioning Linux packages, and I applaud them for that. They certainly work better than any Mac package manager.
Not sure where you have been for the last 10 years but yes, even SPAs are trivial to scrape today. But even better, because many people build SPAs, they tend to be powered by APIs, so you can just use the API directly instead. But even if you can't, trivial to scrape even when flooded with JS magic.
Ah, ok. Yes, if you can remote control a browser you can of course "scrape" anything the browser can load. (Although even here the puppeteer README says it can load server side rendered data. Not all single page web apps do that.) To me that isn't quite the same as having a separate program, independent of the browser, that is able to just load the data from the URL and then operate on it, which is what I'm used to seeing referred to as "scraping".
I think what you are suggesting is often done using browser extensions. It's obviously not independent of the browser, but it serves this use case where you want to extend existing apps adding interactive features.
My understanding of the word "scraping" is primarily something related to en mass automated data extraction from user interfaces.
> Something that maybe defaults to always being on the latest version, but when the user wants, allows them to use an older version. Just like native applications (mostly) do.
This makes good sense for client-side native applications, especially Free and Open Source applications where supports costs don't work the same way, but it's in tension with what many developers (and their overlords) want from the web.
People that run web-based solutions want to be able to change or retire old server-side functionality as things evolve. Perhaps a feature never got any traction, or perhaps there was ugly server-side code to cope with a deficiency in the client-side code that has since been reworked. If you commit to eternal support for all older versions of the client-side application code, your hands are tied regarding the server-side code. You also have the challenge of supporting O(n) versions of the client-side code, rather than only the most recent one.
> you force the app onto those you want to collaborate with.
Ah ah ! Exactly why I don’t like this trend to have Discord on every project. I don’t really care about the chat room being hosted on Discord servers. Eventually, it’s the channel owner’s choice.
But forcing me to execute the client ? Sorry but I can’t. It’s not that I don’t like it, but that I can’t trust it. Well, and that it doesn’t integrate well with any of my OS (well, except on Windows where not being integrated is now the norm for pretty much everything).
Yeah... I honestly find it strange that anyone would bother installing the "app" version at all, much less feel blocked from using the service by somehow feeling forced to: Discord is just a web page!
Sketch vs Figma is the famous example of this. By the time Sketch evolved beyond their native Mac app focus, Figma had already captured a ton of the market that wanted cross-platform and web support. Turns out that mattered a lot more than having a great native Mac app.
Personally I think figma's ux is excellent. And the killer UX feature of being able to create a semi interactive demo and share it via a link is also excellent.
Can you give some examples of where figma's UX is worse than sketch's?
Figma is _fine_. My team recently switched from Sketch to Figma (I was involved in the decision), but I miss the niceness of Sketch.
Sketch is a real Mac app. Figma is a web app. There are important powers I have as a Mac user that aren’t there for Figma, no matter how much they work on the UI.
For example, besides just being hideously ugly and completely out of place on a Mac, Figma’s in-window menu system doesn’t let me assign my own shortcuts through System Preferences. I had lots of those for Sketch. Also, it uses its own menu search instead of the native Help menu. And right-click menu doesn’t use Mac services, so I can’t use other parts of my system to alter things quickly.
The toolbar isn’t customizable. This is one of the best features of real Mac apps, and honestly should be a power tool basic requirement.
Copying content in Figma copies weird Figma-only content, rather than providing multiple versions of that content on the clipboard for the paste consumer to use. Try copying from Figma into Slack (another UI story of “hey it’s good enough”). Or into any Mac app.
Windows restore in weird places and spaces when restarting. Windows behave weirdly in a dozen subtle but annoying ways.
Text editing is subtly different from that of true native Mac apps.
Color display is sometimes slightly different from native Mac apps, presumably due to color profiles, though I’m not sure. Sketch just always gave me consistently right colors, including mirroring on my phone, and Figma fails, especially with oranges. This warrants more investigation and work on my part, but is annoying.
Dragging things into or out of Figma sucks. Probably related to the copy/paste story.
There are genuinely dozens of other examples I could give. This is the tool I live in day in and day out. I’m a craftsman, I care about my tools, and honestly I don’t love this one.
BUT! Figma offers compelling features that made it an obvious choice over Sketch, and not just the “collaboration” stuff. Auto layout, decent prototypes, better color and component overrides, and a bunch of others. And to a real but lesser extent, web-first documents for the broader team.
EDITED TO ADD: Also, Figma has branching and merging! Super cool, and well implemented.
I _wish_ Sketch had been the winner on features, because I have joy using it. But it wasn’t the winner, for us. But that’s a failure of Sketch, not a condemnation of native Mac apps broadly. But please know Figma drives me crazy, because it’s not a native Mac app, and that has real UX downsides.
Honestly, we had some frustrations at first switching from Sketch to Figma but those frustrations were short-lived as all the benefits far outweighed any potential limitations. We’ve been on Figma for years now and are extremely happy we switched. It’s better in too many ways to count imo.
Figma killer feature is developer handoff. When designers use Adobe XD or Sketch it's a pain, but with Figma developers on Linux can access design documents as well.
I think the browser experience is bad but not horrible. The pros outweigh the cons when it comes to a tool like figma compared to sketch, a designer doesn't have to save and sync files, everything is async and all in one place, it makes collaboration very easy.
This comment is a shallow dismissal, which is looked down upon by the HN guidelines. Your first sentence doesn't need to exist, and as for the latter ones, please elaborate on your opinion as to what exactly is a "horrible UX".
Yeah this is something that was brought home to me when my nine year old son wanted to design his own deck of playing cards
I thought about giving up my Mac so he could use Sketch. But then my partner suggested he try Figma on his iPad
I connected my old Magic Mouse and keyboard up to his iPad, Air-dropped the initial Sketch file we had made to him, and imported it into Figma. Once I taught him the basics of components, transforms and the shapes and vector tool he was up and running (I was pretty strict about naming his layers properly!). He quickly got through the whole deck in two suits
It still bothered me though: why was Figma using windows hotkeys, except for copy and paste? Why did the layers panels sometimes not scroll all the way to the bottom, text editing was clunky, things didn't feel quite as smooth. But it did the job
Figma is a C++ application compiled to webasm that paints to a blank canvas for the majority of it's usage. It's about as 'web' as the unity game engine compiling to web. In development they compile to a macOS app and use instruments to profile it.
The platform is still web, even if it's not using HTML and CSS. The success of figma has lead to a lot of start ups targeting the web as there main platform, but using WASM (C++ or Rust) and WebGL (soon WebGPU). This makes sense in creative tools, I think. We're also starting to see tools that run on the server and stream video to the browser.
Christ, don't get me started on that last point. One of the most egregious examples I've ever heard of is Mighty, an app that streams Chrome from a server to your laptop, because apparently fixing Chrome's performance is too much of a hassle that now we need to send a video of our browser back to us.
And the worst part is, they might win. Lots of apps are web based with WASM and WebGL like you say, which are purely client side, and lots of people that need to do work might not have good enough computers to run such apps, if we assume (and I believe this to be true) that applications with more and more complexity will be pushed onto the web browser as the universal app interface. If a server can render those apps better and send them back, the client doesn't have to any work.
We continuously invent and reinvent the terminal/mainframe architecture, it appears like.
Might? They will win, is it not obvious at this point that every single app in the near future will be sandboxed in some way? The unix grey beards had a couple decades to prove they could write secure software and they failed.
Or to write a UIKit that works across Windows, Linux and macOS with no hassle, making cross-platform development easier. But no, we have 3 SDKs on a single platform already and it apparently is confusing.
Oh wait, they did create a true cross-platform platform: the browser.
it's not very "web" if you're concerned about the philisophical purity of the web as a mechanism for distributing html documents.
but if you just want an app that works reliably without having to worry about what type of computer you work on, it's very "web". in my books, the ability to compile a unity game to run on the web is exactly why web apps are so great right now.
When people complain about electron and web apps being wastes, what they are really complaining about is javascript, html and webdev practices. When your using C++ & OpenGL your skipping most of that. OSes can also add a chromium detection layer and make it first class like the rest of the OS system libraries too, because at this point it might as well be.
I don't know about that, most designers i know stick with Sketch. Figma captured everyone else except the designers - i guess we'll find out how useful that is.
The funniest thing about this is that Sketch used to claim that it was impossible for them to port it to other platforms (i.e. Windows or Linux, let alone web) because only Mac OS had the kind of APIs the app needed to even work.
In addition to this, I think one thing many people discount is that when you have a good cross-platform dev experience, your devs can actually build more features that you care about much faster than if they're porting and debugging for every app platform. Obviously some amount of cross-platform validation and debugging is always necessary, but the simple fact is that OSes are just not differentiated enough these days to make me think "Oh yay, I'm so glad this developer spent months on the perfect 'native experience'" - when they actually could have been building shit I really need.
> Your devs can actually build more features that you care about much faster than if they're porting and debugging for every app platform.
But do I care about those features? Do they actually make the software better?
I believe a major reason software gets worse over time is because companies add features which detract from the app's core purpose and make it more difficult to use. "Oh, you like Dropbox because it's a reliable way to sync files between computers? Great, let's add in a password manager and a word processor!"
Prime example of this are the Adobe CS apps. As far as my needs are concerned, CS1 or CS2 is more than enough. Very few features added since are of benefit to me, and yet I have to live with these apps becoming ever-slower, ever-larger, ever-muddier balls of mud as a result of those features being added.
At this point for some categories of apps I would gladly pay a subscription for a product that’s feature locked, with 100% of development efforts going into fixing bugs, improving performance, and keeping pace with OS updates.
> when they actually could have been building shit I really need.
The shit I really need is almost always what I would have gotten if the developer had focused on a "perfect native experience" in the first place. Multi-window support, keyboard shortcuts, scripting support, better performance, etc. I find myself wishing for those improvements 10x more than wishing for some "feature."
Those are features? You are describing features. You just don’t like that those kinds of features don’t bring in more revenue because they’re niche and often not dealbreakers when among people who care about them.
I agree they are, but this is framed in the context of the parent post which implied that experience improvements aren't really features that count.
And of course you're right, the reason almost no one builds polished experiences anymore is that, in most cases, it's not economical. Some developers (e.g. Things, Fantastical, Telegram, etc) make it work, but unfortunately it's very rare. I wish incentives were aligned differently, but I know they're not and I don't have a scalable solution; just have to hope enough developers decide to position themselves as the app with a good experience and make it work.
Apple is in the business of selling hardware, and developing a cross-platform toolkit would have the potential to cannibalize that. I think Swift's weak footing in other OSs is also owed to that fact.
Apple's best bet is to create an ecosystem of hardware and software that is self-sustaining and moated. I'd argue that they have been successful in that, but all those web platforms have significantly weakened the moat. You don't need apps like Sketch anymore (infact I consider Figma way superior), and you don't need most of their bundled native apps—there are great replacements that are either 3rd party native, or web based, or hybrid apps.
So how will they strengthen the moat? Probably not by sharing code with other platforms. They seem to be ready to accept that distributed systems won't go away and are obviously actively buying into that space (https://github.com/apple/swift-distributed-actors/). But, UI-wise, I'm only seeing renewed determination to push native apps: https://www.imore.com/apple-rebuilding-apple-music-native-ap.... And I think it makes sense for their bread-and-butter hardware business.
What is special about notes vs say Google Keep? I used to use Notes on my iPhone but switched to keep since it's available everywhere (both my 3 Macs and my Gaming PC).
PS: I know there's an icloud web version of notes but Apple's crappy requiring an Apple device only code every few times I use it and the fact that it's written in some kind of non-webby framework so that each non-ASCII character takes 100-2000ms to appear just really turned me off.
Notes has loads more features than Keep. Things like document scanning, instantaneous capture with pencil, better sharing etc. The simple UI makes it seem like they are similar.
(I also use Keep for the same reason as you but it isn't even close in terms of functionality.)
> Cross-platform compatibility makes an app greater
This is largely a developer's concern, not a user's concern unless the user uses multiple platforms and wants exactly the same app everywhere regardless of other issues - in practice this is a niche situation and the most people use either a single platform or two platforms that are still considerably different (ie. mobile phone and desktop/laptop) where having the same UX is actually a negative.
On the other hand, cross-platform compatibility actually makes apps lesser because they are designed with a lowest-common denominator approach where each apps uses its own controls, its own framework and libraries, etc for things that the native platform already provides - while not taking advantage (or using at a very surface level) functionality that is exclusive to the user's platform (e.g. Services on macOS - cross-platform applications either do not support it at all or have some surface support for things like text).
> No installation makes an app better.
No installation in the web app sense means that the user is not in control over the applications they are using - one can't just decide to stay on an older version because the developer broke the UI in an attempt to improve the UX while having no idea how people use their application (or trying to target some imaginary "common user" that supposedly had no interest in their app but now that they "improved" the UX everyone would fall in love with it) - they have to keep using the latest and "greatest" version (a very common story). Similarly if the developer shuts down the server or closes shop or drops dead the application is forever lost.
Also installation in rarely an issue in most platforms - and macOS has the simplest among all.
> Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater
While this can be useful functionality, in practice many web applications do not really "collaborate" with other web applications but instead just provide multiple sessions over the same application and all data is held hostage to them. Even with open source web applications that you can host yourself, it is very rare for multiple web applications to be able to share data with each other.
> Automatic updating makes an app greater.
See my comment on not installing.
> Being able to open the app I normally use on my desktop on my phone in a pinch makes an app greater.
This means that either the phone UX or the desktop UX are going to suffer to accommodate the idiosyncrasies of the other one. Either case does not make an app "greater".
> Not locking me into using a Mac makes an app greater.
And again this is only true if you are not a macOS user.
> two platforms that are still considerably different (ie. mobile phone and desktop/laptop) where having the same UX is actually a negative.
I disagree. I think most users want app foo to behave the same on their phone and their PC, even if that means not fitting in with the native platform conventions on one or both.
> Similarly if the developer shuts down the server or closes shop or drops dead the application is forever lost.
> Also installation in rarely an issue in most platforms - and macOS has the simplest among all.
Isn't it macOS that now prevents you from installing (native) applications from developers who have shut down, by requiring an up-to-date digital signature?
> in practice many web applications do not really "collaborate" with other web applications but instead just provide multiple sessions over the same application and all data is held hostage to them.
And in practice that's the most useful thing for person-to-person collaboration.
> I disagree. I think most users want app foo to behave the same on their phone and their PC, even if that means not fitting in with the native platform conventions on one or both.
I don't see how you'd disagree with that or why you think most user would want that.
> Isn't it macOS that now prevents you from installing (native) applications from developers who have shut down, by requiring an up-to-date digital signature?
Yes, macOS nowadays is awful on that front - even the linked article is exactly about that.
> And in practice that's the most useful thing for person-to-person collaboration.
Right but that is a different type of collaboration and doesn't need a web app for it. I do not remember the name, but i remember a P2P text editor from a decade before Google introduced Google Docs - and i'm sure Emacs has a mode for that too (actually i just checked and there are more than one modes for that).
> I don't see how you'd disagree with that or why you think most user would want that.
IME most regular users are application-oriented rather than operating-system-oriented; they're not "using iOS", they're "using WhatsApp" (or whatever). Frankly I think they're right; the operating system is meant to be the platform that supports the applications, not something that puts the attention on itself.
> Right but that is a different type of collaboration and doesn't need a web app for it. I do not remember the name, but i remember a P2P text editor from a decade before Google introduced Google Docs - and i'm sure Emacs has a mode for that too (actually i just checked and there are more than one modes for that).
It's possible with enough effort, sure, but you'd have to manually reimplement a lot of what the web gives you by default. In practice with limited development time, this kind of collaboration is much more commonly available in web apps than in native apps.
I hate to cherry-pick, but the comment on cross-platformness being a developer issue isn't always the case. I use Linux for everything, and an app being cross-platform increases the likelihood that I can use it.
You can be right as much as you want, but the majority of users do not care.
Native apps are better in so many ways, and users continue to not care. And that’s what apple is just ignoring. That’s what users like you are missing.
That is because "the majority" of users are very often not in a position to be able to judge why they should care nor even know what they are missing. E.g. if all one uses on their brand new Mac is Electron or other lowest-common-denominator apps and web apps and they never take advantage of something like Services then they wont even know what that menu is about - and these applications wont even teach them about it.
At that point the Mac becomes just an expensive, sleek looking device running an OS with a fancy theme that you but might as well replace with a similar looking fancy device running Windows or GNOME - there is no real reason to use it beyond being fashionable or as a status symbol akin to some clothing and accessory brands.
Strangely enough there’s still enough native to the platform that even the best notebook that can run Electron is still actually a compelling advantage because I would still have Spotlight, I would still have Quick Look, I would still have a POSIX environment, I would still have Exposé, I would still have the ability to globally reassign menu hot keys, I would still have the best PDF handling on any desktop environment I’ve ever used, I would still have Safari, I would still have Time Machine, I would still have Look Up, and I would still have Live Text. Loathe that I am to admit it, even the Finder ain’t half bad compared to the nonsense out there I could be using instead and I’ve made my peace with its deficiencies.
I wouldn’t be happy without the excellent suite of native 3rd party software and I’m not happy about 1Password’s decision to go from native to Electron, but the core Macintosh operating system features are still a compelling package.
> Strangely enough there’s still enough native to the platform that even the best notebook that can run Electron is still actually a compelling advantage because I would still have Spotlight
You can't use Spotlight to find a channel in Slack
> I would still have Quick Look
You can't Quick Look a Google Docs document
> I would still have a POSIX environment
You can't `grep` any of your Google Keep notes
> I would still have Exposé
Not really useful if all your "apps" are really browser tabs
> I would still have Time Machine
Can you back up your Figma designs in Time Machine?
Are we just assuming that everything I didn’t list is also just magically gone? I wasn’t.
Or to clarify, my list was mostly (but not entirely) a unique combination of things that distinguish the Macintosh. I can run Emacs anywhere, and every platform more or less has a set of PIM applications like the ones that come preinstalled on Mac OS X, but there’s a core set of features that makes my experience doing stuff I could in theory be doing on other platforms better.
> Are we just assuming that everything I didn’t list is also just magically gone? I wasn’t.
I'm not GP, but, well, I guess I'd be curious to hear what else you think is relevant, because this is generally along the lines of my thinking on the matter too. The features which make macOS special become increasingly less relevant as apps move away from the traditional macOS paradigm.
It's a spectrum, to be sure—Exposé is still useful even if all of my windows are Electron apps (although, not if they're browser tabs). But if I'm actually just working in Chrome all day, I really can do that on any machine and have the same (IMO, lesser) experience.
> I'm not GP, but, well, I guess I'd be curious to hear what else you think is relevant
I mean, presently, pretty much anything on a fresh install of a Mac in /Applications or /Applications/Utilities. The Catalyst crap aside that honestly may as well be Electron apps, Apple still has very good application software, most of which I’ve never felt compelled to replace and wouldn’t just magically disappear just because 3rd parties choose Electron. OmniGroup, Panic, Flying Meat, SmileOnMyMac and Bare Bones are still making excellent software that I use every day, and I have no indications that any of them are thinking Electron might be in their future.
Personally I still avoid Electron as much as possible, but when 1Password 8 hits, well, I’m not replacing it with something else unless it actually is somehow terrible. Agile Bits has made excellent Mac software for 15 years in Cocoa, if they went this route, I’m willing to chance it.
My real concern is that there’s no fresh blood developing new and interesting native apps. In the last 5 years, there has been IINA which replaced QuickTime 7 for me, Retrobatch from Flying Meat and I’ve been keeping an eye on nvUltra (a kind of expansion or rethinking or something of Notational Velocity) for a couple of years but it still hasn’t been released. Flying Meat is also basically just one guy and his wife who has a day job, so what happens to Acorn and Retrobatch when he retires?
My other concern is that a lot of the people at Apple that knew how to write good Mac software seem to have already retired, so I’m not holding out for good new and interesting app software on that front.
If there’s a future that’s mostly Electron for me, it’s probably from what I have atrophying and decaying with only Electron-based replacements.
Woah woah woah. You’re saying that the majority of computer users treat their OS as a tool to run the software they care about and let the platform get out of the way and you’re looking down on them? That’s literally all an OS is for. Everything else is fangirling.
Macs are a computer with excellent build quality, great battery life, and let users do the things they want without fiddling plenty fast. Like put on your end user hat, what else could you even ask for?
There’s zero self-awareness why someone might choose to buy a computer that isn’t a spec sheet with the biggest numbers shoved into the cheapest injection mold plastic money can buy. Like we’re nerds — we’re the equivalent of people who drive stripped down street racing cars with all aftermarket parts and the metal struts exposed saying “haha look at those idiots buying Honda Civics, must be for the badge.”
> Woah woah woah. You’re saying that the majority of computer users treat their OS as a tool to run the software they care about and let the platform get out of the way and you’re looking down on them? That’s literally all an OS is for. Everything else is fangirling.
No.
I'm saying that the software doesn't take full advantage of the tool people have bought, -to use a similarly bad analogy- like forcing them to use their motorized screwdriver without using the motor by instead by twisting it around like a classic hand operated one because that is the approach that works on all screwdrivers.
I know where you're coming from but I take a less pessimistic view, people are still making really great, first class apps for the Mac and will continue to do so as long as Apple provides a development environment for the platform. Craft and Raycast are two big examples that come to mind but the indie Mac and iOS developer community is alive and strong and generally positive about the future.
This line of argument sounds like a petition-gatherer trying to get signatures for a niche local issue and getting frustrated that they can't get enough people to see things their way.
It is an example because i think a lot of people on Hacker News know about macOS and its advanced features that you wouldn't expect most people to know about.
Personally i do not even really use macOS myself anymore as a main OS since around 2011 and the last Mac i bought was in 2012 (a Mac Mini that i gave away to my mother a few years ago so the only Mac i have around is a 2009 iMac - and whatever is the last version of macOS that runs on it).
I could use OLE and COM automation on Windows as a different example, though i'm not sure if even Microsoft cares about those anymore despite allowing for things you can't get in lowest-common-denominator multiplatform applications.
Native apps feel like they're built from rock and web apps feel like they're built with paper.
I don't care if the web app is available on my phone & laptop if the experience sucks on both.
Why are web apps so much worse performance-wise than cross-platform UI toolkits? Is it a result of the web’s historical baggage, or are the tradeoffs inevitable?
It depends. I have no idea why Microsoft Teams has such terrible performance on my Mac, for example. Slack is perfectly performant.
If there's a general ("inevitable") reason it's that updating the DOM (i.e., adding, removing, and changing HTML elements) is very slow compared to the function calls that native apps use to draw on the screen. That's why frameworks like React are designed to update the DOM as minimally as possible. It's also why Figma is written in C++ that compiles to WebAssembly and draws its content with WebGL instead of using the DOM.
I wouldn't call Slack performant. It sometimes struggles with basic things such as scrolling channel list. And it always lags with repainting window when its resized (when you resize window, extra space is left blank until Slack catches up - this never happens on native apps).
My guess was the DOM, too. But why does the DOM only exist in the web UI tech stack? There aren’t analogous constructs in other UI stacks (e.g., Windows Presentation Foundation), are there?
I think the biggest difference is just that the layout algorithm for the DOM is a lot more complex than those for native apps. Changing one element might reflow the whole page. Native frameworks aren't like that, and the solution they're converging on is the one React pioneered for the web, which is making a control's data dependencies explicit so you know when it needs to be updated.
> But why does the DOM only exist in the web UI tech stack?
Maybe because "web UI stack" wasn't designed for "UI". It was designed for hypertext documents and DOM is a perfectly cromulent way to represent a HTML document.
They have enough money to solve any problem, including through acquisitions of potential rival technology. They also have enough influence to steer standards in a way that suits them. I haven't been interested enough to check, but I just assumed that their developer ecosystem was healthy enough; other than push-back against the fees in the appstore.
Although, I had also assumed that developers would be moving toward web-based apps anyway.
I think Figma is a good example of a product that spells trouble for Apple's Mac platform strategy. It is the exact kind of app you would have expected to be Mac-first or Mac-exclusive (like Sketch!) just ten years ago or so (highly visual, with a primary audience of designers, who historically have used Macs).
But with WebAssembly and other advancements in web technology, the performance of Figma can rival and even exceed that of native apps, and it beats the pants off Sketch for collaboration and cross-platform compatibility. Figma is just a better product, and that's in large part due to being web-native. You cannot make a Mac app to compete with it without putting enormous resources towards all of the things it gets for free by being on the web.
Figma is terrible for users. If they change their business model or get acqui-hired, I lose access to the app and all my documents.
With a real app on my computer, I can continue to use my documents indefinitely. Even if the app developer goes out of business and it can no longer run in the latest version of macOS, I can set up a VM or keep an old computer or boot disk around to run it.
That will never be the case for apps running on someone else’s server.
These base practicalities are why, no matter how good the user experience of Figma, I can never rely on it for anything important or long-term.
Local first behavior is a big reason I still use Sketch. Nobody can take my documents from me, no matter what.
Sketch is also generally more friendly to people trying to take their Sketch documents elsewhere — the Sketch file format is publicly documented, which has allowed several other apps (including Figma) to be able to read it. Figma has yet to do the same for its format, which reeks of lock-in and rubs me the wrong way.
You can save Figma files as regular files on your desktop. My app Flinto includes a Sketch import and Figma import feature. I get your point, but just pointing out its not as locked down as you might have assumed.
The difference is that all existing Sketch files are guaranteed to match the file format specification that has been published, whereas Figma could change their file format entirely without telling anyone and suddenly nothing but Figma can read files exported from it until third party devs reverse engineer the new format (which isn’t a given).
Figma would earn a lot of goodwill if they published their specification and assured users and devs in its ecosystem that the format won’t change out from under them. Even then though, they could very easily say one thing and then do another. It’s an unavoidable uncertainty that comes with web apps.
I have the same discomfort as you but I would suspect most users would be prepared to make this tradeoff. Most people need to get a job done and dusted using the best tools. The archival concern feels a little too nerdy/fogeyish to me. Not broad enough to be "terrible for users", rather "terrible for nerds who value archival for vague posterity reasons".
Who archives besides a few wonks reading HN? UX is one step above sketching on a napkin, it's not the final project.
>The archival concern feels a little too nerdy/fogeyish to me.
Is that really a nerd issue or is it a business continuity issue? Would a professional designer or consultant ever want to rely on something like this, let alone a large business with many employees?
I felt goofy about using Google Docs early on too, felt totally wrong but collaboration is so important. Is Google Docs "ready for professionals"? "Good enough" eventually wins in these situations.
I probably have older files on Google Docs than documents on my computer -- Local archival isn't inherently safer. "When Google goes out of business.." used to be a reasonable thing to say, a while ago.
Losing access to the account is bigger concern. You need backups, wherever you store your important files. I wish Google made it easier to make incremental backups of Google Drive.
You just like the current business model of Sketch better, it had nothing to do with it being native. They could have required online license checks from the beginning like so so much b2b software does.
Building high-quality software costs money. If you produce consumer software, growth is a must to finance that. Some smaller efforts can certainly live with organic growth, but it's rare.
> If you produce consumer software, growth is a must to finance that
That's not true. You need to be profitable in order to finance the expenses, yes, but you don't need growth beyond that, unless you're aiming for something more. Fast growth is not the only way to finance something, and if you're aiming to build something long-term, fast growth is actually working against you.
I agree with a lot of what you’ve said here but Microsoft might not be the best example. They’re good about some things but not others. They aren’t even close to feature parity in every single version of their apps, be it web, windows, macos, ios and android. The windows clients probably have the most features but even they don’t have all of the same features as their web applications. And I’m not even talking about things that don’t make sense on a given platform due to UX or other constraints. You can search your mailbox on macos but not your online archive. So you have to switch to the Outlook web app to do that.
And the web apps... there are a bunch of small issues and differences between using their webapps on macos and windows. Browser standards aren’t perfect but building cross platform web apps in 2021 is way easier than it once was. And that’s not even getting into just how awful they’ve been from the start. When they first announced O365 I was sure they’d use their expertise with their own products like excel to quickly catch up to Google and surpass them. They’ve never come close in features and, more importantly, quality.
My suspicion is that basing their webapps on SharePoint has put them in a spot where they’re iterating on features as much as they are fighting the platform’s limitations and constraints. At one point Teams couldn’t handle more than x number of users per team because they were storing the membership in a SharePoint list which has a obnoxiously small limit to the number of items it can store. This was a major pain in the ass at least as far back as SharePoint 2013 (maybe even 2010) when their on-prem implementation of one drive was based on SharePoint and people would hit the list limit as soon as they did a sync with their local machine.
Microsoft will cripple their own velocity and productivity with some products in order to prop up others. They’re ruthless from a business perspective and leverage their existing enterprise agreements and relationships which allows them to capture large numbers of users by using IT decision makers who care more about budget to force the rest of the enterprise to use it regardless of quality or appropriateness. So I doubt they’re feeling much financial pain from it but there’s a reason people have a lot of hate for some of their products and services. Developing your product around whether or not a sales team can convince a business unit to force it down users throats instead of building something people want to use has resulted in a Microsoft that has a weird lack of consistency across the board.
One thing I will give them is that they put a lot of effort into security, policy and enforcement across products. But ultimately that’s as much good architecture as it is a way to ensure they can leverage those IT teams. Does it really matter that slack won’t let an ignorant but well meaning security team frustrate your entire company by invalidating your session every 5 minutes? No. But since you can do that with O365 it shows up on a security theater checklist.
If you’re still somehow reading this sorry about the rant, went a bit off topic.
I'm not a particular fan of Microsoft products, like I said I'm all-in with Apple stuff. But they have always understood developers better than Apple has, and I think their recent strategic efforts with .NET and Android demonstrate a clearer view of where the puck is going with application development than anything Apple is doing currently.
> This has always been wrong, because it completely discounts the advantages of the web. Cross-platform compatibility makes an app greater. No installation makes an app better. Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater. Automatic updating makes an app greater. Being able to open the app I normally use on my desktop on my phone in a pinch makes an app greater. Not locking me into using a Mac makes an app greater.
I'm all-in on the Apple ecosystem, but collaboration and universal access on all platforms and automatic updates are considered table stakes for growth-focused products (edit: most products that normal people care about) these days. The cost-benefit analysis of using Mac apps when I have to collaborate with people so often just doesn't pencil out in favor of native apps for most of the things I do. The few places where it does are things like Notes, which is a first party app that all Apple users have, but even then it's a pain for people on other platforms to collaborate.
Forgot about all the Unix stuff. That part is easy to fix if they care about it. If Apple still wants the Mac to succeed as a native platform, they will have to solve enough of these problems for their developers that the Mac is a competitive native platform to the web. I don't really see a way forward for that strategy except building some sort of cross-platform UI toolkit, whether that means web apps run natively on the Mac or Mac apps run natively on the web and other platforms or what. Microsoft has been working fairly aggressively in integrating Windows with Android apps and building a new cross-platform app toolkit. Without progress on this front, I predict continuing decline of the Mac as a developer platform.