19 ms·

Catching Native Apps

196 points by bangonkeyboard 5y ago

valleyer 5y ago
> 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.
- deleted 5y ago
  [deleted]
- The_rationalist 5y ago
  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.
  - favorited 5y ago
    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 https://github.com/WebKit/WebKit/commits/main
    - The_rationalist 5y ago
      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/WebKit/WebKit/pulse https://github.com/chromium/chromium/pulse https://github.com/chromium/chromium/pulse
      - saagarjha 5y ago
        Are you seriously going to make an argument on the relative investment each browser engine gets based on how many commits they have?
        The_rationalist 5y ago
        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
    - smoldesu 5y ago
      ...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.
      - saagarjha 5y ago
        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.
        The_rationalist 5y ago
        Yes igalia, a google paid company
  - password1 5y ago
    Why would apple self sabotage itself by not hiring and allocating good developers to their frameworks?
    - The_rationalist 5y ago
      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.
- Apocryphon 5y ago
  It's truly Google-like in its inconsistency and confusion for developers.
  - aaaaaaaaaaab 5y ago
    Google? Nah, Microsoft is the king of incompatible parallel UI toolkits.
    - CamperBob2 5y ago
      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.
- frou_dh 5y ago
  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.
  - favorited 5y ago
    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)."
egypturnash 5y ago
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.
PaulDavisThe1st 5y ago
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.
- rbreaves 5y ago
  They can exist because their "small" markets or audience will pay for their software. That simple.
- deergomoo 5y ago
  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.
  - PaulDavisThe1st 5y ago
    > 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.
    - 5y ago
tambourine_man 5y ago
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.
- eyelidlessness 5y ago
  > 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.
  - ricardobeat 5y ago
    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.
    - favorited 5y ago
      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.
melissalobos 5y ago
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.
- dmitriid 5y ago
  I'll add another one of "user doesn't care". They do: https://news.ycombinator.com/item?id=29930397 https://news.ycombinator.com/item?id=29930397 It's a thousand little things.
- c0balt 5y ago
  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.
- aaaaaaaaaaab 5y ago
  >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…
- jolux 5y ago
  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.
- deergomoo 5y ago
  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.
jolux 5y ago
The best part of this article is this comment from Plume: > This has always been wrong, because it completely discounts the advantages of the web. Cross-platform compatibility makes an app greater. No installation makes an app better. Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater. Automatic updating makes an app greater. Being able to open the app I normally use on my desktop on my phone in a pinch makes an app greater. Not locking me into using a Mac makes an app greater. I'm all-in on the Apple ecosystem, but collaboration and universal access on all platforms and automatic updates are considered table stakes for growth-focused products (edit: most products that normal people care about) these days. The cost-benefit analysis of using Mac apps when I have to collaborate with people so often just doesn't pencil out in favor of native apps for most of the things I do. The few places where it does are things like Notes, which is a first party app that all Apple users have, but even then it's a pain for people on other platforms to collaborate. Forgot about all the Unix stuff. That part is easy to fix if they care about it. If Apple still wants the Mac to succeed as a native platform, they will have to solve enough of these problems for their developers that the Mac is a competitive native platform to the web. I don't really see a way forward for that strategy except building some sort of cross-platform UI toolkit, whether that means web apps run natively on the Mac or Mac apps run natively on the web and other platforms or what. Microsoft has been working fairly aggressively in integrating Windows with Android apps and building a new cross-platform app toolkit. Without progress on this front, I predict continuing decline of the Mac as a developer platform.
- brazzledazzle 5y ago
  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.
yepthatsreality 5y ago
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.
- pacifika 5y ago
  Otoh You don’t have to register an account for native apps.
  - friedman23 5y ago
    Which ones? Native or not has nothing to do with requiring account registration.
collaborative 5y ago
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
- vorpalhex 5y ago
  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.
  - lenkite 5y ago
    Can you elucidate the problems you ran into on MacOS ?
synergy20 5y ago
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.
Klonoar 5y ago
>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.
harryf 5y ago
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
- lultimouomo 5y ago
  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.
- magicalhippo 5y ago
  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.
ary 5y ago
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.
chadcmulligan 5y ago
You can make cross platform native apps with Delphi https://www.embarcadero.com/products/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
- udbhavs 5y ago
  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?
  - rcarmo 5y ago
    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.).
  - chadcmulligan 5y ago
    Compared to the others you mention Delphi is streets ahead. There's a free download at https://www.embarcadero.com/products/delphi/starter/free-download 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 https://lp.embarcadero.com/Object-Pascal-Handbook-2021 and another here (pdf) (probably the best to start) https://www.marcocantu.com/edelphi/EssentialDelphi_1033_20200319.pdf https://www.marcocantu.com/edelphi/EssentialDelphi_1033_2020... There's intro videos here https://www.embarcadero.com/resources/videos 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 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)
pornel 5y ago
> 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.
- Klonoar 5y ago
  > 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.
aparticulate 5y ago
> The Mac’s Unix layer has been withering Kind of a strange comment, updating those programs listed is a one-line string of text.
ChrisMarshallNY 5y ago
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.
- donkeybeer 5y ago
  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.
  - ChrisMarshallNY 5y ago
    Fair point.
