Which processes ? It's not like there is a webkitd and everything is done via RPC.

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.

There is a big difference between a dynamically-linked WebKit and a constantly running process.

I am on a Mac right now. What is the name of the WebKit process ?

Run this:

`lsof | grep webkit`

You'll need to run that as the user handling WebKit processes, so sudo might be required.

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.

No process there (Ventura, ran with sudo).

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) making sites feel much more native in practice, especially combined with all the performance.

Chrome feels like a dinosaur.

Safari feels like how Chrome felt 10 years ago :p

  > On iOS, Cocoa uses WebKit to render text, and everything UIKit-based on MacOS

you are saying that nstextview and friends are rendered with webkit?

They have no idea what they’re talking about, just move on.

Literally everything in this comment is wrong.

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.

Processes? No.

Various parts of MacOS use the WebKit libraries for rendering, but that's a library, not processes.

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.

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.

> AFAIK macOS does not use WebKit to render UI

Sure it does: iCal, Mail.app, iTunes (Music app), App Store, etc.

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.

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

macOS WebKit browsers that ship their own custom build of WebKit rather than using the system version (like Orion) are just as efficient as Safari is.

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.