I choose it every single day. I have chrome, Firefox, edge and safari at my disposal. Safari is my day to day for most regular usage. For tech/dev work, Firefox and Chrome are usually in flight at the same time.

Why do you chose safari?

Battery life, keychain, PIN numbers from iMessage, integration between desktop/mobile, it's not supported by ads/Google...

Keychain is a big one for me. In the past, Chrome used to support Keychain for their passwords, which meant I could sync all my secrets on any browser on any of my devices.

Why did Chrome stop supporting it? Seeing that they support more obscure keychain apps like whatever ships with KDE and Gnome, I suspect that it was not due to a lack in resources.

> PIN numbers from iMessage

This isn't actually a Safari feature but an iOS feature AFAIK.

I'm like 99% sure this works on desktop, too, if you've got iMessage configured.

It does.

It's an OS-level keyboard feature on iOS, but on macOS I think it's only part of Safari.

I don't really use Safari (for the sole reason called uBlock Origin), but something really nice is that Look Up displays a scrollable preview of pages/links.

I really miss that since it greatly reduced the amount of tabs I opened.

It's fast, good with memory, and does everything I need from it.

Doesn't seriously harm performance of the rest of my system the way a many-tabs Chrome or Firefox tends to.

Fast, best battery life, better UI, the tab groups implementation is great. I like the approach to the extension store better.

mostly what others said already. for most day to day stuff, iCloud sync and whatnot is decent and works across devices. safari dev tools are... horrid imo, so chrome/ff for dev work, but general browsing, it's great.

I choose Safari because it's the default, and as a user I can no longer really tell the difference between the major browsers. Gone are the days when I'd even think about downloading a different browser when I set up a computer. On Macs I use Safari, on Windows I use Edge. I don't see the benefit of going out of my way to install a different browser.

I'm actually continually shocked at Chrome's market share. Is there any PC or laptop platform, besides Chromebooks, that ships Chrome as the default browser? Why is it that so many people took time out of their day to go download a different browser in 2022?

Google is promoting Chrome left and right, and most users use at least Google Search, so are constantly exposed to the marketing.

And most computer-savvy people who support less computer-savvy people “helpfully” install Chrome for them, because “everyone knows” it’s the best browser.

On Windows, it also doesn’t help that Edge has the negative image of being associated with Microsoft telemetry, while Google still benefits from its former “don’t be evil” image.

The "peeking" you can do with the trackpad on a Mac when navigating backwards and forwards between pages is a must have for me in a browser. It's so nice in Safari, I use it hundreds of times a day. It's painful for me when I use other browsers that don't have this feature.

I do this with my Magic Trackpad on Linux as well, it's very nice.

Wait, how are you getting that on Linux?

If you're running Firefox with native Wayland support, multitouch trackpad gestures are working now.

Edit: I also found a Chrome extension that adds it: https://chrome.google.com/webstore/detail/swipe-back/mkkcgaj...

Similarly, the "peeking" you can do with Look Up on URLs.

> When is the last time you said "I will choose to use safari"

The last time I opened a Mac with a battery (i.e., today).

Every day since it was first released. I left FF for it and never looked back.

FF has massively improved since then, but Safari is my habit and I’m very happy with it.

I exclusively use Safari for better battery life and I trust their security more and anticipate I will be using Keychain for a long time.

You should probably read the security section of any iOS release notes sometime. Great at security isn’t the first thing that comes to mind for me.

Here’s the latest one for example: https://support.apple.com/en-gb/HT213530

So fixing security issues is ... bad?

FFS… nobody said that. Nobody even implied that.

If Chrome can update itself in the App Store without a reboot like it does on Android, and Safari continues to require an OS update, Safari security will continue to be worse.

Rapid Security Response should fix that.

iOS release notes combine the OS, apps, and dependent libraries. If you compare to Chrome or Firefox on Windows or Android it's pretty hard to say that anyone has this solved other than to the extent that they're migrating to memory-safe languages. I think Chrome is a ahead on proactive mitigations but from a user's perspective it's basically a never-ending race to install updates since they all have high CVEs on a regular basis.

