- (NSInteger)age;

- (NSInteger)age {
    [self willAccessValueForKey:@"age"];
    NSNumber *result = [self primitiveAge];
    [self didAccessValueForKey:@"age"];
    return [result integerValue];
}

He swears this boilerplate code is untouched Xcode-generated code, but every Xcode I tried only generated object-based code. (Spoiler: he doesn’t remember, but I think he must have written it himself, like Apple recommends.)

Xcode doesn’t even generate object-based boilerplate anymore by default. As of 10.5 and up, the runtime will create object-based getter/setter methods for you, so Xcode only generates property stubs, like this:

@property (nonatomic, retain) NSNumber *age;

@dynamic age;

Very nice, but Xcode 4.2 has a curious new checkbox called “Use scalar properties” in the class generation sheet:

When you check it, the new property declaration/definition is indeed scalar-based:

@property (nonatomic, retain) uint16_t age;

@dynamic age;

Could I use this to replace the mysterious boilerplate in my coworker’s class? Well….

If you build and run this, it’ll work just fine sometimes. But some people have reported problems with it. (Can’t find the link right now, sorry.) The trick is that this new ability to generate scalar-based getter/setters at runtime is limited to iOS 5 and Mac OS X 10.7 “Lion”, and won’t work on earlier versions of those OSes. (To make matters worse, Apple’s documentation hasn’t been updated to mention this scalar functionality at all.)

Hm…I want the benefits of runtime-created getter/setters, which will almost certainly be more efficient than manually boxing and unboxing NSNumber objects in my own code…but I also want to support the older OSes. What’s a programmer to do?

mogenerator to the rescue!

mogenerator is…well, I’ll just put in the “elevator pitch” from the website:

mogenerator is a command-line tool that, given an .xcdatamodel file, will generate two classes per entity. The first class, _MyEntity, is intended solely for machine consumption and will be continuously overwritten to stay in sync with your data model. The second class, MyEntity, subclasses _MyEntity, won’t ever be overwritten and is a great place to put your custom logic.

mogenerator’s default template declares object-based getter/setters and also declares a second set of fully-implemented scalar-based getter/setters. For example, if the object-based accessor is age, then the the scalar-based getter is ageValue.

But I want something a little different: I want a scalar-based definition of age and setAge:, but only if the OS is earlier than 5.0/10.7. If not, I want no definition, so that the OS will generate it for me.

How do I do that? Here’s a partial example of a mogenerator-generated “machine” entity source code file, using my custom template:

#import <objc/runtime.h>

#import "OSVersion.h"

@implementation _Measurements

@dynamic age;

static short ageIMP(id self, SEL _cmd) {
    [self willAccessValueForKey:@"age"];
    NSNumber *result = [self primitiveAge];
    [self didAccessValueForKey:@"age"];
    return [result shortValue];
}

