5 ms·

On this note, do you have any notes or resources on what makes a MacOS app "native"? It's a quality people discuss but I can't identify. I used MacOS briefly 2

On this note, do you have any notes or resources on what makes a MacOS app "native"? It's a quality people discuss but I can't identify. I used MacOS briefly 2000-2004, and then got a Macbook in 2022. Even among Apple's built-in apps, I can't identify why they would be considered "native". For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. One would also expect Applescript / Automator (Apple's built-in macro tool, a-la AutoHotkey / xdotool) to work with native apps, but it doesn't work on ARM Macbooks. Compared to Linux, I think anyone with no experience in it could sort native GTK vs native Qt vs native xMotif applications. But I think "native" as a quality is more of a dependency management and consistency question. The only thing I can recognize from Panic's screenshots that appear "native" is the Preferences page, in the older "grid on a shelf" format. (edit) And the "install applications by dragging to the Applications" folder workflow, which I appreciate very much. All this is to ask, what does "works and feels native" mean and what makes it desirable?

adolph 2y ago
> For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. For the grey beards of MacOS: This guy trashes the HIG [Apple Human Interface Guide] the way Johnny Depp trashes a hotel room. He even sports a custom radius on his window corners. No other window on the system has a shape like this. It’s wild. Just wait until the HIG zealots get a load of this guy. https://daringfireball.net/2005/09/anthropomorphized https://daringfireball.net/2005/09/anthropomorphized
joshstrange 2y ago
Apple that follow the HIG [0] closely are normally considered "mac native" (though I don't like the word "native" here as I normally use it to differentiate between electron/native). [0] https://developer.apple.com/design/human-interface-guidelines https://developer.apple.com/design/human-interface-guideline...
crazygringo 2y ago
> what makes a MacOS app "native"? For me, it has three parts: 1) Does it look native at a pixel level? In other words, does it use a standard Mac window and title bar and buttons and widgets and all the rest? 2) Is it organized according to Mac UX conventions? Does it put commands in the menu bar rather than inside of windows? Are menu items where you'd expect? Is the "Settings..." command where you'd expect, and is the Settings dialog laid out in standard tabs or icons across the top, rather than something else (like a list box on the left)? 3) Does it respect all standard gestures and shortcuts and animations? If I press opt+left in a textbox, will the cursor jump to the previous word? If I press cmd+right, will it jump to the end of the text? If I scroll down, will it bounce at the bottom? That's what it means. And it's desirable for 1) aesthetics, 2) understandability, and 3) usability directly corresponding to those three points. Aesthetics is less important but it's still nice. Understandability is important because I don't want to hunt for a command when it's not where I'd expect. And usability is critical because when I cmd+right in a text box and it doesn't work, it's incredibly frustrating. Obviously, "native" is not a binary but is rather a continuum. And yes, even Apple's own apps are not always 100% at the "native" end, especially with stuff they've designed in conjunction with iOS. Which I think a lot of Mac users find frustrating.
- isametry 2y ago
  Greatly put, thank you so much. We should put this up somewhere as the Mac-assed manifesto. But I would actually add, on a more fundamental level: 0) Does it actually run on my metal? I.e. not in a VM, not any sort of "thin client", and CERTAINLY not Electron… but rather an actual solid piece of software compiled for the computer it's running on? You say "native is not a binary" but actually, in my opinion yes, it is also very much the binary!
- wpm 2y ago
  "is the Settings dialog laid out in standard tabs or icons across the top, rather than something else (like a list box on the left)?" Or worse, a huge plain old JSON with tons of multi line comments explaining what one particular key does. Like, I get it, its l33t and haxx0r to use a text file for settings, and yeah, you can easily transfer it to other platforms unlike an XML Plist file, but I despise apps that don't even bother providing a basic UI for changing settings. Ctrl+F "autocomplete" (30 results) is a *terrible* experience vs a natively drawn "Autocomplete" tab in a settings modal.
throwaway290 2y ago
As an apple fan, Music is disgusting on every platform. It is possible to be technically native but also very bad. For a text editor it is also true but where entry speed matters being a web based monster like VS studio is a downside. You may not notice delay consciously but it takes its toll
- Doctor_Fegg 2y ago
  “It is possible to be technically native but also very bad” and yet still 100x better than iTunes.
  - renewedrebecca 2y ago
    It seems like it would be so easy to not suck though. I think a lot of the problems stem from the Music app really wanting to be a streaming app, and not a way to organize your own music.
