On macOS the situation is interesting because there is a sort of an “in-between” later that doesn’t really seem to exist on other platforms, which is cells. Usually you either have a control or you have a drawing primitive and you get nothing in between, but on macOS you have a class that encapsulates the drawing portion of a control and you can hook up your own event system on top of it. Safari has it a little bit more complicated than this because it needs to handle basically every possible abuse of NSButtonCell before it falls back to something completely custom; Mac apps typically don’t style their buttons in a dozen different ways. Safari can’t actually use NSButton because such a class obviously can’t be hooked up to the DOM: it wouldn’t be worth it. But if Safari actually included a full reimplementation of NSButton, it would be significantly more complicated than what we see here. It is still relying on a lot of NSButtonCell functionality, which as you mention is just drawing but includes behaviors like highlights and sizing and animation which people who actually do try to reimplement have historically done poorly. (Actually, to be completely honest, Safari actually does break a couple of things as it tries to disable built-in behaviors. But this is coming at it from the opposite direction from usual.) I know it isn’t sending NSEvents around but it “feels native” and works with the web: it looks, acts, and even updates like a button but makes an event in the web page, which is I think the best anyone can do. (FWIW, iTunes does its own thing too, and it’s native as well. It’s just
bad native.) At some point, when they’re using a significant portion of the platform’s native control and are working hard to hook it up to something which isn’t what it usually is connected to, to the point where people who generally have complaints about “non-native UIs” (hello) sit back and say “actually this is not too terrible” I think you have to give it to them.
Edit: I thought more about it and I think I was misunderstanding where this conversation was going. I do care very much about native controls being more than looking native. The thing is that in the web really the only thing exposed is how the control looks because all the platform behaviors have to be stripped out: for example, on one OS a native control with the word “OK” inside of it may be implicitly activatable via the pressing enter on the keyboard, but such an interaction is undesirable on the web because a button should have the lowest common denominator of behaviors. There really is no room for much more than the actual UI of a control to show platform conventions and so when I call things native in this context I mean that they are native as they can be used in a webpage. Plus more complex interactions, which is often where such “native” frameworks go wrong, are just not a thing on the web so I am using ignoring them while you are not.