Harsh Language

Apple’s in danger! Because they don’t have a modern programming language and runtime, unlike their competitors. And even if they introduced one tomorrow, getting their developers to switch over would be difficult and take many years, putting them even further behind.

That’s John Siracusa’s thesis (paraphrased) in his latest Hypercritical podcast. He mentions Microsoft’s C# and .NET transition, a decade long and still with a significant amount of non-adoption.

I don’t know about that. But it occurred to me that Apple’s transition, when and if it happens, will be far swifter, due to the App Stores.

Microsoft has to convince its developers to switch. With rational arguments! On iOS, at least, Apple can simply require it as a prerequisite of approval. Apple’s unequal treatment of their developers has led to a situation where none of the aspects of such a demand would even be new.

Onerous, sometimes arbitrary approval requirements? Check. Retroactive new requirements that, if not met, will get you yanked from the store after a certain date? Check. Little expectation of influence or bargaining power on the part of its applicants? Check check check!

It amazes me how well-positioned Apple is to force such a transition. I imagine they could go from language/runtime initial introduction to required status for iOS App Store inclusion in less than, say, two years. As long as the iOS App Store remains lucrative, developers have both the financial incentive and the mental conditioning to go along with it.

And does anyone doubt that the Mac App Store will have a similar stranglehold, in effect, on app purchases within 1-2 OS revisions?

DeleGate

One of the first patterns you encounter when you’re learning Cocoa is the way Apple’s view classes extend their functionality with delegates.

If Apple does it with their view classes, it must be a great idea for your view classes too, right?

The answer you’re looking for here is “no”.

Let’s play a game of 20 2 questions, shall we?

1. Is your view class (a) a general-purpose class, intended to be used by future clients in ways you can’t anticipate? Or is it (b) a very specific class used in a very specific, single way?

2. Do you have (a) two or more classes serving as delegates for your view? Or is the delegate (b) always the same class, used in exactly the same way, to the point where you’re not even bothering with respondsToSelector: checks?

If the answers to both questions are (b), then you know what using the delegate pattern buys you for connecting your view class to its “delegate”? That’s right, nothing. And you know what it causes for the people who come in later to maintain your class? A big headache, right again!

For one, they have to spend the time investigating what classes actually serve as the delegate of your view class. They may need to run the app, get it into a variety of hard-to-reproduce states, just to be sure. Certainly, this might not be that big of a deal for one class. But in a large codebase where this “pattern” has been used repeatedly, it can bog things down.

For two, it means they can’t entirely rely on the automated refactoring tools when they want to make changes to the delegate classes. Because delegates are of type id, right? That’s the pattern. So that bogs things down, too.

Let me spell it out: if you have a view subclass (or any class, really) that needs functionality from an associated class, add a typed reference to that associated class. Don’t add an untyped “delegate” reference.

By all that is holy (donuts, CDs, bowling balls, etc.), don’t create your own DeleGate scandal.

And stay tuned for my next post, where I rant for twenty pages about bindings misuse.