+ (BOOL)resolveInstanceMethod:(SEL)selector {
    if ([OSVersion isLionOrGreater] == NO) {
        if (selector == @selector(age)) {
            class_addMethod([self class], selector, (IMP)ageIMP,
                [[NSString stringWithFormat:@"%s@:", @encode(short)] UTF8String]);
            return YES;
    }

    return [super resolveInstanceMethod:selector];
}

There are two tricks here. First is the use of resolveInstanceMethod: to add the method implementation, stashed in the otherwise hidden ageIMP() function. The code here is straight out of Apple’s documentation, so take a look there for details.

Second is the use of the custom class OSVersion, which conveniently tells us which OS version we’re running on. That class is included in my mogenerator-Sample project on github (my first!).

Note: my github project’s sample app uses scalar getter/setters via a rather impractical UI, because for simple projects, object-based methods really fit better with Cocoa design patterns. For example, an object must be used as the value of an NSTableView cell. It’s only when you have more custom UI (or none) that scalar methods start making sense.

The most important detail, however, is that isLionOrGreater must be fast, because it is called dozens of times for even one simple class. In my first implementation, which wasn’t fast, I managed to slow down our iPad app by about 30 seconds (!).

I think the sheer variety we’re seeing, and the, let’s call it the level of teasing, is directly based on how all the content comes from Apple’s servers, not the local copy of iOS on your phone. And that’s for three reasons.

1. Space. As we’ve seen, there are often multiple responses for each phrase. And there are different responses if you’ve repeated a phrase versus saying it new. While each response might only take up a tiny amount of space, 5-10 answers for every single thing Apple engineers think of responding to probably adds up.

2. Schedule. I would bet real money that at least some of the answers that have so tickled the Mac/iPhone tech folks were invented after iOS 5 went golden master, after all the exhaustive testing that was done to ensure that it worked well enough to ship. There just wouldn’t have been time to both finish the feature and add this level of polish for a 1.0 release.

3. Response time. This one’s the killer. I think the reason Apple can provide the cutesy answers that it does is in part because they know they can yank any particular answer in a heartbeat. Otherwise, if they came up with a snarky response that offended someone, that made the news and gave them lots of bad press, the earliest they’d be able to fix it on the device itself might be months away, given other iOS priorities and testing requirements. Apple has a large and busy contingent of lawyers, and I think they would have limited the OS itself to a much more conservative set of responses if they knew they might be stuck with them for a long, long time.

Instead, the Apple engineers must be feeling an unfamiliar sense of freedom. They can provide jokes to statements like “I need to hide a body” and “Talk dirty to me” and “Who’s your daddy”. I’m sure, at some point, we’ll find one that’s in bad enough taste that it’ll make the news.

But we won’t find it for long.

Note #1: I’ve thought a lot about Matt Gemmell’s “SEO for Non-Dicks” article, but I can’t bring myself to switch from whimsical titles to titles “that are relevant to the content”. It’s always going to be a pun or a reference or something. If it keeps me from getting hits, well, I can live with that. Good advice if you’re smarter than me, though.

Note #2: Since I’m talking about snark anyway, I’m going to throw in a plug for Dan Benjamin for his role as co-host on many of the 5 by 5 podcasts. Mostly he’s there to listen and goose things along a bit, but I find that his understated, deadpan snark makes the episodes a lot more enjoyable. The reaction of his co-hosts to the little digs he makes is classic. John Gruber plays along with even drier wit, while both Marco Arment and John Siracusa just kind of pause in annoyance before continuing. It amuses me, anyway.

Many of my colleagues in the Mac/iPhone/iPad developer community had a deep, personal connection to Steve Jobs, which they expressed on Twitter and in blogs immediately after his death. I’ve never seen anything like it, and I’m grateful for it.

Along the way, I saw a number of attacks on those who didn’t stick to the positive: Daniel Jalkut called it “bottom feeding”, and Jeff LaMarche called it “cruel”, “hurtful”, and “little”.

Personally? The unwavering praise combined with a circling of the wagons made me uncomfortable, and awoke my contrarian nature.

Do you think the man who started phone calls with strangers by swearing at them would begrudge a realistic portrayal of himself after death? Articles on public figures, including obituaries, don’t omit flaws and failures. The page-long article from the October 8th issue of The Economist called “The Magician”, for example, has, amid the tribute, a single-sentence caveat in it.

We haven’t had our caveat yet.

2. “Mourning a Billionaire”

Here’s a tweet from Jana Olsen on October 6th: “Kind of weird how we all went from talking about a huge protest against big business to mourning a billionaire.”

The Occupy Wall Street movement started its encampment in New York City on September 17, over two weeks before Steve Jobs died. His death prompted criticism of the group from both the right and the left. The right made fun of the protesters for the contradiction of protesting the actions of the richest 1% while grieving the death of a very rich one. The left hectored the protestors for feeling any sympathy for Jobs at all.

I’m a lifelong Mac developer. I’m also as liberal as they come, and it’s becoming harder and harder to reconcile the two. On the one hand: the Apple vision of ever-sleeker, ever more useful devices connected to a burgeoning global network of information. On the other: the end of the Western way of life when the oil dries up with no realistic substitute. On the one hand: a thriving consumer market and developer ecosystem providing a good standard of living for many of my colleagues and friends. On the other: deepening unemployment and inequality, fostered by a corrupt media and political class.

3. “Steve Jobs Didn’t”

The always insightful Horace Dediu wrote a clever article using the deflation of some of the myths attributed to Steve Jobs to point out his true accomplishments.

I’m going to be less original, and point out the things that he really didn’t do:

1. He didn’t challenge the entrenched, monopolistic power of most of the industries Apple got involved with. While the big music labels are dying, that’s not Apple’s doing, and in some ways Apple helped prop them up temporarily by dragging them into the digital age. Apple has done nothing to disrupt the movie/television/cable industry that’s in the process of killing TiVo and Netflix. And the telephone carriers, while they can’t dictate phone models like they used to, still follow anti-consumer practices with impunity.

2. He didn’t break the glass ceiling or the tech industry boy’s club. The current Apple executive bios page contains no women. The parts of Apple that I saw had the same lopsided ratios of men to women in their engineering sections as the rest of the industry. I’m not without blame: when I was a hiring manager at Apple, I didn’t try hard enough to find qualified women candidates, and I’m sorry for that.

3. He didn’t help prepare the industry for the post-peak oil era. Bit more of a futuristic point than the others, and even more crazy-hard, but still true.

4. Perhaps most importantly in the near term, he didn’t challenge two great harmful industrial trends, the outsourcing that has all but destroyed America’s manufacturing base and jobs, and the employment of foreign companies that cut corners and endanger workers in order to keep prices low.

You can argue that none of these things were his responsibility, that he had his own company to run and his own vision to follow (which he did extremely well). You can argue that these problems are simply insurmountable or just the Way Things Are—many do.

The reason I think it’s worthwhile to bring these things up in the context of Steve Jobs, in the context of our Mac community, at this very moment, is that our praise of Steve Jobs brings it all to a head: if he was so innovative and unorthodox and uncompromising, if he could achieve the impossible (if he was, as the Onion snarked, the “last American who knew the fuck what he was doing“), what does that say about how we view these problems when we give him a pass on them? They’re worse than impossible? They’re not anyone’s responsibility?

Or as a beginning, maybe this, trite as it is: there’s a lot of bad shit coming down the pike, and we can’t rely on our heroes to save us from it.

One idea that’s stuck with me in the 8 years (8 years!) since I wrote my first draft of this post is std::swap().

You use std::swap() like so: instead of doing all your work on your actual objects, you do it on temporary objects instead. Reading in a file’s contents, making a change to your document, parsing a user’s input, it all happens detached from your data model. When the work, and all the possibilities for errors, have been slogged through, you use std::swap() to exchange the temporary objects’ content with that of the real objects.

This is important in C++ because codeflow-interrupting exceptions are a much larger part of error-handling, and because std::swap() is guaranteed not to throw.

Why should I care about this in Objective-C? After all, Apple’s developer documentation goes out of its way to discourage any use of exceptions for normal error handling, instead recommending that methods use NSError parameters².

Let’s leave aside that it can be rather cumbersome to add an extra parameter to all of your methods, and to be sure deeply nested errors are passed all the way up. Even if no exceptions are thrown, if you encounter an error in the midst of complex changes to your data model, it can be tough to back all the changes out safely. Using temporaries reduces that risk to zero.

Is it worth it? You may, after all, wind up swapping out your entire data model if the changes you’re accumulating are extensive. If you’re working on a 4 GB image file, for example, then this technique probably isn’t for you.

And what if one of the things you’re changing is a file? Here, too, you can swap a temporary with the real thing in a way that’s virtually guaranteed never to cause problems—at least, if you’re willing to drop down a bit from the high-level Cocoa APIs and use Core Service’s FSExchangeObjects() method. (And are willing to bet that a method that uses FSRef types isn’t going to be deprecated. Hey, they ported it to iOS.) My understanding is that FSExchangeObjects() makes only HFS+ metadata changes, if the two files are on the same HFS+ partition. No worries about running out of disk space, permissions, etc. You can use it for ten files in a row, and they should all Just Work.

1. A fair number of my other colleagues at Apple were C++ fiends.

2. “Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications.”

Really, go read them.

My contribution? Well….

There was a joke going around for a while about how every New Yorker cartoon was funnier if its caption was replaced with “Christ, What an Asshole.”

We all know it: Steve Jobs is a jerk.

I mean that in a lot of ways, but the most important is: he has strong opinions and he doesn’t care what you think.

He doesn’t care what I think. He doesn’t care about stepping on toes. He doesn’t care about making friends. With him at the helm, Apple has ruthlessly exploited its partners, its third-party developers, the media, and anyone else it has leverage over. The only reason it hasn’t attacked its rivals more is because it doesn’t care what they think, either. You either live with it or you don’t.

As an Apple employee, I was delighted to have this awesome weapon pointed outward. It was less pleasant to realize I was surrounded by it. From what I saw, Apple has spent years busily discovering, hiring, and fast-tracking the most razor-sharp, take-no-prisoners assholes it could find throughout its ranks. John Gruber phrases it as, “The company is a fractal design.” I would say: it’s assholes all the way down.

That’s why I’m not worried about my former employer.

I’ve rarely if ever seen unit tests break.
In theory, the tests exist so that when you add functionality to a class or a group of classes in a way that changes the code paths of existing functionality, you’re sure the existing functionality still works. In practice, I’ve seen that either those classes are never touched again, or they’re only added to, not modified, or the modifications are simple enough that they just don’t lead to breakage.

Rewrites don’t bring the tests along.
In my experience, when you’re doing a rewrite of your GUI application code, for, let’s say, a new major release, you’re generally changing the logic in the new code enough that the automated tests don’t come along. So any exhaustive, pre-existing tests you have need to be thrown out. For example, if you’re moving your model to Core Data for version 2 of your app, much of your existing model classes tests are now outdated.

I’ve only had one case where a rewrite kept the same logic, and that was for a recent side project that was more of an example than anything else. And in that case, I wrote the exhaustive tests right before doing the rewrite. That worked really nicely, but, if anything, it’s an argument for putting off writing such exhaustive tests until you know you need them for something specific.

Regression tests tend to run into sorting issues.
I’ve written extensive regression tests for some projects, and I’ve tended to run into problems with sorting. NSArray’s sorting APIs are unstable. So I’ve often had to write extra logic into the production code to provide reproducibility that it doesn’t actually need, for the sake of testing.

Whenever I talk to any colleagues about automated testing, there’s always a wistful quality to it; yes, we don’t have automated tests or we only have a few, but we should be testing everything. We’ll get to it when we have time. You’re not a real developer unless you’ve done it or at least feel inadequate about it.

But in my, possibly limited experience (I did, after all, work on the same app for almost 6 years), I just don’t see them as the panacea that others do.

And not in a good way.

The pattern purportedly heads off this kind of class hierarchy, where the abstract public classes are in blue, and the concrete classes are in black:

The idea above being that for every public, abstract class, like Window and its subclass CircleWindow, you’ll need a full array of concrete classes hanging off of it, like OSXWindow and OSXCircleWindow. That can lead to a proliferation of classes, even in the two-level deep hierarchy shown above.

The Bridge pattern makes it unnecessary to have any more than a single array of concrete classes:

But it does this by making a very brittle assumption: the only concrete method implementations that will ever be needed anywhere in the system can be put into that base implementation class. (Here, WindowImp.)

The example given in the book is drawing. The concrete classes implement DrawText() and DrawLine(), and everything else can be derived from that—geometric shapes, icon borders, etc.

I have no faith in that. There isn’t a single complex architecture I’ve worked on—and why would you use this for very simple architectures?—where you can comfortably put everything you need in a base class like that. You will always need weird, subclass-specific logic, and tossing such things into a base class leads to confusion, lack of proper separation, and maintenance headaches.

“Oh,” you say, “well then, make an Imp class hierarchy and….” Dammit, multiple hierarchies are what this pattern was supposed to solve!

This led me to a series of questions, which, alas, are not answered on the Overview or Mail Help pages I was directed to.

1. Why do I have to agree to the upgrade? If Yahoo can upgrade its mail to be better, why not just do it without requiring me to do anything? Wouldn’t that be better?

OK, so that’s three questions. And actually, there is an answer here. It says, “Due to the new and exciting features within Yahoo! Mail”. But…which features? As I’ll be mentioning below, many of the “features” you talk about are actually just improvements to the service, not features per se, which you shouldn’t need my permission to roll out. So: why? And will I get a straight answer to this question anywhere on your website?

2. Why does your Overview page prominently feature useless Flash videos that don’t tell me anything? Aren’t you trying a little too hard here?

3. Under the “Awesome Features” tab of the Overview page, you mention faster email, better spam protection, and unlimited storage. All for the good, but why did I have to wait until now for these improvements? And as part of this mysterious “upgrade”? I’ve had an email account with you for 10 years, for crying out loud. Is this the first time you’ve made any of these things better? Or are you really just throwing those in to sweeten the “upgrade” I haven’t agreed to yet?

4. Why does the new web email interface, which you tout heavily on the Overview page, look almost as ugly as the current interface? (Now with more purple!) Why do your video tutorials take great pains to crop out the areas of the interface where ads normally reside? Even if the new interface were bee-yootiful, if it had the vast number of ugly ads that festoon the old interface, it would be an unpleasant experience regardless.

5. If these new web abilities of your email are so great, why can’t you get the HTML of your own Overview page right? Here’s how it acts in Safari 5.0.5 if you make the window too narrow:

Before:

After:

And here’s a bit more tomfoolery I found:

6. You mention a new Mobile interface, but never quite get around to mentioning on the Overview page that this is a web interface, not a native interface. What’s going to happen with the native iOS Yahoo mail? Anything? If not, can’t I just keep using that rather than agreeing to this “upgrade”? You mention waaaaay at the bottom of your “Emailing: The Basics” help page that, “If you upgrade to Yahoo Mail Beta, your experience using Yahoo Mail on your mobile device will not be affected”. But (a) that doesn’t answer my question, and (b) why the heck is a question like that on a “The Basics” page which is mostly about the nuts and bolts of using the email interface? Are you maybe trying to hide it?

7. Why does your help page say, “If you aren’t ready to try it out, no problem!” but the email I received say that I only have a month before I have to upgrade?

8. When I was clicking around trying to find information about iOS, I found your page about what operating systems you support, last updated in October 2010. You know what it says? “Mac OSX “Tiger” and “Leopard” (10.4 & 10.5)”. For a service called “New Yahoo Mail”, wouldn’t you have expected someone to go through all the support pages and update them with the most up-to-date information? Doesn’t this say something about your attention to detail? And even if nobody did that, wasn’t Mac OS X 10.6 “Snow Leopard” actually released a year earlier than the last time this page was updated? Or are you actually saying you don’t officially support Snow Leopard? (Let alone Mac OS X 10.7 “Lion”!)

9. Hey, what’s all this in your Mail Beta FAQ about “relevant ads”? Well, OK, you do answer that question in the FAQ itself; it sounds like one of the major things about the new Yahoo Mail is that it scans your email content, like Google, in order to show you ads that are, yes, relevant. That’s really one of the “features”, isn’t it? Part of the “new and exciting features” you mention above? But somehow can only think to mention at all, let alone in any detail, in your text-only, sans-exciting-videos-or-graphics FAQ? That you probably hope will be tl;dr for most people? Hey, at least for now, you let people opt out of it. That’s something.

10. Why do I still use Yahoo Mail?

Let me tell you a bit about what I saw at Apple.

There were at least three places I knew of—in areas you might not expect—where being a relative backwater in the grand scheme of Apple’s priorities helped make a project both better and more enjoyable for the engineers involved.

Let’s tackle the first one: because the projects weren’t anyone’s priority, they didn’t have to be flashy or aligned with unrelated interests or subject to political whims. The engineers could, y’know, just do what they saw fit. Now, I’ve drunk enough Apple Kool-Aid to believe the engineers shouldn’t solely be in charge of a project. There still need to be real designers involved, among others. But the engineers who work day in and day out on a project are often the ones with the best insight on the important bugs, the little annoyances, the things that the actual users want. And given their freedom, they can fix and provide those things.

(The lower-tier engineers are generally not the ones to go to for sweeping, breathtaking new directions. And since Apple’s management skews towards that, you can see why they don’t listen to those engineers very much.)

And the second: because the engineers were allowed to exercise a little judgment and do their own thing, they had more fun. Important Apple projects can be extended death marches, where you both work insanely hard and really aren’t given much creative freedom. Maybe that’s the only way to get the kind of quality Apple provides consistently.

But, y’know, what fun is that?

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?