"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15"
- Sites that try to detect mobile by looking at "ARM" in user-agent string
- Sites that try to parse the macOS minor version for some reason and would be confused to see something like "11_0"
BTW, user-agent is a hell anyway. Just looking at this user-agent that OP posted, macOS still identifies itself as "Mac OS X", still is based on Mozilla/5.0(!), still identifies itself as KHTML enginee (compatible with Gecko), and so on...
Browser makers tried to do that by providing feature detection, but the weight of legacy code and developers already used to using the user agent strings has made killing it impossible.
Edit: As pointed out in another comment here, it seems like Google is killing it (or planning to). [1]
[1]: https://www.zdnet.com/article/google-to-phase-out-user-agent...
But the many attempts to freeze the existing UA are for the purpose of stopping people testing through the UA
Because it only affect graphic, you can't really detect whether you are affected by it or not from js.
The best thing you can do it guess the browser from user-agent and apply the workaround anyway. Or you can pray for the apple to fix their sh*t (given what they have done in the past, it is unlikely).
This is why we have some more developers spending time on creating FOSS libraries that parse user agent strings and tell you exactly what the browser claims to be, with attributes like browser name, OS, version, browser engine, etc. All these libraries need updates (or at least a cursory look) whenever a new browser version is released so that they can continue identifying browsers correctly. All those people, bless them for this work, could be doing something else in an alternate universe.
Notwithstanding feature detection and graceful downgrades, browser user agent strings seem to be very commonly used to decide the behavior of many websites.
In the vast majority of use cases, these values should not be used to detect platform features - actual feature detection should be used instead.
And "actual feature detection" doesn't work with SSR, like, at all.
The latest iPadOS, for example, purposely reports itself as a Mac desktop because too many sites saw 'MobileSafari' and returned a sub-par site experience based on a small mobile phone screen. But it actually goes beyond that:
1. It lets the user toggle the user agent themselves between mobile and desktop (iPhone and Mac Desktop style agents)
2. The browser will by default use a mobile user agent when rendering in a small form, such as a browser in a smaller modal window or a side-bar.
Client hints might provide a way to actually formalize a contract for SSR apps, if people participate and indicate what they need.
It doesn't make sense to make the choice of what to render on the user agent: for example if it says Android, what does it mean? It is probably a smartphone, but it could also be a tablet, a TV, or even a PC!
An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile, since it usually work one way and thus if you share on a chat the link to the mobile version of the site and the other one opens it on a desktop there is no easy way to get back to the desktop site (most of the times I have to modify the URL!)
> It is probably a smartphone, but it could also be a tablet, a TV, or even a PC!
That's what the "request desktop website" setting is for.
> An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile
Yes, I wholeheartedly agree with you on this one.
Desktop UIs are meant to be compact because mice and trackpads allow nearly pixel-level positioning. Mobile UIs, on the other hand, have to have large elements and ample spacing between them because tapping stuff with your fingers is inherently imprecise. You can't really have both these things at the same time.
Out of websites that are currently live and have good desktop versions, I'd point out HN and reddit (the old design).
And then there's Facebook who has separate mobile and desktop websites but recently chose to redesign its desktop one to look very mobile... I can't imagine the justification behind this one.
I personally prefer (and may well someday need) larger text and UI elements, because my vision and motor skills have gradually declined. I also prefer (and soft-need) lower information density because higher density is a cognitive challenge (ADHD).
Absolutetly this - the number of people sharing m. links for Wikipedia when is just annoying. And there is absolutely no excuse for having different HTML for today's smartphones and Desktops. For text sites like Wikipedia you shouldn't even need media queries or any fancy stuff - just avoid fixed (minimum) widths and use <meta name="viewport" content="width=device-width, initial-scale=1"> to tell broken-by-design mobile browsers that your website is not broken and can be rendered normally instead of in a giant viewport.
Allow me stop you there. The User-Agent string is semantically meaningless.
Everyone does this, which is kinda why we need to get rid of user agents and replace it with feature detection (and css that works everywhere for people who don't want to run Javascript).
Assuming things like that continue to happen, what are web developers supposed to do?
I propose a Real-Agent header that includes browser name and version, os name and version, cpu type (maybe) and desktop/mobile flag (maybe). Or separate headers for each name/version data, I don't care, I just know I need real data sometimes, and some new weird server request pattern isn't going to work well. Then continue to send shakespearean sonnets in user-agent for all I care.
When someone asks me to build I site for them I say, look I will guarantee that the site that I make is compliant with the W3C specification. If there is something that it doesn't work because some browser don't implement the standard correctly, you go to Microsoft to complain, or you install a decent browser like Firefox.
IE 6 had such a history where it held back other browsers and developers were held hostage to it for several years. Now we have Chrome to fill that gap and some Google platforms won’t work well or work the same on Firefox.
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15"
And all three are NextStep.
And Mach.