Catching Native Apps(mjtsai.com)
mjtsai.com
Catching Native Apps
https://mjtsai.com/blog/2022/01/12/catching-native-apps/
220 comments
> No installation makes an app better.
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.
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.
> Yet Another Account makes an app worse.
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.
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.
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.
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.
I thought we were more talking about Electron apps than Web apps, but you're right on that front.
[deleted]
> If not, they tend to be trivial to scrape.
Not if the "web page" is just a skeleton that gets filled in by Javascript. Like, you know, pretty much every web app out there.
Not if the "web page" is just a skeleton that gets filled in by Javascript. Like, you know, pretty much every web app out there.
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.
> even SPAs are trivial to scrape today
How? (I'm asking about the case where there is no API.)
How? (I'm asking about the case where there is no API.)
With something like Puppeteer [1]. That said, if we're now headed towards a canvas + WebAssembly world, things could get far more difficult.
[1] https://github.com/puppeteer/puppeteer
[1] https://github.com/puppeteer/puppeteer
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.
My understanding of the word "scraping" is primarily something related to en mass automated data extraction from user interfaces.
[deleted]
> 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.
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.
At least I can get the data out of web apps, for the most part, since they tend to run in a scriptable environment with built-in dev tools.
There are native apps on my phone where I can't even select the text because they didn't use the right control.
There are native apps on my phone where I can't even select the text because they didn't use the right control.
> 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).
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).
Discord has a website app, it's the same as the OS one, because, well, it's Electron. I use it and it works fine for me.
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!
The app version offers specific functionality that the web version does not, or implements poorly.
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.
I can’t understand how designers can work on the browser
It’s an horrible UX. No surprise it come out in these times where user interfaces are html documents masked as inconsistent UI.
It’s an horrible UX. No surprise it come out in these times where user interfaces are html documents masked as inconsistent UI.
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?
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.
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
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.
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.
Basically what was done in X Windows and Citrix/RDP is now the browser's role, and the wheel keeps on turning.
> And the worst part is, they might win
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.
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.
Oh wait, they did create a true cross-platform platform: the browser.
It is so cross platform, that some think it is too much work to support various browsers so they bundle Chrome with the application.
Could be worse I guess, there are those that ship a whole OS with the application.
Could be worse I guess, there are those that ship a whole OS with the application.
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.
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.
It runs in a web browser. It's a web app.
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!"
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.
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.
In this particular case, you might look at the Affinity Suite.
I was more than happy with the Adobe suite when it was still the Macromedia suite.
I've still got an install of Fireworks somewhere.
I've still got an install of Fireworks somewhere.
> 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."
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.
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.
And native accessibility controls. Absolutely.
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.
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.
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.)
(I also use Keep for the same reason as you but it isn't even close in terms of functionality.)
I don't think plume has ever tried to build a cross platform app which works on iOS. No notifications, no local storage, second class in every way.
> The best part of this article is this comment
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.
> 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.
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.
> 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.
> 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.
> 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.
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.
Windows and Mac users are typically catered for.
Windows and Mac users are typically catered for.
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.
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.
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.
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?
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.
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, 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.
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.”
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.
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.
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.
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.
> Slack is perfectly performant.
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).
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
>"When Google goes out of business.."
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.
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.
[deleted]
>growth-focused products
Yuck, no thanks. Can we just have good products?
Yuck, no thanks. Can we just have good products?
[deleted]
What do you think pays for these 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.
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.
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.
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.
If only the Windows team shared the same clearer view.
The more fundamental question here is: why, given what we know of the market share of devices running macOS, would anyone choose to develop solely for macOS (and thus target Apple-provided APIs)?
Now, let's be clear. I am not insisting that there are no reasons why anyone would do this. If you believe (rightly or wrongly) that your audience/user niche is overwhelmingly macOS-based, that's one pretty good reason right there.
But ... yep, truth be told, I can't imagine any other good reasons. If you're developing native applications in 2022, targetting a single platform makes almost no sense unless you pre-define your audience as limited to that platform. You may be able to create a viable revenue model doing that, but for every user on your chosen platform, there's somewhere between 2 and 20 who are irritated by your decision.
Now, let's be clear. I am not insisting that there are no reasons why anyone would do this. If you believe (rightly or wrongly) that your audience/user niche is overwhelmingly macOS-based, that's one pretty good reason right there.
But ... yep, truth be told, I can't imagine any other good reasons. If you're developing native applications in 2022, targetting a single platform makes almost no sense unless you pre-define your audience as limited to that platform. You may be able to create a viable revenue model doing that, but for every user on your chosen platform, there's somewhere between 2 and 20 who are irritated by your decision.
If you were to ask Mac-focussed companies like Panic or Rogue Amoeba I am certain they would tell you it's because they as individuals enjoy the Mac platform, and the user base is large enough to make it work despite being a niche of a niche.
I think as a society we often focus too much on growth and maximising. It's okay to keep steady and focus on the things you like.
Personally, I'm very glad that there are still companies out there targeting one platform, even for the platforms I don't use. Unless there are enough resources to focus on native versions for each platform, multi-platform software is often full of compromises IMO.
I think as a society we often focus too much on growth and maximising. It's okay to keep steady and focus on the things you like.
Personally, I'm very glad that there are still companies out there targeting one platform, even for the platforms I don't use. Unless there are enough resources to focus on native versions for each platform, multi-platform software is often full of compromises IMO.
Panic, Rogue (Bare Bones, Omni Group too) have built-in audience from ~3 decades of classic -> modern Mac development. I feel like it would be a lot different for a newcomer.
> It's okay to keep steady and focus on the things you like.
Absolutely, would never have it any other way.
Personally, I just want to believe in what I do, and if I believe in it, I don't want it restricted by platform. YMMV and that's cool.
Absolutely, would never have it any other way.
Personally, I just want to believe in what I do, and if I believe in it, I don't want it restricted by platform. YMMV and that's cool.
Sure, I can totally appreciate that.
FWIW I think there’ll always be a place for cross-platform frameworks, and that there’s still a lot of room for improvement in the space.
Things like Electron have undoubtedly resulted in tons of valuable software that simply would not have existed otherwise—now we just need to address the caveats.
FWIW I think there’ll always be a place for cross-platform frameworks, and that there’s still a lot of room for improvement in the space.
Things like Electron have undoubtedly resulted in tons of valuable software that simply would not have existed otherwise—now we just need to address the caveats.
I love some of the Mac only apps, but it's undeniable that this 2010-like dream of building a native Apple software and the monetization model (selling it on the App Store) is almost entirely gone. I honestly think this was a first-movers pipe dream. Once the competition caught up and the industry matured, interoperability was going to dominate all other arguments.
Today we live in an entirely different world, and the big corps are still funneling money into keeping these ecosystems alive (heck, there's no other way). Yet, no developer want to learn 6 stacks, not even the big corps do this for their own apps for gods sake.
I will bet my left thumb that eventually GUIs will be predominantly made with web technologies, will run on all platforms, and will have native proprietary extensions. The web today even has a path to become language agnostic with wasm.
Today we live in an entirely different world, and the big corps are still funneling money into keeping these ecosystems alive (heck, there's no other way). Yet, no developer want to learn 6 stacks, not even the big corps do this for their own apps for gods sake.
I will bet my left thumb that eventually GUIs will be predominantly made with web technologies, will run on all platforms, and will have native proprietary extensions. The web today even has a path to become language agnostic with wasm.
The reason software shops used to justify developing either Mac-exclusive or at least Mac native apps was because Apple customers tend to spend more money on software in general. And that was when Apple had an even smaller market share. I suspect it’s still true to some extent, but probably much less so than in the past. And almost certainly because:
- The App Store(s) drive pricing down
- Free alternatives are more prevalent, particularly because of Electron
- The App Store(s) drive pricing down
- Free alternatives are more prevalent, particularly because of Electron
One answer is that you can write a better app, and that can be a competitive advantage. For example, I bought Fork and not GitKraken, because Fork's native experience is so much better than Electron-based alternatives.
This doesn't preclude you from releasing the app for other platforms: Fork also has a Windows app, with separate UIs but presumably shared business logic. This is how cross-platform development used to be done. It's certainly more total work, but you don't hit a quality ceiling like you do with write-once-run-anywhere frameworks.
This doesn't preclude you from releasing the app for other platforms: Fork also has a Windows app, with separate UIs but presumably shared business logic. This is how cross-platform development used to be done. It's certainly more total work, but you don't hit a quality ceiling like you do with write-once-run-anywhere frameworks.
Consistency across apps on the same platform is directly opposed to consistency across platforms within the same app.
As a multi platform user, I prefer that Figma, Discord, Spotify and vscode always look and feel the same independent of which machine I'm using.
As a multi platform user, I prefer that Figma, Discord, Spotify and vscode always look and feel the same independent of which machine I'm using.
> This is how cross-platform development used to be done.
Not for at least 20 years. We've had Qt, GTK, WxWidgets for longer than that. Those GUI toolkits are how cross-platform developer "used to be done", and to a large extent still is.
Electron is not the only way to do cross-platform, and there are lots of reasons why it absolutely is not the best way. What it does have in its favor is leveraging the knowledge of developers who've only ever worked on webstacks. Not much else.
Not for at least 20 years. We've had Qt, GTK, WxWidgets for longer than that. Those GUI toolkits are how cross-platform developer "used to be done", and to a large extent still is.
Electron is not the only way to do cross-platform, and there are lots of reasons why it absolutely is not the best way. What it does have in its favor is leveraging the knowledge of developers who've only ever worked on webstacks. Not much else.
Another thing Electron has going for it is better built-in accessibility support, at least on Windows. wx is fine as long as you stick to the wrappers over native widgets; and there are caveats even then (e.g. having to use different wx classes to get a native list view on different platforms). Last time I checked, GTK is still inaccessible with screen readers on Windows and Mac. Qt seems OK; I haven't done a detailed evaluation lately, but I would still bet on Electron coming out ahead, particularly on Windows.
Yes, a11y matters and needs to be attended to for apps where it makes sense. Doesn't make a lot of sense for some things though (e.g. where the main app display is essentially a drawing canvas). Not sure how much better Electron could be in the scenario.
Native apps don't have to be exclusive.
You cannot run an application that uses Apple's *Kit APIs on anything other than macOS.
Obviously for native apps you have to develop different frontends for different OSes but you don't have to develop the whole app exclusively for one OS.
Case in point (the cross-platform app I've spent 20+ years developing): 500k lines of code. 190k lines of GUI code. So nearly 40% of the codebase is dependent on the GUI toolkit we use. Not only that, but the GUI part of the application is by far the most complex to develop, even though the rest of it is realtime, multithreaded deeply complex programming. The idea that we'd maintain more than one GUI "frontend" is completely absurd.
Developing native application is not targeting single platform. It means choosing a different set of tools and technologies used for development. Instead of relying on some cross-platform framework / module / engine you just rely on different stuff which is closer to the platforms you plan supporting.
If the tools & technologies are only available on one platform, as is the case with the overwhelming majority of Apple APIs (same for Windows), then I'm sorry, but selecting them is targeting a single platform.
They can exist because their "small" markets or audience will pay for their software. That simple.
In the end Electron may be slow and bloated, but it is easy to distribute and you can make it look exactly how you want. People often say they want apps to look "native", but really most people I have met don't really care that Spotify doesn't use native Windows widgets.
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.
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.
People may not care whether apps fit in visually (I do, but I acknowledge the vast majority of people don’t), but I think the subtle differences in behaviour caused by software having to or choosing to reinvent the wheel is a major problem.
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.
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.
caused by software having to or choosing to reinvent the wheel is a major problem.
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".
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".
> It’s always small things like keyboard shortcuts, focus behaviour, placement of controls, but it’s all one more roadblock to using the computer.
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?
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?
I dunno, I’ve been using iTerm for years, which fully supports Cmd+arrow to jump to the start and end of lines.
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.
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.
One app with inconsistent behaviour is fine. Many/All apps is not.
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.
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.
> People often say they want apps to look "native", but really most people I have met don't really care
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.
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.
I fully agree. Nobody cares if it doesn't look native as long as the relevant native integrations, like app/ tray icon, notifications and URL handlers, are there. Even without native speed it's fast enough for most users.
Electron also has an (comparatively) awesome Dev experience in regard to the tooling available and the nodejs ecosystem.
Electron also has an (comparatively) awesome Dev experience in regard to the tooling available and the nodejs ecosystem.
Maybe for something like Spotify it doesn’t matter, but what about a real app?
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?
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?
> a real app
This is just moving the goalposts.
This is just moving the goalposts.
It's possible to make cross-platform apps look native, but it's much harder work to make cross-platform apps act native. For example, there are themes that make an XFCE desktop look like Mac OS 9 or Windows 2000, but it doesn't make applications behave like native Mac OS 9 or Windows 2000 applications. This is not just a criticism of Electron; this criticism extends to many other cross-platform toolkits. Using non-native controls, for example, has accessibility consequences if the cross-platform toolkit does not properly hook with the native platform's accessibility API.
A cross-platform toolkit that implemented compliant looks and behaviors across all of its supported platforms would be an amazing thing.
A cross-platform toolkit that implemented compliant looks and behaviors across all of its supported platforms would be an amazing thing.
> Using non-native controls, for example, has accessibility consequences
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?
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?
Not necessarily. macOS and iOS have multiple accommodations for users with accessibility needs, from dynamic type to UI element voiceover plus pretty decent speech-to-text recognition and haptic feedback. Developers that want to take the time can build apps that can be effectively used by users with visual and/or auditory deficits.
There are plenty of good arguments for Electron or using web tech but this one never really sticks for me. Users indeed care if the software runs slowly or is missing functionality, shortcuts or accessibility features they're used to but they might not know that these issues are exacerbated by using cross-platform tech. You can overcome these of course but many developers won't bother.
> In the end Electron may be slow and bloated
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.
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.
Coming from someone that has been using an old computer for a while, I could definitely tell the difference between Electron and non-Electron apps based on their speed. E.g. Spotify and Discord. They take forever to start (the worst part IMO), there's significant lag when changing pages, and they just feel bad to use. If you've never noticed it, then your computers are very good.
Spotify, at least on Windows uses something other than Electron as far as I can tell.
> 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.
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.
Try unplugging from the power outlet and you will notice the difference.
That's maybe a good argument for a product manager, but very poor one for the end users.
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.
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.
Electron is bloated because it's vendoring two major pieces of software (chrome and node). The binary size and memory footprint can be solved with some minor help from platforms (already in progress - see webview). Web itself is more than fast enough for GUI, and is incredibly optimized, both layout and js engines (or wasm, if that's your thing).
Good points, but you're missing something: the web platform is incredibly and intrinsically complex, and any complete implementation is going to necessarily also be complex and consume a minimum amount of resources. I would need to see some empirical evidence that this minimum amount is low enough so as to not be noticeable on 10-year-old hardware.
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.
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.
> the web platform is incredibly and intrinsically complex
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).
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).
Very good point about the difference between speed and size wrt webtech applications in particular - I completely agree, I think that frameworks are the cause of power efficiency/performance issues, but that the platform isn't intrinsically slow.
It definitely pisses me off that billion-dollar companies can't be bothered to write native apps for desktop platforms anymore, but not enough to make it worth it to forgo the benefits of Electron apps and web apps as an end user.
I'll add another one of "user doesn't care". They do: https://news.ycombinator.com/item?id=29930397 It's a thousand little things.
>most people I have met don't really care that Spotify doesn't use native Windows widgets
Probably because Windows was always a UI/UX clusterfuck, so Windows users don’t notice the difference. Mac enthusiasts on the other hand…
Probably because Windows was always a UI/UX clusterfuck, so Windows users don’t notice the difference. Mac enthusiasts on the other hand…
> three competing app frameworks won’t create it
> 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.
> 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.
It struck me as a very mature move by Apple to do the two-pronged approach and launch both SwiftUI and Catalyst around the same time (they are for different purposes... greenfield projects vs. ports).
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.
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.
It's fitting with their historical approach to OS X development. The transition strategy to OS X was "If you're starting from scratch, use Cocoa (SwiftUI). If you're porting an existing Mac app, use Carbon (Catalyst)."
[deleted]
It's truly Google-like in its inconsistency and confusion for developers.
Google? Nah, Microsoft is the king of incompatible parallel UI toolkits.
The difference is, Microsoft doesn't abandon their old stuff as soon as something newer and shinier comes along. I can still write a Win32 app today, almost 30 years after NT 3.1 came out. Even more impressive, if I use an old-enough version of the compiler and stick to a functional subset of the API, the program will run on both an NT 3.1 box and a brand-new Windows 11 machine.
Try that in the Apple ecosystem.
Try that in the Apple ecosystem.
lol let's not pretend that Apple has limited resources though. Apple has a very limited amount of core developpers (e.g webkit being abandonware) and they are probably mediocre on average but obviously this is artificial scarcity.
WebKit has had 32 commits to trunk in the last 24 hours (35 if you include 3 reverts).
[edit] source: https://github.com/WebKit/WebKit/commits/main
[edit] source: https://github.com/WebKit/WebKit/commits/main
Webkit has 246,027 commits
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: https://github.com/WebKit/WebKit/pulse https://github.com/chromium/chromium/pulse
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: https://github.com/WebKit/WebKit/pulse https://github.com/chromium/chromium/pulse
Are you seriously going to make an argument on the relative investment each browser engine gets based on how many commits they have?
Are you seriously gonna ignore that pulse also shows the diffs (additions/deletions) and that corroborate with commit rate.
Moreover I have expertise in web features, i have read a big chunk of chromestatus.com features and the gap between chromium and webkit is even bigger than the gap between chromium and gecko.
Finally the most meaningful metric is: webkit: ~60 developers worked on it this week, chromium: >700 developers
The gradient gap is pathetically big
...5 of which came from actual Apple employees. Putting it in perspective, the WebKit Open Source maintainers made more contributions today than the people who are paid to do so.
I’m not sure how you’re counting contributions, but well over half of WebKit commits come from Apple employees and (skimming the commit history) I see nothing that refutes that in the most recent commits. The majority of the other commits come from Igalia, with a handful of contributions from Sony, Google, etc. and then some random interested contributors.
Yes igalia, a google paid company
Why would apple self sabotage itself by not hiring and allocating good developers to their frameworks?
Mediocrity can be very hard to explain but it can be asked for many things at apple. Why does the richest software company on earth has made almost zero innovative software products nor technologies this decade?
The only technical talent at Apple is making hardware.
At the end of this...
> 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
> 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
This is truly one of the biggest issues when developing apps for customers. They check the app holding an iOS phone in their left hand and an Android one in their right hand, and couldn't for their own life imagine that a user is not in that situation.
As a random user, I'm annoyed non-OS-specific functionality is only implemented on a different platform. So I most definitely care that they're not consistent in that sense.
> Meanwhile, Apple is no longer leading by example, at least not in a good way, as its recent Mac apps have been Catalyst ports or weird hybrids that feel more Web or iOS than Mac.
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.
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.
> 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.
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.
I am ditching 5-year's efforts to code native apps and porting to js/wasm (as "native" as possible). Already have a beta that feels ok. Sad but true
Yup. Attempted to write a cross-platform app with MacOS support being a big part of it.
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.
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.
Can you elucidate the problems you ran into on MacOS ?
>Web app developers don’t need permission to deploy their code.
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.
Edit: formatting.
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.
Edit: formatting.
While I wholeheartedly agree I can't imagine why the author left out a key pillar of the problem: Apple's documentation has become useless and/or non-existent.
- 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.
- 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 just like writing native apps. I always have. I’ve been doing it for a long time. I liken it to an impressionistic-style oil painter, in this age of photorealistic 3D artwork. The 3D work is amazing, and often takes even more effort than the oil painting, but they feel different, to make, and result in unquantifiable, visceral, differences to the viewers. Some will prefer the 3D work; others will prefer the oil painting.
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.
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.
I will say generally web applications would be like the impressionist painting and native apps the exacting 3d work if we use a more obvious criterion for the analogy.
Fair point.
A computer should still function when offline. A time will come when more people distrust the internet and return to using their computer and its apps disconnected from it, or at least highly restricting what apps try to connect to. I do this already using Simplewall because it warns and asks permission for any app or protocol that I do not specifically allow, and I end up blocking most of them, especially OS "services".
You can make cross platform native apps with Delphi https://www.embarcadero.com/products/delphi
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
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
I have seen this brought up a few times and from the website the crossplatform native claims are impressive, but I can't find any basic guide or documentation for getting started anywhere. Why is Delphi never a part of the conversation when React Native, Flutter, Ionic, Xamarin etc are discussed?
Compared to the others you mention Delphi is streets ahead. There's a free download at https://www.embarcadero.com/products/delphi/starter/free-dow...
Here's some resources to get you started
There's a free book here: https://lp.embarcadero.com/Object-Pascal-Handbook-2021
and another here (pdf) (probably the best to start) https://www.marcocantu.com/edelphi/EssentialDelphi_1033_2020...
There's intro videos here https://www.embarcadero.com/resources/videos
They have a YouTube channel here, that has a lot of more in depth stuff https://www.youtube.com/c/EmbarcaderoTechnologies
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.
If you want to see components have a look at tmssoftware.com for some drag and drop components, you can even make web applications with Delphi with their web components (they cross compile to javascript)
Here's some resources to get you started
There's a free book here: https://lp.embarcadero.com/Object-Pascal-Handbook-2021
and another here (pdf) (probably the best to start) https://www.marcocantu.com/edelphi/EssentialDelphi_1033_2020...
There's intro videos here https://www.embarcadero.com/resources/videos
They have a YouTube channel here, that has a lot of more in depth stuff https://www.youtube.com/c/EmbarcaderoTechnologies
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.
If you want to see components have a look at tmssoftware.com for some drag and drop components, you can even make web applications with Delphi with their web components (they cross compile to javascript)
Because it's not as cool, mostly. It's _very_ stable tech, and thus perceived as old.
Also, nobody really wants to code in Object Pascal anymore (despite its readability, etc.).
Also, nobody really wants to code in Object Pascal anymore (despite its readability, etc.).
I’ve been a Mac user for over 30 years. What kept us when it was a slower, more expensive computer was the user experience.
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. 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.
I wish they’d abandon the annual release cycle. At this point I’d argue even the iPhone is mature enough that annual releases are more hindrance than help, but this is certainly the case for the Mac.
> 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.
> 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.
I wish they abandon user feature release. Apart from UI changes like Dark Mode, I cant remember a single new feature from the past 5 - 6 years that I used on macOS.
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.
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 this point, I’d be grateful if they release what they promise. Universal Access, where art thou?
> 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.
I think the every 6 month minor release cycle Windows and Ubuntu have converged on is probably the right one. You can't actually do enough stuff in a year in something like an OS to justify a major version upgrade.
> The Unix layer is abandoned.
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.
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.
We’ve been running VMs at near native speeds for a decade. Docker on Mac runs 20-50x slower mostly due to poor I/O which is a platform “feature”, they are already on the latest hypervisor framework provided by Apple.
You can run VMs on the Mac at near native speeds. I play some pretty unoptimized games with friends who are running Windows in a VM on their M1 Macs, and their performance is fine.
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.
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 problem isn’t that the VM itself is slow (in fact, Apple’s hypervisor is pretty good IME) but that sharing files with the Mac filesystem is slow. If you use Docker volumes the issue goes away, but that’s kind of hard unless your editor has support for cloning your code to a Docker volume (so, it’s hard unless you use VSCode).
The dev environments feature in preview for Docker Desktop[0] 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.
0: https://docs.docker.com/desktop/dev-environments/
The dev environments feature in preview for Docker Desktop[0] 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.
0: https://docs.docker.com/desktop/dev-environments/
Reminder: Docker Desktop is a) closed source and b) also is spyware.
You're much better off using your own VM and the free software docker CLI tool. Set DOCKER_HOST to "ssh://root@$VM_IP".
You're much better off using your own VM and the free software docker CLI tool. Set DOCKER_HOST to "ssh://root@$VM_IP".
> Docker on Mac runs 20-50x slower mostly due to poor I/O which is a platform “feature”
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.
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.
That might be exaggerated because I'm including overhead from other aspects of Docker, but those are not exactly made up numbers - it's roughly the difference between building the project I currently work on locally, vs building its Dockerfile.
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 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.
I don’t question your measurements, I even agreed with your technical root cause analysis. What I questioned was, emphasis added to clarify: ‘poor I/O which is a platform “feature”’. This seems like a chip on shoulder attack, but it doesn’t seem like you have that particular chip on your shoulder. So I’m asking again if you can clarify what you meant by platform feature.
macOS has not abandoned its Unix layer, and in fact is still a certified Unix (https://www.opengroup.org/openbrand/register/). However, there is a growing gap between certified Unix and the innovations that *nix-like systems have included in the past decade. macOS has not kept up with Linux and the BSDs in terms of feature parity, resulting in a growing gap between the features that come with modern Linux, FreeBSD, and OpenBSD versus macOS. A minor issue is macOS's BSD-derived utilities being based on late 1990s-early 2000s versions and thus not taking advantage of functionality added in later versions of these BSDs. Other issues include no support for file systems such as ZFS and btrfs in macOS (though I remember when ZFS support was proposed for Mac OS X Leopard), and macOS not supporting FreeBSD jails (https://docs.freebsd.org/en/books/handbook/jails/).
> Other issues include no support for file systems such as ZFS and btrfs in macOS
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.)
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 was not only a joy to the end user but for t he developer to write apps
on.
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.
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.
Docker is slower because it runs a VM. The macOS kernel doesn't include any containerization API, thus a native Docker cannot be built. Of course even if it can be built the kernel would be completely different than Linux and you could only run macOS containers and not the containers on the public registry, but it would still be an improvement.
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.
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.
> 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.
That's just wrong on so many levels. The majority of developers using Mac don't touch Xcode at all.
That's just wrong on so many levels. The majority of developers using Mac don't touch Xcode at all.
Don't see what macOS gives you more than Linux if you don't need XCode. While I can understand developers that use Windows (there are a ton of compilers and development environments that unfortunately are only for Windows, especially in the embedded field) I can't name a tool other than XCode that doesn't run on Linux.
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?)
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?)
> 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).
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..
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..
Exactly. As a long-time Mac user, I miss the days when Apple and Microsoft were focused on advancing desktop computing, and when they heavily invested in the macOS and Windows platforms.
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.
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.
Docker running badly is just as much a Docker problem for it being so tied to Linux as it is a macOS problem. It’s one of the big cons of a “ship the whole rainforest” approach: you’re trading fewer variables for your application for performances losses due to greater possible incongruities between the abstraction and the host.
One would have similar issues rigging up Docker to run on FreeBSD, because that’s also not Linux despite being plenty UNIXy.
One would have similar issues rigging up Docker to run on FreeBSD, because that’s also not Linux despite being plenty UNIXy.
AFAIK macOS doesn't have namespaces/jails/zones so it would be near-impossible to build native Docker for macOS.
How useful would Mac-native docker be? You couldn't run any of your Linux containers and I cannot see much utility in macOS containers.
Plenty of people develop on macOS and deploy on Linux (this isn't completely reliable but people consider it good enough for Ruby/Python/Node.js) so I could imagine a portable Dockerfile that generates either a macOS image or a Linux image depending where it is built. This would speed development dramatically.
But isn't the whole point of Docker having a 100.0000000% repeatable environment? And how would that portable Dockerfile would look?
> Why is it harder and slower to run docker on macOS than anywhere else?
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.
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.
Regarding the many Docker/Unix comments: there was a time when Apple led the way on Unix land. If you love or hate systemd, you have Apple and launchd to thank for.
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.
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.
Let's not forget that they are shipping signed, unmodifiable OSes (in the default security config) that will be scanning your local files without your consent for contraband, and any true or false positives will be reported to Apple and the police.
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.
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.
Docker is based on Linux namespacing, and the Mac does not use a Linux kernel, so you have to run a VM to have one. That's it, period.
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 "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!
> Let’s not even discuss whatever almost happened to Safari.
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...
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...
Side rant:
> No installation makes an app better.
No install isn’t really true of web apps. It’s a fallacy in my mind, it’s more accurately continuous implicit installation. You still have to install a browser. Then that browser downloads website data which then implicitly renders UI and executes JavaScript. Which is what installation in the modern day is, download the file then setup the file to execute.
> No installation makes an app better.
No install isn’t really true of web apps. It’s a fallacy in my mind, it’s more accurately continuous implicit installation. You still have to install a browser. Then that browser downloads website data which then implicitly renders UI and executes JavaScript. Which is what installation in the modern day is, download the file then setup the file to execute.
Otoh You don’t have to register an account for native apps.
Which ones? Native or not has nothing to do with requiring account registration.
> The Mac’s Unix layer has been withering
Kind of a strange comment, updating those programs listed is a one-line string of text.
Kind of a strange comment, updating those programs listed is a one-line string of text.
god what is going on with this page, Safari keeps on deciding to stop rendering anything when I scroll up, none of the links work when I hover over them, it breaks Reader mode too.
edit: oh now that I bitched about it here it's loading fine, how peculiar.
edit: oh now that I bitched about it here it's loading fine, how peculiar.
Make Mac's key-binding(yes the option-command-thing) work across non-Mac will be a good first step, after all, on the Desktop level, Mac is not even the mainstream yet, and I hope it will never be.
I tried really hard to embrace apple ecosystem since last August with a $4000 macbook pro(assigned by my employer with no other alternatives), now I apply for an exchange to any non-Mac laptop(or desktop), be it a windows or linux one. I don't want to touch Apple's product for the rest of my life.
I could list a top-10 reasons why I "hate" Mac, but I will just stop here, anything more on the subject is a waste of time.
I tried really hard to embrace apple ecosystem since last August with a $4000 macbook pro(assigned by my employer with no other alternatives), now I apply for an exchange to any non-Mac laptop(or desktop), be it a windows or linux one. I don't want to touch Apple's product for the rest of my life.
I could list a top-10 reasons why I "hate" Mac, but I will just stop here, anything more on the subject is a waste of time.
> 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.