Many Mac users choose to use Safari because it is by far the most efficient browser.

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

I'm very skeptical this is due to safari and not Microsoft style monopolistic behavior by baking the browser into the OS so it's always loaded.

No it's simply due to priorities.

Apple has always placed privacy and efficiency over new features.

...but part of it is also that WebKit is baked-in to MacOS, and gets it's always-on processes reused by the browser when you launch it.

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.

macOS does very little to favor Safari. It provides identical resistance to changing defaults to Safari as it does changing defaults from Safari.

I literally don't have Chrome on my Mac. Safari is faster and has less Google shoving their random product initiatives to me. I never have to log into Safari to do anything.

At some point the battery usage on laptop was considerably better using safari. That’s a plus.

Battery life on my Macbook is better using Safari, so I choose to use it all the time. They've also been pulling ahead of Firefox on several occasions when implementing new CSS features.

precisely. and we see a lot of similar behavior from Chrome now as it helps them replace the good old search form with a url bar as the main driver of their ad dollars.

this unsolvable battle is exactly why I opted for the Brave [1] browser. all the better if they’re able to use alternate engine under the hood next.

[1] https://brave.com/

I choose safari every day. It uses less power and it's an overall smoother and better integrated experience. It's also not constantly hounding me to sign into Google accounts.

"Pushing the bounds of the web" specifically isn't a huge goal for me, I want to see the bounds of computing pushed. That doesn't have to be on the web. The web is Rube Golberg-esque enough as is. [edit] To be clear I'm not opposed to it, I'm neutral to it.

I choose Safari as my primary browser on my personal MacBook, it's great

Lifetime windows user, just got a MacBook. I heard safari was better for battery life (haven't tested so can't confirm) so I thought I'd try it. It works fine for all my needs so why change?

Side note, last pass on Mac is a pile of hot garbage. I wish I had never gotten my family onto it because switching is going to be a hassle.

Multiple implementations help the web be diverse, and there is a long history of features becoming easier to use, more capable, or secure based on feedback from one of the browser teams other than the first to propose something.

It’s also not the case that any current browser is so bad that the web is better off without it. Anyone with web development experience has run into problems or limitations with every browser and depending on what you do you will have different assessments of which one is best at a given time. For example, on the Interop 2022 effort all three browser teams have been coordinating currently Safari is in the lead and that will continue to shift over time.

https://wpt.fyi/interop-2022

> When is the last time you said "I will choose to use safari" or seen apple pushing the bounds of what the web can do?

Firefox and Safari are both noticeably faster and use less memory. If you care about that, or work on battery that’s enough right there.

Firefox and Safari don’t have conflicts of interest preventing privacy improvements or ad blocking.

I haven’t used Chrome as my default browser since Firefox took the performance crown ~5 years ago but I’ve used all of them plenty as a web developer. The idea that Chrome is so far ahead that we should give up on the web having multiple implementations and just let Google run it is completely the opposite of my experience.

> It’s also not the case that any current browser is so bad that the web is better off without it.

But it is. Safari on IOS is either missing or badly implements every system that lets web apps compete with system apps.

It's totally impossible to use something other than safari on IOS as well, which basically means apple is able to force a very significant amount of web traffic into their browser and basically lock out any feature the choose.

That is bad for the web.

Additionally, I think you're mistaken on the performance crown. Firefox made big gains years ago but chrome has always managed to perform better at most tasks despite those gains.

Maybe if you were running really low on ram Firefox is the faster option? That's not your typical use case though.

I use Firefox regardless. I way value their not crippling AdBlock over chrome and would encourage everyone to use it despite speed issues.

Can you be specific about what exact features you think are so critical that the web would be better off without Safari? For example, if you've already retracted the claim down to “letting iOS users use PWAs which use more app-like features” it's clearly not true because most people do not use PWAs at all, even on Android, and there are many PWAs which work just fine.

