Where Apple Went Wrong With iOS

It seems that as I become more familiar with and gain a higher understanding of iOS I manage to find more and more parts of the Cocoa Touch framework that I disagree with the architecture of. As I realize these things I can’t help but find myself wanting to rewrite parts of Apple’s own framework. Now, for today, I’ll give them the benefit of the doubt and assume that they made these architectural decisions for very good, perfectly logical reasons. But, from where I’m standing and what I can see and have gathered as of today, I can’t come up with any even slightly logical excuses for setting these parts of the framework up this way.

Take for instance, the UITableViewController, which I have mentioned before. Even though Apple makes the claim that they follow the Model-View-Controller architectural pattern, the way that they setup their UITableViewController_completely, and blatantly, contradicts this claim. All of the methods, protocols, and class types exist to make it work properly, but for some strange reason Apple decided to ignore this fact. Instead they opted to teach all of their developers, young and old, to implement a botched version of MVC, believing it to be true, proper MVC. Personally, I just don’t understand this thinking. I mean, you have it all right there, the Controller (_UITableViewController) and the View (UITableView), as well as a protocol for making your model properly (UITableViewDataSource). Why they don’t teach their developers to implement these methods and protocols properly is beyond me.

Another thing I’ve realized, is that Apple not only completely screwed up memory management of _IBOutlet_s in iOS. But instead of making it work properly just like they did in OSX, they decided they would teach they’re developers to fix it for them!

Let me explain. If you think about it logically, you would assume that when you allocate or retain an object you should also handle the releasing of said object, right? As well as vice-versa, if you don’t actually allocate or retain an object, you shouldn’t release it. Ever! That makes sense, right?

If you agree, then wouldn’t that beg the question; why is it that when you create an IBOutlet, as a simple instance variable, instead of a @property, that you have to make sure you release that variable in your dealloc? You never told it to retain, so why would you release it? So, how did Apple choose to fix this issue? Well, what they did, I must say, is sheer brilliance. Instead of just fixing it by retaining and releasing it properly in their own code, just as it’s done in OSX, they decided they would convince all of their developers that what they should always do is to actually create a @property/@synethize pair for every single IBOutlet they make. If you don’t understand what @property_and @synethize do, simply enough, @property just creates the declaration of a getter and setter for the variable declared, and @synethize creates the implementation of the getter and setter of that variable using the options passed in through the parentheses in the @property declaration. By telling developers to make all of their _IBOutlet_s as @propertys, Apple effectively convinced them to release their _IBOutlets in the dealloc method, thereby fixing their own faulty logic. This way, when the compiler goes through, creating all of the connections for the IBOutlet_s it goes through the setter method, which calls retain on the variable, instead of just automatically calling retain on it, this way the developers can see where they themselves told the _IBOutlet to be retained and therefore, know they should release it.

The problem, however, is that by using this you are actually creating a getter and setter on a controller’s view outlets that no other class should actually have access to. These are view specific objects, that the controller needs access to, not other random classes that happen to have a reference to the controller itself. _IBOutlet_s should be private to a controller, they are meant to be private to a controller, or at the very least readable only by other classes. But, instead you end up with all of your _IBOutlet_s set up to where, you retain and then release them as you should, in order to prevent iOS to retain them and never release them itself. But now they are completely public, and can easily be modified by any and every outside class that can access the instance of your Controller.

Basically, Apple has singlehandedly taught all of their developers, their thousands and thousands of developers, to write their apps so that the developers correct faults in the base design of iOS, instead of just writing it all properly in the first place. I don’t understand why they didn’t just write it properly themselves, especially considering some of these discrepancies are actually architected as they should be in OSX. Why not in iOS? I’m sure there are plenty of excuses out there as to why Apple did these things this way, but personally, I just can’t believe that this was the best way to fix whatever “issue” it was they faced. In my opinion, it was just Apple’s developers being lazy and in the end teaching their app developers to be mildly incompetent.