> 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.
Yet Another Account makes an app worse.
> 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.
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.
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.
How? (I'm asking about the case where there is no API.)
My understanding of the word "scraping" is primarily something related to en mass automated data extraction from user interfaces.
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.
There are native apps on my phone where I can't even select the text because they didn't use the right control.
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).
It’s an horrible UX. No surprise it come out in these times where user interfaces are html documents masked as inconsistent UI.
Can you give some examples of where figma's UX is worse than sketch's?
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.
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
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.
Oh wait, they did create a true cross-platform platform: the browser.
Could be worse I guess, there are those that ship a whole OS with the application.
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.
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!"
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.
I've still got an install of Fireworks somewhere.
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."
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'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.
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.
(I also use Keep for the same reason as you but it isn't even close in terms of functionality.)
For me that was the worst part since...
> 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.
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.
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 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).
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.
Windows and Mac users are typically catered for.
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.
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.
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.
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?
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.
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 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.
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.”
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.
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.
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).
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.
Although, I had also assumed that developers would be moving toward web-based apps anyway.
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.
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.
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.
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.
Who archives besides a few wonks reading HN? UX is one step above sketching on a napkin, it's not the final project.
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 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.
Yuck, no thanks. Can we just have good products?
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.
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.
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.
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.
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.
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.
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.
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 App Store(s) drive pricing down
- Free alternatives are more prevalent, particularly because of Electron
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.
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.
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.
Also, I liked the idea on this site of responding to twitter comments by posting them whole on the site and writing the response below. It feels more like it is an older style mailing list that way.
It’s always small things like keyboard shortcuts, focus behaviour, placement of controls, but it’s all one more roadblock to using the computer. The more we have to consciously think about what we’re doing because we can’t rely on consistent muscle memory, the less effective of a tool the computer becomes.
It’s not even just the Electron/web based stuff either. Drag and drop in Office for Mac doesn’t work the same way as every other Mac app, and it throws me every single time.
One of the biggest examples of this is "dark mode", something which arguably isn't that old in a Mac context, but Windows let you choose the appearance of individual UI elements --- colours, fonts, sizes, etc. --- and everything native in the system would automatically match. That is, until Windows ~8 or so, when they gutted most of the customisation, only to later reintroduce as a half-baked "dark mode".
Let me check something... I open "Terminal.app" and what is this? I can't move around my cursor with my keybindings that I use in Sublime and VSCode (Cmd + Arrow to jump to start or end of line). Why do I quit a session with Ctrl + D? What is even this Ctrl key, I'm used to Cmd + anything on the Mac?
Isn't it odd that devs spend a lot of time in the Terminal, but apparently aren't as obsessed about the inconsistent keybindings vs the rest of macOS there?
You’re correct, it would very much annoy me if my terminal was inconsistent with the rest of the system, and I am disappointed that the system terminal is not setting a good example.
Moreover, the internet is full of people asking how to enable MacOS shortcuts in Terminal. And iTerm.app even comes with a "natural editing" preset precisely because of that.
They do. It's just that they are not technical enough to say "I don't want a web based app".
They say "this app is slow". "Why is my computer hot all the time?". "Why doesn't my screenreader work in the app?". "Why can't I use my keyboard the way I use it in other apps?" "Why can't it keep window size and location"
And a thousand other questions.
Electron also has an (comparatively) awesome Dev experience in regard to the tooling available and the nodejs ecosystem.
Why doesn’t VS Code have macOS’s native file name/location controls in the title bar? Why does it freak out if I move a file while it’s open?
This is just moving the goalposts.
A cross-platform toolkit that implemented compliant looks and behaviors across all of its supported platforms would be an amazing thing.
Correct me if I'm wrong, but don't people with serious accessibility needs typically prefer web because there are way more tools optimized for web than for native?
I'm going to push back against this just because it feels like sort of the "cool" thing to say around HN. I certainly understand some users on some hardware may have had a negative experience with Electron, but I haven't. I have never felt an Electron app (primarily Slack and Spotify) was sluggish or negatively affected my overall experience on my laptop in any way. Granted, I've always had relatively decent MacBook Pros, but this "common HN refrain" has simply never been an issue for me.
That's exactly why it's never been an issue, and will likely never be an issue for you.
Most people (with the exception of gamers, who are still not "most people") do not have relatively recent MacBook Pros - they have machines that are significantly weaker. All of my non-gamer, non-techie friends have 4-to-7-year-old computers that are significantly weaker than my already-lackluster ultrabook that struggles to run Discord and watch a 1080p YouTube video at the same time. That is the average person's experience on desktop/laptop computers (not mobile devices).
You may never had had to deal with this, but that's because you've only used machines that are far more powerful than the median.
Users don't like slow and bloated. Given equal choice users prefer small and fast. Of course, they are okay with Spotify client, because there's no native Spotify client with the same functionality. People want to have the service, but don't think that everyone is okay with how this service is packaged.
That is - just because Electron will get faster with some optimization doesn't mean that it's possible to become enough faster while still completely implementing the various web specifications.
Absolutely true. I don't like that the web is so complex there are only a few competing implementations. Still, it's the best we got in terms of platform support.
> doesn't mean that it's possible to become enough faster
Unless you bloat your app with tons of frameworks, I don't think the issue is speed, but size, which is true for web in general. Almost all of that size can be deduplicated (and some big parts even discarded).
Probably because Windows was always a UI/UX clusterfuck, so Windows users don’t notice the difference. Mac enthusiasts on the other hand…
> Apple splitting their resources to support AppKit, SwiftUI, and Catalyst probably doesn't help.
Yup. After years trying to coalesce development around AppKit (transitioning away from the original Toolbox API), Apple decided to ship the org chart and simultaneously maintain three different UI frameworks, none of them fully consistent with the others. Engineering labor was divided between them, and extra work was created due to interoperability requirements. All three were left worse off as a result.
I mean it's the most obvious surface-level minimalist/designer/programmer impulse to want there to be only 1 way rather than 2, because it just overall feels more neat/tidy that way. That's the kind of impulse I heed a lot of the time. But in the real world and especially trillion dollar market situations like this, what's actually best to do is not necessarily that simple.
Try that in the Apple ecosystem.
 source: https://github.com/WebKit/WebKit/commits/main
