How to Determine Exactly Which Model of iPhone/iPod Is Running Your App

Updated 8/18/09: Added info for 3GS (Thanks Jamey).

Erica Sadun recently shared a great post on Ars Technica showing how to determine specifically which model of iPhone or iPod Touch is being used, as opposed to the high-level “iPhone vs. iPod Touch” information made available via the UIDevice -model: method. As she points out, knowing the exact model can be pretty helpful as there are some significant differences between the different devices (e.g., the second-generation iPod Touch has speakers, while the first-generation model does not).

In a nutshell, you use a C function called sysctlbyname to get the hardware model (and if you’re not familiar with doing stuff in C like manually allocating and freeing memory, the code sample is really helpful). Here’s a snippet from the original post:

- (NSString *) platform
{
  size_t size;
  sysctlbyname("hw.machine", NULL, &size, NULL, 0);
  char *machine = malloc(size);
  sysctlbyname("hw.machine", machine, &size, NULL, 0);
  /*
  Possible values:
  "iPhone1,1" = iPhone 1G
  "iPhone1,2" = iPhone 3G
  "iPhone2,1" = iPhone 3GS
  "iPod1,1"   = iPod touch 1G
  "iPod2,1"   = iPod touch 2G
  */
  NSString *platform = [NSString stringWithCString:machine];

  free(machine);
  return platform;
}

Clint Harris is an independent software consultant living in Brooklyn, New York. He can be contacted directly at ten.sirrahtnilc@tnilc.

Tags: iphone_dev, objective-c

Al

Except this is a terrible way of checking for avaliable features, as like most of Sadun’s stuff, it’s neat but not vusable in production code.

If you want to check if the device your code is running on has a speaker or not, use AudioToolbox to check avaliable audio routes. In an app I’m working on, I check kAudioSessionProperty_AudioInputAvailable to see if we have a mic or not (binding a property listender to kAudioSessionProperty_AudioInputAvailable). If I just checked the device model I’d have no idea if a headset were plugged into an iPod Touch or not.

Test for features, not devices.
https://clintharris.net Clint

@Al: Good point, especially considering the inevitable arrival of new devices (i.e., instead of worrying about which of the many devices is running your code, just focus on the feature you actually care about). Thanks for sharing.
http://pandav.us David Hodge

I just had an app rejected because we didn’t check for telephone availability. The reviewer said this is exactly how we should do it. I really don’t like the idea of doing this kind of checking… But Apple seems to think this is the way.

In our case, we decided we could deal with new devices by using this specific check only when running 2.0…Because now that 3.0 is out you know all the devices that could ever have 2.0 installed. When we determine 3.0 is running, (by an easy runtime check) we use the [[UIApplication sharedApplication] canOpenURL:@”tel:…”] method to see if the URL can open. I suppose it really depends on what you want to get out of the hardware info… This technique just works for making phone calls.

It’s certainly less then ideal, but this seems to be the way to go.
Jamey

By the way, I just confirmed that the 3G S is “iPhone2,1″. I needed to know this since we care if someone is running a 3G S because our app relies on the new camera lens.

Thanks for the useful post, by the way!
https://clintharris.net Clint

@Jamey: I’ve updated the sample code–thanks for the info!
Nate

Is there a similar way to check if the device has rumble/vibrate capabilities without checking the machine type?
john

Thanks, this was very helpful for me because my application needed to know whether it was looking through a 3G camera or 3Gs camera. I don’t know of any other way to determine the camera hardware. I have tested the reliability on a 3G, 3Gs and Touch2G.
Mithun

Nice article. Nice Blog as well
One question… what about the new “late 2009″ Line of Ipod Touch Models
http://twitter.com/sutibo sutibo

The code above will produce a compiler warning. I was able to remove it by following the instructions given by Tarrant in this post:
http://stackoverflow.com/questions/2144617/how-to-resolve-compiler-warning-implicit-declaration-of-function-memset

In my case, I had to include the following headers to remove the warning.
#include
#include