# Any suggestions on how to improve this mobile user agent check?

I've been using the following user agent Regular Expression to detect mobile devices, but I recently came across a few resources that listed a whole host of mobile user agents that I had not heard of before.

Whilst my agent check is only the first step in the detection process - I also have some JavaScript as a fallback - I would like for it to contain the majority of currently undisputed mobile "keywords" so as to optimise the user experience for those handsets. I would also like to keep things as future-proof as possible, but this can only ever be argued with good reasoning and not set-in-stone.

The core of the regexp follows - please note the user agent string has had it's white-space removed. The check is also specifically case dependent. please ignore the newlines, they are for formatting only

/i[Pp]hone|[Mm]obile[Ss]afari|[Ww]indowsCE|[Ww]indows[Pp]hone|
IE[Mm]obile|[Oo]pera[Mm]ini|[Oo]pera[Mm]obi|[Bb]lack[Bb]erry|
[^A-Z]RIM[^A-Z]|[Ss]ony[Ee]ricsson|[Nn]okia|[^A-Z]MIB[^A-Z]/


These are the extra edge-case agents that I've found out about:

/[Ss]kyfire|[Tt]ea[Ss]hark|[Nn]et[Ff]ront|[Mm]inimo|
[Ii]ris|[Ff]ennec|[Dd]oris|[Ss]eries60|BOLT|[Bb]lazer/


My question is, does anyone have any further suggestions, or possible keywords to remove that could cause false positives. For example I do not include Samsung or Android for the precise reasons that they are not unique to mobile agents. I'd rather let agents through to the JavaScript that I'm unsure about.

As a second note, many user-agents report as Like Something - i.e. Like Mobile Safari - should I filter these out of the equation, or if something is reporting this; is it also likely to be a mobile device.

### In response to the first 'not an answer' :)

This is precisely what the JavaScript side of things handles - as there is no better way to determine a device - good point, well made (+1). However using JavaScript/CSS either means a responsive layout or two requests to the same resource (as in JS detects mobile and reloads the mobile version of the page). The site I am planning to use this with next is very image heavy, and the average pageload of a typical "desktop" page is hovering just under the 1MB mark. I am working towards bringing this down, but for the moment "Mobile" is a priority.

It is my opinion that responsive layouts can only go so far to provide a good mobile experience (it is fine for desktop and tablet), which is why with this site we have a seperate Mobile theme instead. This still gives the mobile user the entire power of the site, but, it rewrites and removes a lot of extra weight - i.e. images are optimised for mobile, stylistic addornments are cut down, css is more lightweight, js is designed for mobile environments. Because this new theme is so involved in modifying the content of the site it has to be enabled from the start of the request. So if my "moblie check" falls back to the JavaScript it will always trigger two loads of the page from the server - something I hope to cut down by detecting almost guaranteed "mobile" user agents at the server side, and serving them the mobile theme directly.

Does that make sense? The above is the only time where I would argue the use of user agent checking over anything more accurate.

-
Any reason not to use a case-insensitive flag to avoid all the [Aa] character classes? Additionally, it would seem to me that you could simply surround the branching in \b word-boundary "characters", or put the [^a-z] classes there. E.g. /\b(iphone|mobile| ... |nokia|mib)\b/i –  Flambino Nov 11 '12 at 1:07

This is not an answer to your question.

It is better to detect features than devices, for example using CSS media queries to cater for small screens, or jQuery UI Touch Punch to handle touch events.

The most important question is WHY you want to detect a mobile user. What will you differently for them?

-
I've expanded my question to answer your question. Thanks for the points and I agree for 9/10 situations -- my requirement is just in that 1/10 at the moment :) –  pebbl Oct 25 '12 at 22:24

First of all I guess your first step of the detection process is processed server side because you said there is a fallback which is processed by JavaScript. Therefore I guess you only perform a HTTP User-Agent check so far.

## Suggestion BlackBerry

I would recommend to add also a check of the Accept request header to your first step of detection.

In one of my recent projects I ran into trouble cause the HTTP User-Agent detection of BlackBerry failed in some cases. For these casees I had to add an Accept request header check which looks for /vnd.rim/. I didn't find out much about the background why it happens. I only know some BlackBerry browsers try to emulate IE or Firefox.

### Example

Taken from the BlackBerry 8120 device specification document: application/vnd.rim.html

## Suggestion J2ME Devices

Clients using this technology might be quite rare but to be sure you could include another RegEx for midp to cover all kind of MIDP devices.

## Question

I know they're dead but I think there are still some around. What about Palm and webOS devices?

-
+1 Thanks for the good points, and pointing out that I had totally missed to state server side, my bad :) you are correct in your assumptions. I had not considered the Accept request header at all, I shall do some research... –  pebbl Nov 7 '12 at 21:35