I really don't like any technology where it works because you learn all of its poor design decisions rather than because it is logical, consistent and instinctive. I dislike Java but for the most part, it is consistent and there are a few things that are a pain (like having to catch exceptions) but to be fair, these are few and far between compared to Objective-C.
Let me give you today's example.
I have to write a custom alert dialog. Why? Not because I need to do something outlandish but because prior to iOS 7, you could rotate the alert dialog using setTransform which was useful when you had to hand-crank the rotation of the device since Apple decided you can't force a rotation. Anyway, as from iOS 7, this is no longer possible for unclear reasons and what really annoys me is that it breaks existing code. The correct way to make changes is to either deprecate something or create a new class and recommend that developers change to the new one, they have only succeeded in forcing even more people to write custom UI classes, something which will only lead to less consistency across apps rather than more.
Anyway, that is another story. As part of this dialog, I wanted to add the buttonTitleAtIndex method as per the UIAlertDialog because I was using it. In order to do this, I thought I would create a dictionary that would map indices to button titles and this function could simply use that to retrieve the button title. So, how to do this? Well, first off, I created an NSDictionary and then tried to use it. I couldn't. Why? Because the NSDictionary is NOT MUTABLE. What does that mean? You can't change it once it is initialised. So only useful if you know the contents when you first create it. You have to use the NSMutableDictionary if you want mutable contents. Now, to me, this is a poor decision. Most languages would use const to create an immutable object - that was even available in C++ - which makes it nice and obvious. The idea that you use two separate classes just to distinguish their mutability does not meet the OO concept that class = identity. In other words, two classes are two different things. An NSDictionary and an NSMutableDictionary are not two different things in identity, they just behave slightly differently.
Well, once that was worked out, I tried to use it to store a key/value pair. In my case, very simple, an integer (or NSInteger) and a string (NSString*). I added the object and immediately got a compiler error: Cannot convert NSInteger to id
So, the solution was to use another class NSNumber, which is a class, and which can therefore be used as a key and utilising its static method numberWithInt to convert the integer into an NSNumber. So all of these poor design decisions take what I would expect to be an obvious action in any language and turn what would look like this in Java/.Net:
myDictionary[itemIndex] = myObject;
into this in Obj-C/iOS
[[self myDictionary] setObject:myObject forKey:[NSNumber numberWithInt:itemIndex]];
Is this really the correct way to write production code that should be maintainable and readable?