ubermonkey 2y ago
Brent Simmons used the term "Mac-assed Mac app" for apps that are un-apologetically MAC apps, and not just x-platform builds of something else with no regard for the OS. https://daringfireball.net/linked/2020/03/20/mac-assed-mac-apps https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
isametry 2y ago
First, I wish there was a resource but there isn't. This kind of just lives on as bits of folklore among users and devs. You'd think Apple's guidelines was a place to start, but honestly not really. The sibling comments gave some great answers and especially `crazygringo` summarized pretty much exactly what I was gonna say, so I'm not gonna go into detail. But I just wanna add: "Mac-assedness" totally includes of some strict, non-negotiable rules, but it also involves lots of loose, abstract "vibes" where even if your app isn't exactly guideline on paper, it just feels right in spirit and paradoxically, by being more custom, the app comes out more native in the end. This takes a certain personal taste to pull off as a developer. And it is the opposite of design by committee.
wpm 2y ago
"One would also expect Applescript / Automator (Apple's built-in macro tool, a-la AutoHotkey / xdotool) to work with native apps, but it doesn't work on ARM Macbooks." This is completely false, I use Automator, Applescript, and Folder Actions near daily on my Apple Silicon Macs.
- lynndotpy 2y ago
  I have my Automations and Applescripts fail regularly, and I saw it discussed as one of the things Apple stopped maintaining after the move to ARM. In my experience, it doesn't work. (Of course, I can't compare to how well it worked on x86...)
  - nozzlegear 2y ago
    I think you might want to double check that. I only moved to macOS after the M1 launched, and all of my automations and AppleScripts work just fine with no issues.
maratc 2y ago
Excellent points above, for me personally the "Shared Find pasteboard" has been a huge productivity boost. Everyone's aware of the normal clipboard: select some text, press ^C (⌘C on Mac) to copy and ^V (⌘V on Mac) to paste it. It's system-wide, so you can copy in one app and paste in a different one (or several). On Mac, there is a similar pasteboard (or "clipboard") for search strings. Select text, select "Use Selection for Find" or press ⌘E (this sends it into shared find pasteboard, overwriting its contents), and ⌘G to "Find Next" occurrence of that string, or ⇧⌘G to "Find Previous". The shared find pasteboard is also system-wide, you can use ⌘E in one app and ⌘G/⇧⌘G in another app. When you use ⌘F to "Find ...", it is expected to already open up populated with the contents of the shared find pasteboard. The majority of the cross-platform apps are lacking this feature, since they are designed to a lowest common denominator (which does not have the shared find pasteboard). On VS Code you'd find yourself doing ^C/^F/^V followed by several "Enter" keys, while overwriting whatever you've had on your clipboard and also polluting your clipboard history. I hope all that explains how I'm stuck with iTerm2, Safari, Mail, and TextMate. I'd pay for a native Slack client (the Electron abomination uses ⌘F to "Find" and ⌘G to "Search" while lacking ⌘E completely) but sadly they don't make it.

adolph 2y ago

> For example, Apple's Music app is surely "native", but does not appear to use the DEs default elements, and performs like an electron app might. For the grey beards of MacOS: This guy trashes the HIG [Apple Human Interface Guide] the way Johnny Depp trashes a hotel room. He even sports a custom radius on his window corners. No other window on the system has a shape like this. It’s wild. Just wait until the HIG zealots get a load of this guy. https://daringfireball.net/2005/09/anthropomorphized https://daringfireball.net/2005/09/anthropomorphized

joshstrange 2y ago

Apple that follow the HIG [0] closely are normally considered "mac native" (though I don't like the word "native" here as I normally use it to differentiate between electron/native). [0] https://developer.apple.com/design/human-interface-guidelines https://developer.apple.com/design/human-interface-guideline...

crazygringo 2y ago

> what makes a MacOS app "native"? For me, it has three parts: 1) Does it look native at a pixel level? In other words, does it use a standard Mac window and title bar and buttons and widgets and all the rest? 2) Is it organized according to Mac UX conventions? Does it put commands in the menu bar rather than inside of windows? Are menu items where you'd expect? Is the "Settings..." command where you'd expect, and is the Settings dialog laid out in standard tabs or icons across the top, rather than something else (like a list box on the left)? 3) Does it respect all standard gestures and shortcuts and animations? If I press opt+left in a textbox, will the cursor jump to the previous word? If I press cmd+right, will it jump to the end of the text? If I scroll down, will it bounce at the bottom? That's what it means. And it's desirable for 1) aesthetics, 2) understandability, and 3) usability directly corresponding to those three points. Aesthetics is less important but it's still nice. Understandability is important because I don't want to hunt for a command when it's not where I'd expect. And usability is critical because when I cmd+right in a text box and it doesn't work, it's incredibly frustrating. Obviously, "native" is not a binary but is rather a continuum. And yes, even Apple's own apps are not always 100% at the "native" end, especially with stuff they've designed in conjunction with iOS. Which I think a lot of Mac users find frustrating.

