Method signatures are often ridiculously long (see NSBitmapRep's initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: method)

Parameter names in method calls are /always/ named. You can't just say obj.someMethod(x,y). It's always [obj someMethodForX:x y:y].

The above combine to make even the most basic operations tedious. Want to trim leading/trailing whitespace off a string? Enjoy [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]

Immutable arrays, dictionaries, sets, strings. I get it, it can be useful for performance to know something is immutable (maybe, I'm not that convinced). But the common use case is most certainly mutable, so /that/ should be the default, e.g. NSArray should be mutable and then if needed there can exist some NSImmutableArray or something. But no, they did it the other way around.

Memory management (up until recently) was neither fully manual nor fully automatic and ownership was based on naming conventions

Being a superset of C, they couldn't provide an object-oriented array class using the normal array syntax, so instead you have tedium like [myArray objectAtIndex:2]

Ditto for strings. Also, you have to prefix string constants with '@'.

Similarly, you can't put "plain" objects into arrays, e.g. [myArray addObject:5] won't work, but [myArray addObject:[NSNumber numberWithInt:5]] will.

And of course you can't just create an array with ['a', 'b', 'c'] but instead have to do [NSArray arrayWithObjects:@"a", @"b", @"c", nil].

Backwards conventions like [NSDictionary dictionaryWithObjectsAndKeys:@"value0", @"key0", @"value1", @"key1", nil];

If I'm going to pay the dev cycle price of a compiled language, it should catch stuff like non-existent selectors at compile time instead of blowing up at runtime

Stack traces from delayed selector calls have zero contextual information

The single inheritance model and a strict class hierarchy discourages writing reusable code. For example, if I have an app that runs on iPad and iPhone and they share a common screen (from the user's perspective although the layout/design might be significantly different), it's a real task to write a common parent class holds the common code.

Many violations of don't-repeat-yourself: if you want to have an object with properties like Foo.title, then the code is roughly:

@interface Foo { NSString *title; }

@property (nonatomic, retain) NSString *title; @end

@implementation Foo @synthesize title -(void)dealloc { [title release]; [super dealloc]; }

Similarly, there's no way to have a truly dynamic object with a clean syntax, e.g. in Python/ruby/js/and a host of others you could have a quick little object you use to pass state around, kind of like a struct that has its members added on the fly, e.g.: x = new Object() ; x.name = 'dave' ; x.age = 3. There is literally no way to do that in ObjC - the best you can do is create mutable dictionary and use its verbose syntax.

We could have a whole extra thread about the toolchain (Interface Builder is an abomination, Xcode often pegs multiple CPUs when it's just sitting there, if you kill the simulator instead of stopping the app via Xcode then you often have to reboot your host machine before you can run the simulator again) but I digress.