Apple Mozilla

Apple’s new Mactel’s and UserAgents

Currently UserAgents for the two most popular Mac browsers are as follows:


This visitor used Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412 (KHTML, like Gecko) Safari/412


Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Does anyone out there know if Apple has switched their developer edition Intel Macs to a different UserAgent yet? I presume it’s simply swapping out PPC with i686.

It would be nice if Apple, or someone from the Safari team [collective look toward David Hyatt] would give an official mention. Or will they do like Windows and not say anything?

It would be nice to know early how this is going to be done. It would allow web developers to start updating log analysis software today so it accurately represents those new systems when it ships (and allows developers to see how much of a market there is for Intel based Macs). Not to mention it allows us to make websites that sniff for the processor type and choose what download the user really needs (rather than force a user to download a larger universal binary).

I’ve yet to see any official mention on the Apple website regarding the UserAgent change and proper detection methods for such purposes.

7 replies on “Apple’s new Mactel’s and UserAgents”

Hmm, sniffing for the UA string has never been a very reliable method in my book.

Besides, in your example, what if the user *wants* the universal binary, because he/she will install it in on multiple machines (I downloaded FF 1.0 once, and installed it on 20 or so different Macs).

@Philippe: nobody says you need to force them. sniffs and recommends a download on the home page, but you can still choose which one you want to download. It just makes it easier for someone who doesn’t know the technical side of things and “just wants what they need”.

If you are asking what Apple wants, then they almost certainly want you (and every other developer) to start shipping Universal Binaries regardless of the size. As well as the basic Apple principle of not worrying (or asking the user to worry) about disk space, bandwidth or processer usage right up until its lack becomes a usability issue in itself there is also the fact that Apple will be doing its best to make the dual processors totally transparent to the average end user.

This would suggest that you should automatically offer the Universal Binary to website visitors with Macs and only offer single processor builds (if at all) to those who specifically request them and who can therefore be assumed to know what is going on.

Actually, how much of the download would actually be duplicated in a Universal Binary? I take it all the XUL stuff, images etc. could be shared. Does anyone have the numbers from Apple’s Firefox port?

@dave: the problem with Universal Binaries is the download size. It’s *much* larger. By deciding what the user really needs (rather than give both) there is a serious savings.

Why should the user download a much larger slower download when they only need half of it?

@Laurens Holst: I don’t really like Windows, but don’t ‘hate’ it to much either. My problem with the UA is that it’s the only thing we webmasters have to decide how to deliver content to the user. The user expects things to “just work”. It’s up to us to deliver the right content. If the UA is reliable and consistant, we can do this very well and provide a better experience to the end user.

Nobody likes to decide which download they need from a giant list of cyptic acronyms and technical jargon. That’s why being able to detect what the user needs is important. So we can deliver the best experience with no effort on their part.

Are Apple actually going to be using i686? Given Intel’s and Apple’s roadmaps, I had assumed that they’d be switching to 64-bit Intel chips rather than working in 32-bit mode.

That would give an architecture string of “x86-64”, “amd64”, “em64t”, “x64” or whatever else it is being called these days.

Leave a Reply

Your email address will not be published. Required fields are marked *