isametry 2y ago
Greatly put, thank you so much. We should put this up somewhere as the Mac-assed manifesto. But I would actually add, on a more fundamental level: 0) Does it actually run on my metal? I.e. not in a VM, not any sort of "thin client", and CERTAINLY not Electron… but rather an actual solid piece of software compiled for the computer it's running on? You say "native is not a binary" but actually, in my opinion yes, it is also very much the binary!
wpm 2y ago
"is the Settings dialog laid out in standard tabs or icons across the top, rather than something else (like a list box on the left)?" Or worse, a huge plain old JSON with tons of multi line comments explaining what one particular key does. Like, I get it, its l33t and haxx0r to use a text file for settings, and yeah, you can easily transfer it to other platforms unlike an XML Plist file, but I despise apps that don't even bother providing a basic UI for changing settings. Ctrl+F "autocomplete" (30 results) is a *terrible* experience vs a natively drawn "Autocomplete" tab in a settings modal.

throwaway290 2y ago

As an apple fan, Music is disgusting on every platform. It is possible to be technically native but also very bad. For a text editor it is also true but where entry speed matters being a web based monster like VS studio is a downside. You may not notice delay consciously but it takes its toll

Doctor_Fegg 2y ago
“It is possible to be technically native but also very bad” and yet still 100x better than iTunes.
- renewedrebecca 2y ago
  It seems like it would be so easy to not suck though. I think a lot of the problems stem from the Music app really wanting to be a streaming app, and not a way to organize your own music.

ubermonkey 2y ago

Brent Simmons used the term "Mac-assed Mac app" for apps that are un-apologetically MAC apps, and not just x-platform builds of something else with no regard for the OS. https://daringfireball.net/linked/2020/03/20/mac-assed-mac-apps https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...

isametry 2y ago

First, I wish there was a resource but there isn't. This kind of just lives on as bits of folklore among users and devs. You'd think Apple's guidelines was a place to start, but honestly not really. The sibling comments gave some great answers and especially `crazygringo` summarized pretty much exactly what I was gonna say, so I'm not gonna go into detail. But I just wanna add: "Mac-assedness" totally includes of some strict, non-negotiable rules, but it also involves lots of loose, abstract "vibes" where even if your app isn't exactly guideline on paper, it just feels right in spirit and paradoxically, by being more custom, the app comes out more native in the end. This takes a certain personal taste to pull off as a developer. And it is the opposite of design by committee.

wpm 2y ago

"One would also expect Applescript / Automator (Apple's built-in macro tool, a-la AutoHotkey / xdotool) to work with native apps, but it doesn't work on ARM Macbooks." This is completely false, I use Automator, Applescript, and Folder Actions near daily on my Apple Silicon Macs.

lynndotpy 2y ago
I have my Automations and Applescripts fail regularly, and I saw it discussed as one of the things Apple stopped maintaining after the move to ARM. In my experience, it doesn't work. (Of course, I can't compare to how well it worked on x86...)
- nozzlegear 2y ago
  I think you might want to double check that. I only moved to macOS after the M1 launched, and all of my automations and AppleScripts work just fine with no issues.

maratc 2y ago

Excellent points above, for me personally the "Shared Find pasteboard" has been a huge productivity boost. Everyone's aware of the normal clipboard: select some text, press ^C (⌘C on Mac) to copy and ^V (⌘V on Mac) to paste it. It's system-wide, so you can copy in one app and paste in a different one (or several). On Mac, there is a similar pasteboard (or "clipboard") for search strings. Select text, select "Use Selection for Find" or press ⌘E (this sends it into shared find pasteboard, overwriting its contents), and ⌘G to "Find Next" occurrence of that string, or ⇧⌘G to "Find Previous". The shared find pasteboard is also system-wide, you can use ⌘E in one app and ⌘G/⇧⌘G in another app. When you use ⌘F to "Find ...", it is expected to already open up populated with the contents of the shared find pasteboard. The majority of the cross-platform apps are lacking this feature, since they are designed to a lowest common denominator (which does not have the shared find pasteboard). On VS Code you'd find yourself doing ^C/^F/^V followed by several "Enter" keys, while overwriting whatever you've had on your clipboard and also polluting your clipboard history. I hope all that explains how I'm stuck with iTerm2, Safari, Mail, and TextMate. I'd pay for a native Slack client (the Electron abomination uses ⌘F to "Find" and ⌘G to "Search" while lacking ⌘E completely) but sadly they don't make it.