> Additionally, I think you're mistaken on the performance crown. Firefox made big gains years ago but chrome has always managed to perform better at most tasks despite those gains.

This always comes down to which specific things you benchmark. All I can say is that I use Chrome, Edge, Firefox, and Safari on macOS, iOS, and Windows and it's exceedingly uncommon for Chrome/Edge to feel faster but I do notice their memory impact on the rest of the system. For battery life, Safari is hands down the winner followed by Firefox and then, distantly, the Chromium browsers.

So which specific features are that critical — for example, do you think most app developers can't work without the battery status API (or that users don't have a vested privacy concern)? I ask because when you drill into things like that there are a lot of numbers which look big until you realize that there are something like 57 tests for a non-standard API which is not broadly used even on the browsers which do support it.

Every feature has the potential to jump out and be critical, even ones that don't appear to be.

Every time I try to use Safari to create something that goes beyond "display text" it's a new adventure in bugs and unsupported features that work in the other browsers.

It's not one of those things you can sit and name, it's a 90/10 issue, and the margins are critical even though they appear small.

Bugs surrounding drag and drop is what lead me to abandon all hope of supporting the browser some months ago.

> Every time I try to use Safari to create something that goes beyond "display text" it's a new adventure in bugs and unsupported features that work in the other browsers.

Do you have any examples which aren't so vague? The only times I've encountered this problem with other developers has been when they were using lots of Chrome-only features and put off testing in other browsers; when starting development in Firefox or Safari the most common case since around the early 2000s has been that everything works in the other two browsers with minimal effort.

> Every time I try to use Safari to create something that goes beyond "display text" it's a new adventure in bugs and unsupported features that work in the other browsers.

Being hyperbolic doesn't help your case; it just looks like you're bashing WebKit because it's from Apple. And while you may have had a bad experience back in the day or don't like that Apple chooses not to implement esoteric or Chrome-only features, that doesn't mean that Safari sucks now.

As I pointed out earlier in the thread [1], Apple has done a great job lately implementing features that they, Google, Mozilla and Microsoft have agreed should be implemented and interoperable and have W3C/WHATWG specifications.

Every browser has bugs; the bug trackers for WebKit, Mozilla and Google are public, so we can actually see what they are.

Like the other browser makers, Apple publishes its bug fixes when a new version of WebKit is released.

[1]: https://news.ycombinator.com/item?id=33991256

I'm not being hyperbolic, I'm being quite literal. I tried two or three times to support Safari. I gave up on it and I'm never going back.

Not bashing web kit because it's from Apple, I'm bashing web kit because I had a website, I wanted to make that website support safari, and it was an absolute pain to the degree that I gave up on it.

The only other browser I've had experiences like this in has been Firefox mobile. I have similar feelings about Firefox mobile.

On the desktop, technically maybe Safari is fine on the desktop because I don't own a Mac so I can't test it, but chrome and Firefox are perfectly easy to make work together on the web with no issues. I do it everyday, safari is not normal in this.

The reason you’re getting negative reactions is because you made these huge sweeping generalizations which are untrue for most web developers but despite being so vehement they’re also entirely unverifiable. It’s certainly possible there’s some feature you hit which was buggy but despite hundreds of words we still have no idea where the alleged problem was – JavaScript, DOM, CSS, audio/video, Unicode support or text rendering, who knows?

> I'm not being hyperbolic, I'm being quite literal. I tried two or three times to support Safari. I gave up on it and I'm never going back.

There's nothing special that has to be done to "support Safari" other than writing normal CSS, HTML and JavaScript just like for any other browser.

Even if you used something experimental or Chrome-only, there are polyfills [2] for most features. This only makes sense for a public facing website (e-commerce, for example), since Safari is on over a billion devices and some of those potential customers might want to use your site.

> maybe Safari is fine on the desktop because I don't own a Mac so I can't test it

Other than some minor differences, the latest version of WebKit is essentially the same on iOS, macOS and iPadOS.

It's pretty common to use something like CodePen [1] to demonstrate CSS and HTML features publicly.