fit2rule 5y ago
anonimamente 5y ago
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".

> 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.

deleted 5y ago
[deleted]
The_rationalist 5y ago
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.
- favorited 5y ago
  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 https://github.com/WebKit/WebKit/commits/main
  - The_rationalist 5y ago
    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/WebKit/WebKit/pulse https://github.com/chromium/chromium/pulse https://github.com/chromium/chromium/pulse
    - saagarjha 5y ago
      Are you seriously going to make an argument on the relative investment each browser engine gets based on how many commits they have?
      - The_rationalist 5y ago
        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
  - smoldesu 5y ago
    ...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.
    - saagarjha 5y ago
      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.
      - The_rationalist 5y ago
        Yes igalia, a google paid company
- password1 5y ago
  Why would apple self sabotage itself by not hiring and allocating good developers to their frameworks?
  - The_rationalist 5y ago
    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.
Apocryphon 5y ago
It's truly Google-like in its inconsistency and confusion for developers.
- aaaaaaaaaaab 5y ago
  Google? Nah, Microsoft is the king of incompatible parallel UI toolkits.
  - CamperBob2 5y ago
    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.
frou_dh 5y ago
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.
- favorited 5y ago
  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)."

egypturnash 5y ago

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.

PaulDavisThe1st 5y ago

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.

rbreaves 5y ago
They can exist because their "small" markets or audience will pay for their software. That simple.
deergomoo 5y ago
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.
- PaulDavisThe1st 5y ago
  > 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.
  - 5y ago

tambourine_man 5y ago

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.

eyelidlessness 5y ago
> 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.
- ricardobeat 5y ago
  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.
  - favorited 5y ago
    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.

melissalobos 5y ago

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.

dmitriid 5y ago
I'll add another one of "user doesn't care". They do: https://news.ycombinator.com/item?id=29930397 https://news.ycombinator.com/item?id=29930397 It's a thousand little things.
c0balt 5y ago
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.
aaaaaaaaaaab 5y ago
>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…
jolux 5y ago
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.
deergomoo 5y ago
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.

jolux 5y ago

The best part of this article is this comment from Plume: > This has always been wrong, because it completely discounts the advantages of the web. Cross-platform compatibility makes an app greater. No installation makes an app better. Simple collaboration and sharing with anyone, including people on weird devices like Chromebooks, makes an app greater. Automatic updating makes an app greater. Being able to open the app I normally use on my desktop on my phone in a pinch makes an app greater. Not locking me into using a Mac makes an app greater. I'm all-in on the Apple ecosystem, but collaboration and universal access on all platforms and automatic updates are considered table stakes for growth-focused products (edit: most products that normal people care about) these days. The cost-benefit analysis of using Mac apps when I have to collaborate with people so often just doesn't pencil out in favor of native apps for most of the things I do. The few places where it does are things like Notes, which is a first party app that all Apple users have, but even then it's a pain for people on other platforms to collaborate. Forgot about all the Unix stuff. That part is easy to fix if they care about it. If Apple still wants the Mac to succeed as a native platform, they will have to solve enough of these problems for their developers that the Mac is a competitive native platform to the web. I don't really see a way forward for that strategy except building some sort of cross-platform UI toolkit, whether that means web apps run natively on the Mac or Mac apps run natively on the web and other platforms or what. Microsoft has been working fairly aggressively in integrating Windows with Android apps and building a new cross-platform app toolkit. Without progress on this front, I predict continuing decline of the Mac as a developer platform.

brazzledazzle 5y ago
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.

yepthatsreality 5y ago

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.

pacifika 5y ago
Otoh You don’t have to register an account for native apps.
- friedman23 5y ago
  Which ones? Native or not has nothing to do with requiring account registration.

collaborative 5y ago

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

vorpalhex 5y ago
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.
- lenkite 5y ago
  Can you elucidate the problems you ran into on MacOS ?

synergy20 5y ago

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.

Klonoar 5y ago

>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.

harryf 5y ago

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

lultimouomo 5y ago
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.
magicalhippo 5y ago
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.

ary 5y ago

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.

chadcmulligan 5y ago

You can make cross platform native apps with Delphi https://www.embarcadero.com/products/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

udbhavs 5y ago
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?
- rcarmo 5y ago
  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.).
- chadcmulligan 5y ago
  Compared to the others you mention Delphi is streets ahead. There's a free download at https://www.embarcadero.com/products/delphi/starter/free-download 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 https://lp.embarcadero.com/Object-Pascal-Handbook-2021 and another here (pdf) (probably the best to start) https://www.marcocantu.com/edelphi/EssentialDelphi_1033_20200319.pdf https://www.marcocantu.com/edelphi/EssentialDelphi_1033_2020... There's intro videos here https://www.embarcadero.com/resources/videos 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 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)

pornel 5y ago

> 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.

Klonoar 5y ago
> 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.

aparticulate 5y ago

> The Mac’s Unix layer has been withering Kind of a strange comment, updating those programs listed is a one-line string of text.

ChrisMarshallNY 5y ago

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.

donkeybeer 5y ago
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.
- ChrisMarshallNY 5y ago
  Fair point.

fit2rule 5y ago

anonimamente 5y ago

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".