What are the advantages of this over Visual Studio Code or JetBrain’s Tools?
I'm sure VSCode and others can be configured or extended to come close to the experience, but 100$ for something well-made that fits your workflow out of the box is a pretty great deal for a professional.
You personally list this particular (mis)behavior as a "plus" since you like the PC convention better. But another person will think the opposite. Objectively, it's simply just inconsistent.
What we need is "good platform citizen" apps which respect the local conventions, and you as the user get to choose the platform with its set of conventions you prefer.
What we DON'T need is apps "unifying" behavior across operating systems based on their own opinion of what's better, ultimately just creating more mess.
Many of us on the Mac are there in part because the environment and conventions make more sense to us than the conventions on other platforms. X-platform apps typically ignore this.
See also
https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
However for keyboard shortcuts said conventions are defined for crippled keyboards without dedicated navigation keys and the extension for PgUp/Down is simply inefficient when programming.
Up / Down: move cursor one line up or down Left / Right: move cursor one character left or right
Option+ Up / Down: Move cursor up or down a whole paragraph Left / Right: move cursor left or right a whole word
Command+ Up / Down: Move cursor to the beginning of the document Left / Right: Move cursor to the beginning or end of the document
Page Up / Page Down: Move the scrolled display area up or down a "page" without moving the cursor
Home / End: Move the scrolled display area to the beginning or end of the document
The latter two are nice to have because it means you can scroll up through a window to view something, and start typing to have your view snap back to your cursor position.
I don't think they ever had PgUp and PgDown. Same thin/small fetish as today. Jobs wasn't typing much, I think.
Apple Extended Keyboard M0115 (1987): https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard_M...
Apple Extended Keyboard II M0312/M3501 (1990): https://en.wikipedia.org/wiki/File:Apple_Extended_Keyboard.j...
Apple Adjustable Keyboard M1242 (1993): https://en.wikipedia.org/wiki/File:Apple_Adjustable_Keyboard...
Apple Design Keyboard M2980 (1994): https://en.wikipedia.org/wiki/File:AppleDesign_Keyboard_blac...
Apple USB Keyboard M2453 (1998) (not in their usual position, above the number pad instead): https://en.wikipedia.org/wiki/File:Apple_USB_Keyboard_B.jpg / https://deskthority.net/wiki/Apple_USB_Keyboard
Apple Pro Keyboard M7803 (2000): https://en.wikipedia.org/wiki/File:Apple_Pro_Keyboard_black....
Apple Keyboard A1048 (2003): https://en.wikipedia.org/wiki/File:Apple_Keyboard_(A1048).jp...
Apple Keyboard A1243 (2007): https://en.wikipedia.org/wiki/File:Apple_iMac_Keyboard_A1243...
Apple Magic Keyboard w/ Numeric Keypad A1843 (2017): https://en.wikipedia.org/wiki/File:Apple_Magic_Keyboard_with...
Additionally at least as far back as the Powerbook G3 "Wallstreet" in 1998, and including the iBook lines from the same time period, to the best of my knowledge every Apple portable since (as well as any wireless/compact keyboards with Fn keys) then has supported Fn + Left/Right for Home/End respectively and Fn + Up/Down for Page Up / Page Down respectively. They were even marked as such through the early non-unibody MBPs but continue to function that way today even without the markings. While these aren't dedicated keys, they're convenient enough in combination with the other modifiers that you'd be using to move the cursor that I don't personally consider it a significant difference.
Answer 2: I bought a general purpose computing device and I don’t need the manufacturer to dictate how I use it.
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?
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.
[0] https://developer.apple.com/design/human-interface-guideline...
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.
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!
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.
https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
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.
This is completely false, I use Automator, Applescript, and Folder Actions near daily on my Apple Silicon Macs.
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.
I’m paying for jetbrains now. I’m on Linux but it’s clearly a non-native application, which has some issues. Actually it integrates really well considering. I can run in any os and it’s the same. I tried eclipse (free), but the experience wasnt good and it was worth buying jetbrains software. This probably has a quite polished experience.
Panic also made transmit, which was my goto file transfer solution for a long time and a really decent piece of software.
I don't know if I would use Nova to actually develop anything more serious. Haven't looked to deep into it and I like my devtools to be opensource or at least have the feeling of them being maintained for very long. (Text editors tend to die very often).
Nope. I use Rider on Mac and Windows and it's better than Visual Studio on Windows in almost every way it's different. I've used Pycharm and Datagrip extensively on Mac and Windows as well, they're excellent tools. I haven't used Webstorm much though.
For auch a “heavy” IDE it’s also surprisingly responsive.