[1]: https://codepen.io/

iOS Safari locking out features is not inherently good or bad.

Yes, it holds back further adoption of cutting edge features that some developers would like but that the average person doesn't care about.

However, it also holds back features that would increase the scope of what the web is, including more features that allow bad faith operators to track and monetize our data.

I use Safari and another WebKit-based browser (Orion) on macOS and iOS/iPadOS all the time, because neither Chrome or Firefox compares when it comes to battery consumption or feeling like a proper citizen of the OS it's running on.

It's seriously frustrating how little regard is given to efficiency in both Blink and Gecko. It don't care if the engine supports WebBanana 2.0 if it's destroying battery life.

But you are running WebKit in all four on iOS :) Because right now Apple doesn't allow other engines. So whatever it is that consumes batter, it's not blink or gecko.

My points of comparison are the macOS versions, where the difference is staggering. Architecturally macOS and iOS are very similar and it’s traditionally been quite rare for either engine’s team to focus squarely on improving efficiency (it’s always speed or features instead, with efficiency as a trailing afterthought), so there’s no reason to think that Blink and Gecko for iOS will be any more efficient than their macOS counterparts.

Is "pushing the bounds of what the web can do" something we should value? Given the current direction of the web, a preference for Safari's relatively slow feature rollouts seems reasonable.

> Is "pushing the bounds of what the web can do" something we should value?

Given that the alternative are app stores controlled by the device vendor, yes. Either we free our devices so that custom software is acceptable and common again or we make sure the web is the go to platform for everything.

Okay, so why should we value the web as the "go to" platform instead of applications? We can do this until the cows go home.

You are making claims about values here, and not everyone shares your values.

You can "do this until the cows go home", but that's about as valuable as repeating "why" every time someone answers a question.

People generally value being able to do more stuff. Putting control into the hands of large central parties generally does not go well.

Because you’re not answering the questions.

You’re providing tautological responses.

You’ve been asked specific things about what features are missing from Safari / WebKit. You’ve replied with vague generalizations that don’t hold to be true outside of the echo chamber of the Chrome Reality Distortion Field.

> Putting control into the hands of large central parties generally does not go well.

Then why are you are in favor of a Chrome monopoly (the obvious externality here)?

I don’t want to ever give websites access to USB, MIDI, or anything else like that.

I’m unhappy that Apple implemented web notifications, personally. So much easier to never have to think about that garbage.

Let's do the former.

> When is the last time you said "I will choose to use safari"

Every single time I need a browser. On iPhone, iPad and MacBook.

All reasons have been mentioned already, so will not repeat them here.

> or seen apple pushing the bounds of what the web can do?

I get that it's easy to attack Apple these days but anyone paying attention can objectively see that Safari has been kicking ass this year. It's easy to do the "whataboutism" thing and they're late on a few things… but if this is a sign of things to come for Safari (style queries and masonry grids are in the works, for example), this is a Good Thing for the web and should be treated as such.

* first to implement (March) the most anticipated CSS feature that was thought to be impossible to implement for most of the past 20 years, the :has() parent selector [1]. It took Chrome until the end of August and it's still not enabled by default in Firefox because bugs

* first to implement wide-gamut color support [1a](2020)

* first to implement oklch and oklab (and a bunch more) color spaces [2]

* first to implement the open Webauthn standard Passkeys a few months ago; Chrome 108 just announced support

* support for all of the "hot" CSS features like Container Queries, Subgrid, new viewport units, AVIF image format and (as they say) "more" [3]

* Mozilla, Google, Apple and Microsoft agreed to focus on the interoperability of 15 web features; WebKit currently passes 98.5% of the tests the companies have agreed to, leading the other companies [4].

[1]: https://webkit.org/blog/13096/css-has-pseudo-class/

[1a]: https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...

[2]: https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...

[3]: https://webkit.org/blog/13152/webkit-features-in-safari-16-0...

[4]: https://webkit.org/blog/13591/webkit-features-in-safari-16-2...