[tshaddox]

I totally agree with that, but couldn't the favicons still support the same browser caching mechanisms as the HTML document? If I can refresh the page and get a new HTML response, surely I should at the same time get a new favicon if a new one exists.

[hunter2_]

Most people probably wouldn't want to refresh an SPA like Gmail every time the favicon isn't showing the correct unread count. But for infrequent rebranding, I agree with you.

[tshaddox]

Yes, I'm not trying to address the feature of having animated favicons or favicons set dynamically using JS. I'm just trying to address the problem of favicons apparently being very stale. My question is why Apple couldn't fix that problem, which is not at odds with Apple's stance against animated or dynamic favicons.

[floatingatoll]

That would allow websites to override Apple's objection, and therefore they can't allow it, even if it will cause occasional problems for websites that think they can do a total branding pivot including favicon overnight.

[tshaddox]

Why is that related to Apple's object to animated favicons or favicons that are set dynamically by JavaScript?

[floatingatoll]

If Safari didn’t aggressively cache favicons, websites trying to overcome Apple’s objection would immediately start trying to use window.reload() and server-side dynamically generating favicon paths, for random “I made this up before coffee” example, which would burn more battery power on Apple devices for endless page reload events. Caching aggressively makes it a non-starter to try and engineer workarounds, and comes at zero impact to users (who are either accustomed to the old favicon and don’t care about rebranding, or ignoring it).