Yes. I have used every way to consume the web since text-only was preferred in early lynx days and finding gopher resources was the norm. NSCA Mosaic, Netscape Navigator, all IE versions, Firefox, Chrome when it first appeared. I want nothing more to only use Safari / OS WebKit on all my devices. If this winds up going through, I will actively delete all applications that switch off WebKit. To each their own...
No they aren't. There's no central webkitd or anything like that. WebKit is a framework, not a background daemon. If you quit all apps that use WebKit, then no associated processes will exist anymore. If you look in Activity Monitor all the web content processes are parented to launchd(1), but if you ask launchd about it, it'll tell you that the "responsible pid" for each web content process is the WebKit-enabled application that spawned it. And if you quit the application, all the associated web content processes shut down.
So, quit all of the WebKit apps and then check to see if WebKit libraries are still loaded. I posted instructions further down the thread, it's not hard to see for yourself.
If I quit all WebKit apps then by definition I've quit everything that loads the libraries.
You also seem to be very confused as to the difference between a library and a process, given what you've been saying. Having a bunch of apps using WebKit as a framework does not confer any kind of advantage on these apps. If I have an app using WebKit, and you have an app using WebKit, they don't affect each other in the slightest. The only way they would is if they were reusing shared web content processes and so didn't have to wait for those to launch, except a) I imagine launching a web content process is pretty quick, and b) they don't share web content processes so it doesn't matter.
So, do it. See what happens; WebKit is still loaded via MacOS because it's used to render UI elements that are considered part of the system. Unless you've modified the way default apps run on MacOS, WebKit should be loaded into memory from the moment you boot MacOS to the moment you shut it down.
The overhead of mapping the files on disk into memory is pretty minimal. The framework still has to be initialized anew for every application. About the only benefit I can think of is WebKit might be in the dyld shared cache (assuming that includes frameworks that can be updated independently of the system), and that just means it would bypass some of the dyld setup, but if so that would just have a minor effect on the launch time of the application.
Also if I actually do that right now I see a bunch of WebContent processes, the apps themselves and then there are a handful of daemons that have InfoPlist.strings open from WebKit (from the iOSSupport subsystem) but that's just a localization file and I don't know what it's doing there but it appears to be completely irrelevant (the daemons do not have anything else from WebKit loaded).
AFAIK macOS does not use WebKit to render UI. iOS has been known to use WebKit for text rendering in the past, but I'm not sure if it even still does that, and that was presumably in-process anyway. And even if it did that still wouldn't matter as far as applications' own use of web rendering engines is concerned.
Those aren't the OS, those are individual apps that have chosen to use a web rendering engine for various content, and it's not even correct. Calendar doesn't use WebKit at all and never has. Mail.app uses it to render external HTML input (i.e. email messages) rather than UI. I believe Music.app moved off WebKit some time ago as well, and it looks like App Store did too (Accessibility Inspector confirms that the Updates page, which used to be rendered with WebKit, is now a collection view). Both Music.app and App Store link against WebKit but that's likely because the Account Settings page is rendered with WebKit (this is likely content that is served remotely).
In any case, the OS itself does not rely on WebKit for UI, it just ships some apps that use WebKit.
The speed with which it launches isn't what anyone here means when they claim Safari is more efficient. They mean it's far more power-efficient and doesn't harm responsiveness and performance consistency on the rest of your system (i.e. programs that aren't the browser) as much as Chrome or FF do.
> and gets it's always-on processes reused by the browser when you launch it
Which is a moot point on macOS, since you hardly ever close the browser application. You just close the windows and the application stays activated in the Dock.
I found this held on a weak Chromebox I'd stuck Void on a while back, too. Dual-core Celeron, no hyperthreading, 2GB memory. Webkit-based browsers were the only ones that approached usability on that device.
You're correct, but the assumption that MacOS reuses system resources to run Safari still stands. It's not necessarily bad, it's just what the earlier comment suggested.
On iOS, Cocoa uses WebKit to render text, and everything UIKit-based on MacOS gets rendered with dynamically-linked WebKit as well. It's safe to say that if your Mac is on, WebKit is probably running.
And like everyone has said that would only affect startup time. Safari does absolutely blow away Chrome at startup time, but it also is more performant in basically every other way: battery, memory, runtime, window resize, tab open/close/re-open, forward/back, paint, layout...
The UI also is more minimal making well built sites feel much more native than Chrome (on Mac and iOS), especially combined with all the performance.
How does this prove that Safari gets an inherent performance advantage over Chrome? I guess on startup there could be a slight difference if the library is already loaded in memory.
