Objective C: how to check if variable is NSArray or NSMutableArray

Question

How can i check if a variable is an NSArray or an NSMutableArray?

Answer 1

*Note that the implementation of NS{,Mutable}Array has changed since this answer was written. As a result, isKindOfClass: now works. On what platforms where and when, I don't know.

Until it is documented as safe to do so, I would strongly recommend NOT writing code that tries to detect whether a collection is mutable or immutable. Even if it were safe, such a design pattern is almost always indicative of a serious design flaw.

(For those with access) Filed rdar://10355515 asking for clarification.

---

Consider:

int main (int argc, const char * argv[]) {
    NSArray *array = [NSArray arrayWithObjects: [NSObject new], nil];
    NSMutableArray *mutableArray = [NSMutableArray arrayWithObjects: [NSObject new], nil];

    NSLog(@"array's class: %@", NSStringFromClass([array class]));
    NSLog(@"mutableArray's class: %@", NSStringFromClass([mutableArray class]));

    NSLog(@"array responds to addObject: %@", 
          [array respondsToSelector: @selector(addObject:)] ? @"YES" : @"NO");

    return 0;
}

(I'm using non-empty arrays because an empty NSArray is common enough that Cocoa offers a single shared instance as an optimization.)

array's class: NSCFArray
mutableArray's class: NSCFArray
array responds to addObject: YES

I.e. neither -isKindOfClass: nor checking for implementation of addObject: will work.

In short, you can't tell the difference between an NSArray and an NSMutableArray. This is by design and very much the intended behavior. It also holds true for NSString, NSDictionary and NSSet (all of which have a mutable subclass).

That may come as a surprise. The reality, though, is that design patterns that require checking for mutability are confusing to use and incur significant overhead.

For example, if test-for-mutability were a common pattern than all of the methods in Cocoa that return NSArray instances would have to actually return NSArray instances and never return a reference to the internal NSMutableArray that might be being used.

Answer 2

Bad but technically accurate advice...

The only way to do it is to invoke [unknownArray addObject:someObject] inside a @try/@catch block and catch the NSInternalInconsistencyException that will be thrown if unknownArray is immutable (the actual exception could be a method not implemented or a class is immutable exception).

Good advice...

The short answer though is never try to peer inside an immutable object to see if it is internally mutable.

The reason peering at the mutability of immutable objects is prevented, is to support methods on classes that work like this:

- (NSArray *)internalObjects
{
    return myInternalObjects;
}

the object myInternalObjects could be mutable but this method on this class is saying: don't mutate what I return to you. There may be serious dangers with doing so. If the class allows you to change the array, it will have a different accessor or mutator method.

If you have a friend class that needs mutable access to the myInternalObjects variable, then declare a special adapter category that only the friend class imports with a method like

- (NSMutableArray *)mutableInternalObjectsArray;

This will allow the friend (which you are assuming is smart enough to not violate special rules) to have the access it needs but without exposing mutability in a broader sense.

Answer 3

I would do the following-

if([unkownArray isKindOfClass:[NSMutableArray class]]){
  // This is a nsmutable array
}
else if ([unkownArray isKindOfClass:[NSArray class]]){
 // This is a nsarray
}

Answer 4

Use ...

[Array isKindOfClass:[NSMutableArray class]]

[Array isKindOfClass:[NSArray class]]

This will work fine.

Answer 5

If you want a mutable array, make it yourself:

NSArray *someArray = /* obtain from somewhere, could be mutable, could be immutable */
NSMutableArray *mutableVersion = [someArray mutableCopy]; // definitely mutable

// later

[mutableVersion release];

There's very few cases where checking the internal type is a good idea (other answers have already covered those). If you want a mutable array, don't check whether an existing array is mutable, just make your own so that you know it is mutable.

Answer 6

See NSObject's -class method:

NSLog(@"myUnknownArray is of type: %@", [myUnknownArray class]);

You can also check more directly with the +class method:

BOOL isMutableArray = [myUnknownArray isKindOfClass:[NSMutableArray class]];

Answer 7

Here's my little test code, with its results below. It demonstrates the technique of verifying mutability of Foundation collection objects.

Take note that the mutable versions (e.g. NSMutableArray) inherit from the immutable ones (NSArray) and so testing for the class needs attention.

Also the test for implementation of mutable-only methods seems to work find, but may be a little slower than the test of class.

In any way - AVOID using @try and @catch to attempt mutating immutable objects, according to Apple docs these should not be used in deployment code- since exceptions cause stack unrolling which is specifically costly and also prevents and voids lots of optimizations.

id arr1 = [NSArray arrayWithObjects:@"Motti",@"name",@55, @"age", nil];
id arr2 = [NSMutableArray arrayWithObjects:@"Motti",@"name",@55, @"age", nil];

NSLog (@"arr1 isKindOfClass NSArray:%@, NSMutableArray:%@", [arr1 isKindOfClass:[NSArray class]] ? @"YES" : @"NO", [arr1 isKindOfClass:[NSMutableArray class]] ? @"YES" : @"NO");
NSLog (@"arr2 isKindOfClass NSArray:%@, NSMutableArray:%@", [arr2 isKindOfClass:[NSArray class]] ? @"YES" : @"NO", [arr2 isKindOfClass:[NSMutableArray class]] ? @"YES" : @"NO");

NSLog (@"arr1 implements insertObject:atIndex:%@", [arr1 respondsToSelector: @selector(insertObject:atIndex:)] ? @"YES" : @"NO");
NSLog (@"arr2 implements insertObject:atIndex:%@", [arr2 respondsToSelector: @selector(insertObject:atIndex:)] ? @"YES" : @"NO");

id dict1 = [NSDictionary dictionaryWithObjectsAndKeys:@"Motti",@"name",@55, @"age", nil];
id dict2 = [NSMutableDictionary dictionaryWithObjectsAndKeys:@"Motti",@"name",@55, @"age", nil];

NSLog (@"dict1 isKindOfClass NSDictoinary:%@, NSMutableDictionary:%@", [dict1 isKindOfClass:[NSDictionary class]] ? @"YES" : @"NO", [dict1 isKindOfClass:[NSMutableDictionary class]] ? @"YES" : @"NO");
NSLog (@"dict2 isKindOfClass NSDictoinary:%@, NSMutableDictionary:%@", [dict2 isKindOfClass:[NSDictionary class]] ? @"YES" : @"NO", [dict2 isKindOfClass:[NSMutableDictionary class]] ? @"YES" : @"NO");

NSLog (@"dict1 implements setObject:forKey:%@", [dict1 respondsToSelector: @selector(setObject:forKey:)] ? @"YES" : @"NO");
NSLog (@"dict2 implements setObject:forKey:%@", [dict2 respondsToSelector: @selector(setObject:forKey:)] ? @"YES" : @"NO");

and the results printout:

14:30:42.2683 Test[381:286] arr1 isKindOfClass NSArray:YES, NSMutableArray:NO
14:30:42.2683 Test[381:286] arr2 isKindOfClass NSArray:YES, NSMutableArray:YES
14:30:42.2684 Test[381:286] arr1 implements insertObject:atIndex:NO
14:30:42.2684 Test[381:286] arr2 implements insertObject:atIndex:YES
14:30:42.2684 Test[381:286] dict1 isKindOfClass NSDictoinary:YES, NSMutableDictionary:NO
14:30:42.2685 Test[381:286] dict2 isKindOfClass NSDictoinary:YES, NSMutableDictionary:YES
14:30:42.2686 Test[381:286] dict1 implements setObject:forKey:NO
14:30:42.2687 Test[381:286] dict2 implements setObject:forKey:YES

Answer 8

You have to use:

[yourArray isKindOf: [NSArray class]]

since a simple comparization of the classes may fail because your array is probably not a NSArray but of some other low level type. You may also check if your array responds to the methods you need.

[yourArray respondsToSelector: @selector(addObject:)]