gecko has 782,002 commits
chromium has 1,080,253 commits
To help you understand the magnitude/impact of this difference, a single 100K commit difference account for more human resources than a whole native GUI framework (e.g cocoa, gtk 72,090 commits, QT ~80K) has received in its lifetime
now multiply that by 8 and you get an idea of how obscolete webkit is regarding human resources.
They might ? have hired more devs recently but if true, it's already a decade too late.
finally the gradient is not closing.. ten time less weekly commits:
> Why did this happen in the first place?
> My answer is something I call “consistency sin”. Understanding the cause lets us avoid similar situations in the future.
Oh seen this happen. Something like...
Random boss: "Our iOS and Android apps are not consistent!"
Mobile PM/Dev: "But Android users don't care what the iOS app is like. They want the best version of our app for Android"
Random boss" "But our iOS and Android apps are not consistent!"
Mobile PM/Dev: sigh
Indeed. Home.app for macOS is an atrocious half-assed iOS port, and on macOS it feels worse than an Electron app. Why should macOS developers care about polished macOS UX when Apple has gaven up?
Second problem is that Apple's post-Aqua flat design is bland. They've made it clean and simple to the point of removing all of its character. The design is now nothing but sterile sans-serif font and rounded corners with a box shadow. You used to be able to use just Cocoa, and have an app that has a unique Mac-specific look (even if not everyone loved brushed aluminium or toothpaste buttons, these were very distinctive elements). The widgets were polished and pixel-perfect to the point you could instantly tell which apps were native, and which were merely copying the look. But now this is gone. If you stick to only Apple's UI toolkit, your application will look like a low-effort webapp styled with 5 lines of CSS.
I think it's pretty clear at this point that Apple's been adding the tools to do more of the kinds of designs you see over in Electron rather than "native" looking pieces. Anybody building with solely native controls in 2022 will look out of place (unless they're trying to look system-integrated, in which case you'd go the opposite way and try to blend as much as possible - the middle ground is gone now though).
Hell, the only native things you need to use from Cocoa's standard toolbox these days:
- NSToolbar (if even)
- SFSymbols or other system images
- NSTableView styling
- Buttons, dropdowns, menus
The rest you can style however the hell you want - I would consider it the most flexible platform after HTML/CSS/JS.
It basically just worked on Linux. Windows had a few odd bugs for usability. MacOS I gave up on.. despite building and testing the app on MacOS.
- All of the good stuff is in the Documentation Archive.
- New documentation is barely more than the function/method signatures from the API.
- Apple has the resources to do better and did so when they were significantly smaller (both in terms of employees and market cap).
They don't care.
I think there's one ultra-nitpicky distinction I'd make here: people shipping things in a browser don't need to sign stuff.
People shipping Electron apps should probably sign their stuff. They're in the same boat as desktop app authors here. Desktop authors can also choose not to sign/notarize - many do.
The difference is that I've noticed far more Electron-based devs don't care about this and just opt not to. I don't mind signing/notarizing, but with how it's done outside of Xcode, I can't fault people for not wanting to put up with it.
Note that I'm just defining the distinction for Electron vs Desktop; I generally agree with the rest of the points made here.
Not all Apple programming has been done by the use of Apple tools. There was a significant stretch of time, when Metrowerks CodeWarrior/C++/PowerPlant was the tool of choice for serious Apple development.
We’ll see what the future brings. I’ve stuck with native Apple, through many, many dead pool sessions. Being a long-term native Apple developer means that I’ve been hearing insults, and looking up noses, for a very long time.
I am glad that I am not really competing with anyone. It’s very freeing, to be an oil painter. For me, the medium is important. I like to feel as if I can produce work that will make its users happy. It makes me happy.
It has screen painters, drag and drop components, database access, everything you could want and is fast, it has a community edition and free trials. Catch up with the 21st century :-D
Here's some resources to get you started
There's a free book here:
and another here (pdf) (probably the best to start)
There's intro videos here
They have a YouTube channel here, that has a lot of more in depth stuff
There's some books by Nick Hodges (former delphi product manager)
'Coding in Delphi' and 'More coding in delphi' for more advanced stuff
The negatives with delphi are its been poorly marketed for years, and it costs money to use, though the community edition is available now. Object pascal is a bit dated imho, but what makes Delphi powerful is the components, there's 2 the VCL which is the original in windows only, then fire monkey which is the new cross platform one.
Also, nobody really wants to code in Object Pascal anymore (despite its readability, etc.).
The Mac UX team is being led by amateurs. Big Sur’s redesign is a joke that Monterey hasn’t began to fix. Let’s not even discuss whatever almost happened to Safari.
The Unix layer is abandoned. Why is it harder and slower to run docker on macOS than anywhere else? In the 2000-2010s, Macs were developer’s first choice.
Cocoa was not only a joy to the end user but for t he developer to write apps on. I’d rather write a Web app than a Mac app these days (but not use it, yet)
The article is spot on.
Good hardware alone won’t be enough to sustain the Mac’s relevance long term. It needs consistent, predictable, discoverable UX. It needs to be the best developing environment.
> The Mac UX team is being led by amateurs
At some point it appears software design at Apple was taken over by someone who thinks that hiding controls behind hover states and overflow menus (such that you can’t actually see what an app can do without discovering it by accident) counts as making the software simpler, when in fact the opposite is true.
There is no need for user feature as marketing. Bug Fix, Security Update, Performance, Drivers, API update are good enough.
To the point I am thinking, OS UX are near the end of the S curve. It is pretty much done.
> At some point it appears software design at Apple was taken over by someone who thinks that hiding controls behind hover states and overflow menus (such that you can’t actually see what an app can do without discovering it by accident) counts as making the software simpler, when in fact the opposite is true.
Granted I’m still on Catalina, but I have never heard anything like this before. That seems like it would cause a huge uproar. But…
> Why is it harder and slower to run docker on macOS than anywhere else?
… I don’t think this has to do with the Unix layer, and I’d expect other Unixes to similarly struggle with Docker. Because Docker only runs natively on Linux. All other OSes need either a VM or (in Windows’ case) WSL.
To be honest I think this is one of the biggest problems with Docker and I’m not sure what Apple can do about it (switching to Linux underpinnings is entirely unrealistic).
Otherwise I largely agree, but I feel this deserves clarification.
It turns out Windows developers using Docker have the same complaints that Mac users of Docker do. In fact, I know people who run Docker Desktop inside a VirtualBox Linux VM on their Macs because it's so much faster than the VM Docker spins up.
The dev environments feature in preview for Docker Desktop is supposed to make this flow easier, but if you have to do anything that doesn’t fit into the “I’m writing a web service that is easy to proxy” mindset, you’re better off doing a full VM with Linux (via Multipass or VirtualBox or whatever) and keeping your code in there if you want maximum performance.
You're much better off using your own VM and the free software docker CLI tool. Set DOCKER_HOST to "ssh://root@$VM_IP".
Unsubstantiated claims like this often get a rise out of me, and I was tempted to reply with a sarcastic “go on…”, but I’ll try to have a more charitable discussion.
APFS performs very well. So does ext4 or zfs or whatever. So it seems your claim is not only that the file system bridge is the source of performance degradation (which it is, I agree), but that’s somehow by design for [reasons]? This is my sincere, charitable attempt to understand your scare-quote laden use of the word feature.
Is that what you mean? If so, can you explain why? If not, I’m happy to understand what you actually mean.
It goes from 10-20s to 6 minutes. It takes 2-3 minutes to install node_modules alone due to the massive number of files. Trying to mount them with buildkit, provide a prepackaged cache folder, etc, are all pointless since they suffer from the same I/O slowdown. Building a go executable also goes from < 10s to > 60s.
It's no thanks to Apple, but there actually is a very good ZFS driver for macOS. I've been using it for several years. https://openzfsonosx.org/
(You can't use ZFS as your root filesystem though, which may be what you meant.)
Cocoa is still there and has hardly changed. Maybe there are some new macOS capabilities that it doesn't provide the right access to, but I'm not sure what.
macOS will only ever be the best development platform for macOS. For cross-platform development, it's always going to be worse than Linux, just because the Linux world takes x-platform seriously.
Microsoft solved the problem by running an optimized Linux kernel in a lightweight VM that integrates with the host operating system.
Mac are not friendly to a developer. And they never were. The only reason why developer use them is because they need to program on iOS and thus need XCode (that is a terrible IDE) and the iOS toolchain.
As a developer I want a system where I am in full control and not a system that is locked down as macOS. I use Linux as a developer (in the embedded area) and it's perfect to me. Only sometime I have to use a Windows VM because of some esoteric hardware platform that have their proprietary compiler that works only on Windows.
That's just wrong on so many levels. The majority of developers using Mac don't touch Xcode at all.
And why should you spend a ton of money on an underpowered Mac while with the same amount of money you get a more performant Linux workstation I have no idea. And not name the fact that m1 Mac are cheap, yes they kind of are (not really, for 1200$ you can get a similar performant Linux laptop), if you don't need to run x86 software or virtual machines.
MacOS to me is an OS that is difficult to use and understand, with so many problems (that are admitted even by Apple, for example it wastes a ton of RAM for nothing).
Really I know macOS, I had a Macbook in the past, a Macbook pro 15 mid 2015, and it was kind of good (well, I paid it a ton of money), and still some things I appreciate more than my current laptop (the screen and the touchpad are fantastic, for example), but I hated MacOS, update after update it become slower and more full of useless stuff that consumed resources, and full of stupid privacy and security features that get in your way (like stupid prompts that you get when you try to run a third party application downloaded from the internet and you have to get every time in the Settings application to consent it - something that I had to research on the internet how to do the first time. They say Apple is intuitive right?)
Have you met android ? Omg that system requires DOUBLE the ram to do literally anything that an iPhone can do.. doesn't matter that it runs Linux technically either.. when shovel java on top of it..
It seems that ever since mobile computing gained a foothold and when Web applications started becoming to be feature-by-feature competitive with native desktop applications, the industry has largely and effectively abandoned the desktop except to serve essentially to provide platforms for device drivers and windowing systems that will ultimately run web browsers (which, lo and behold, happen to be developed by these same platform vendors). Native mobile applications exist, but only to justify the existence of walled-garden app stores. Modern operating systems have essentially become ChromeOS with support for "legacy" APIs like Cocoa and Win32 for running "legacy" desktop applications.
It would not be an exaggeration to say that the success of the iPhone was the worst thing that happened to the Mac. Compared to the iOS ecosystem, the Mac now makes up a small minority of Apple's profits. While Apple's ARM-based Macs are undoubtedly a major advance in terms of computer hardware, unfortunately on the software side macOS just isn't the same as it used to be. Mac OS X in the 2000's was truly ahead of its time, but today macOS is no longer heads-and-shoulders better than its competition, and its Unix core lags behind modern Linux and *BSD in terms of features.
While the Web has many advantages such as ease of distribution, there are key advantages of traditional desktops, such as better latency, the lack of dependence on Internet access, and the idea of desktop applications conforming to the UI/UX guidelines specified by the platform. Unfortunately, if all of our applications are Web applications, whether they are running in a web browser or as Electron apps, we lose out on the consistency and interoperability benefits that come from well-designed desktop applications.
I think the days of a polished ecosystem of well-designed applications that have consistent UI/UX guidelines with each other is coming to an end due to these market pressures.
One would have similar issues rigging up Docker to run on FreeBSD, because that’s also not Linux despite being plenty UNIXy.
Apple should have either let or at least recognized the need for containerization and followed.
Process isolation done right could solve end user security issues, instead of the half baked annoying dialog boxes they have littered throughout the system. It could also allow something similar to Docker for developers.
They also need to solve their relationship with GPL3. If it’s indeed that toxic, then they need to write or adopt alternatives with different licenses, instead of just shipping decades old binary.
Is it harder than on Windows?
It's harder than on Linux for sure, but that's because Docker uses features that are part of the Linux kernel, and so doesn't really work natively anywhere else.
They are proceeding with this plan, now that the initial fervor has died down.
You can't turn it off without disabling the majority of the platform security protections on the machine.
The "harder and slower" bit is debatable (you can run podman, for instance), but a lot of it is on Docker's side, not Apple's -- they even provide a hypervisor you can use with 10 or so lines of code!
The weird Safari summer was beta process working properly imo. They incorporated literally all of the constructive feedback. The common sentiment is that Safari now is better than the previous version.
Now if only Firefox could have followed this path with the removal of compact tabs but that's another story...