Looked at one way, that's a 200% estimation overflow. But more realistically, it means it was pretty small and I tackled it in the wrong way. I had to refactor some code early that I left alone for too long. I should've written in the right way to begin with, and I should have realized it was wrong sooner, and I should have stopped trying to make it work.

More pragmatically, maybe I should have known better. But, of course, I didn't. And that's okay! I know better now.

What's my point in posting this?

Mostly, it's this: iPhone development isn't nearly as hard as I've made it out to be. Useful applications can actually be quite small and still be useful. Simple things are simple. When they're not simple, it's time to fix something.

I'll post a link here when I finish the project. It'll be a bit before I can devote another day to it. But I'm excited by its usefulness, its simplicity, and the idea of having an app in the App Store of my own.

I started at the most basic level, wondering at the language. What are these brackets? What's with the @ signs? What's the difference between a - and a +? These aren't hard things to learn, but understanding the reasoning behind them helps. And then there's a point where it suddenly makes sense.

But the framework was confusing. How do I do this? Though I was less confused, this one isn't solved directly. I became competent. And I started to ask the best question: "Why?"

The patterns were still confusing. Why does this work this way? What's the purpose of this? Why is this done, but not this other thing?

And then there was a point where the patterns became obvious. More, the pattern in the patterns became obvious to me. And now, I look to find more examples of patterns, and patterns of patterns, to better build my knowledge.

It took me a while to get here, and it's the same for every language. I'm feeling pretty confident about Objective-C now.

Back on the first day, I was confused and lost.

By that, I mean that aside from the standard keyboard shortcuts (Save, Copy... that sort of thing), none of the keyboard shortcuts made sense to me.

So I duplicated one of the keyboard shortcut profiles and deleted most of the keyboard bindings. I was brutal with it — if the combination didn't make sense to me OR it was something I'd rarely use it was removed. Then I added keyboard shortcuts that I needed. By using about an hour to customize these settings, I ended up having keyboard shortcuts that I fully understood and rolled off my fingertips.

At this point — and this is where it became a useful exercise — I added my ~/Library/Application Support/Xcode to version control so I could easily sync it between computers. So when I find something that isn't quite working out for me, I make a change and propagate it to my other system.

Am I going to share what I ended up with? No, because that's not the point of this. Rather, I want to point out a simple fact of Xcode: Xcode will adapt to how you want to use it, and if you feel like you're suffering at all with it you should spend the time it to takes to make it enjoyable to use.

And when someone tells me I can do something with a particular keyboard shortcut, I switch back to the defaults and see what it's bound to.

Should your new application support skins?

Probably not. Skins are often a programmer's way of saying "Oh, I don't do UI. We'll let someone else get it right." Only nobody ever does, at least not in your product. Your UI just isn't as compelling as the one it's replacing.

The corollary to this is that if lots of people are demanding skins, it means your UI sucks. Once you add skins, you'll never be rid of those skins, and you won't have fixed your application either.

You'd probably do better to fix your application's appearance and behavior.

Now, should you do a custom appearance?

If you're planning a completely custom appearance for your applications, odds are it will suck. Unless you have artists that are beyond simply competent, but brilliant, you'll probably fail.

First, you need a UI that looks and feels good. Secondly, it probably needs to fit in with the native platform. If you're planning a full screen game, it's fine to not fit in. But if you're building a Windows-based BIOS updater, that custom UI that you think looks so amazing? The truth is, it looks like complete shit.

You're better off fitting custom UI into the OS rather than changing your whole application to fit them.

Now, finally: What about plugins?

This one is a little less clear. There's great reasons to do plugins. Integration with another system (whether technical such as a web site or social such as particular requirements for reporting) is a good one.

But you know what isn't a great reason? Making your product a platform. Do you want to be a product people use, or a platform people struggle with?

Firefox's plugins make me flinch. They're usually poor quality, craptacular tools that lunge for a particular nugget of a good idea and fall flat on their faces a few yards away from it. There are a few that are interesting, but they'd benefit from being rolled in, or being a separate stand-along product on their own.

Pick your features carefully. 37signals didn't become popular by picking an extensive list of features or allowing people to write their own features. Instead, they built something they wanted to use. And they're not alone. There are a few things I'd love to see (MarkDown instead of Textile, for instance), but even if a hypothetical plugin system could add these things, they'd be overwhelmed by the layer of suck.

Before you build a plugin architecture, put the effort into your application.

Xcode will automatically recognize iPhone OS 3.0.1 and look for a new SDK at a set path. The problem is that SDK doesn't exist. The good part is that the iPhone OS 3.0 SDK works perfectly for developing 3.0.1. The only apparent change is the SMS fix.

Assuming you've installed to /Developer, the iPhone OS 3.0 SDK is here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0 (7A341)

When using Xcode with iPhone OS 3.0.1, Xcode looks for the iPhone OS 3.0.1 SDK here:

/Developer/Platforms/iPhoneOS.platform/DeviceSupport/3.0.1

The trick, then, is to build a symbolic link that connects what Xcode is looking for with what it needs to find.

So what do you do? Assuming you've installed Xcode in the standard location, this is a Terminal command to fix the problem:

ln -s /Developer/Platforms/iPhoneOS.platform/DeviceSupport\

DeviceSupport/3.0.1

(I've split this into three lines to make it easier to copy and paste with the \ line continuation character.)

This will not add a SDK to Xcode's list, it will just teach Xcode to map your device to the 3.0 SDK.

A few other tips:

• If you still can't debug restarting your iPhone may help. Most of the iPhones I've tried to debug on, I've had to restart first.
• If you get an error regarding code signing, try downloading your provisioning profile again and re-installing it. Also, select it again in your build settings.

Based on information from iPhone OS 3.0.1 Advisory.