I\'ve seen in some projects something like:
#if .....
code...
#endif
but i can\'t find it now...
Let\'s say, for example, if the ap
As Steven Fisher said, you should not check for the system version but for the availability of the class or method you want to use.
The check if a specific class is available use
if ([NSHologram class]) {
// Create an instance of the class and use it.
} else {
// The Hologram class is not available.
}
To check if a specific method is available use
NSString* hologramText = @"Hologram";
if ([hologramText respondsToSelector:@selector(convertHologram)]) {
[hologramText convertHologram];
}
Yet for the method checking, the method must be available on the system where you build your app, or else you will get a compile error.
You're probably asking the wrong question. Except in very rare cases, you should not care what system version the user is running. Instead, you should be checking if the specific thing you're interested in is available.
For instance, if Apple introduces a MagicHologram class in Mac OS X 10.9 that you want to use, you don't check if the user is running Mac OS X 10.9. Instead, you check if the MagicHologram class is available. If it is, you can use it. If not, it's not available. It doesn't even matter why. Maybe they're running 10.8. But maybe it's five years later, and Apple's decided to drop the MagicHologram class entirely.
(Also, keep in mind that you'd need to weak link to HologramKit, the library that provides the MagicHologram class.)
Likewise, if they introduce a new method to NSString, instead of checking the OS version you'd check if NSString knows about the new method.
That said, NSApplication.h includes an external constant called NSAppKitVersionNumber
. You can compare this to constants like NSAppKitVersionNumber10_7
which (it should be noted) are numbers like 1138, not 10.7. There's only a few places this is appropriate, mostly where classes were private and undocumented but got major changes before being documented and becoming a part of the public parts of the SDK. Also, it might be helpful if you want to avoid a specific bug that's been fixed since.
To recap:
NSAppKitVersionNumber
and NSAppKitVersionNumber10_7
to cover those cases where class or method detection would lie to you.operatingSystemVersionString
, which is specifically listed as not safe for parsing.References/more information:
You can get the current release from the uname -r
command (that's actually the kernel release, though it's easy to map onto Mac OS X versions), from the sw_vers
command which gives you the release name, version and build identifier, or from the Gestalt()
function (on current versions of Mac OS X, anyway). The safest way is probably to read the output of sw_vers
which is in a stable format that's easy to parse.
Notice that you probably don't want to know what version of the OS you're on, though. What you probably want to do is to test whether a particular feature is available. You can do this by weak-linking frameworks, by weak class references, or by inspecting whether a class responds to selectors appropriate to the feature you're interested in.
Here is code for how I do it. I love it this way, mainly because I don't have to A) Rely on an NSTask or B) Rely on any File I/O that many processes have access to.
static NSString* const kVarSysInfoVersionFormat = @"%@.%@.%@ (%@)";
static NSString* const kVarSysInfoKeyOSVersion = @"kern.osrelease";
static NSString* const kVarSysInfoKeyOSBuild = @"kern.osversion";
- (NSString *) _strControlEntry:(NSString *)ctlKey {
size_t size = 0;
if ( sysctlbyname([ctlKey UTF8String], NULL, &size, NULL, 0) == -1 ) return nil;
char *machine = calloc( 1, size );
sysctlbyname([ctlKey UTF8String], machine, &size, NULL, 0);
NSString *ctlValue = [NSString stringWithCString:machine encoding:[NSString defaultCStringEncoding]];
free(machine); return ctlValue;
}
- (NSString *) getOSVersionInfo {
NSString *darwinVer = [self _strControlEntry:kVarSysInfoKeyOSVersion];
NSString *buildNo = [self _strControlEntry:kVarSysInfoKeyOSBuild];
if ( !darwinVer || !buildNo ) return nil;
NSString *majorVer = @"10", *minorVer = @"x", *bugFix = @"x";
NSArray *darwinChunks = [darwinVer componentsSeparatedByCharactersInSet:[NSCharacterSet punctuationCharacterSet]];
if ( [darwinChunks count] > 0 ) {
NSInteger firstChunk = [(NSString *)[darwinChunks objectAtIndex:0] integerValue];
minorVer = [NSString stringWithFormat:@"%ld", (firstChunk - 4)];
bugFix = [darwinChunks objectAtIndex:1];
} return [NSString stringWithFormat:kVarSysInfoVersionFormat, majorVer, minorVer, bugFix, buildNo];
}
Enjoy!
A quick way to do it is:
if ( NSAppKitVersionNumber >= NSAppKitVersionNumber10_7 ) {
// Do stuff for Lion or later
}
More here.
You can see all the constants available in NSApplication.h, which you can get to by using Open Quickly... (Cmd-Shift O) in Xcode.
The header files provide for some surprisingly interesting reading material, if you are so inclined.
As others have said above (and I'd pick Steven Fisher's answer), you usually do not actually want to get the version number.
And if you only need to do comparisons against a major OS X version up to the version of the current SDK you're using, NSAppKitVersionNumber (as in Monolo's answer) is the right way to do it.
If you actually do need to get the version number for some reason (e.g., for recording analytics about your users, so you can decide when to stop supporting 10.6.0-10.6.5), here's how to do it:
#import <CoreServices/CoreServices.h>
SInt32 majorVersion, minorVersion, bugFixVersion;
Gestalt(gestaltSystemVersionMajor, &majorVersion);
Gestalt(gestaltSystemVersionMinor, &minorVersion);
Gestalt(gestaltSystemVersionBugFix, &bugFixVersion);
For 10.7.3, this gives majorVersion = 10, minorVersion = 7, bugFixVersion = 3.
The 10.7 documentation removed the paragraph that directly suggested Gestalt as the way to get OS version, but it's still not deprecated or legacy, and there's no other suggestions. In fact, every other way to get this information (parsing -[NSProcessInfo operatingSystemVersionString], calling sysctlbyname on "kern.osrelease" and converting Darwin kernel version to OS X version, etc.) is explicitly counter-indicated somewhere. So, this is the way to do it, if you really want to.
Just keep in mind that, as the release notes for System 6.0.4 said back in 1989, this new API may not be permanent and could be removed in a future version of the OS.