I also like episode 19 of their podcast, which is edited from a live recording of a planning session for Rework. My first impression of Rework was that it was too finely edited — that to get to the essence they threw away too much material. I wanted to hear more case studies from their business, approaches that worked or didn't, and lessons learned.

But I've flipped through the book again, a few months later, and it holds up. I don't know if it was intentional or not, but the lack of filler text gives it a certain timelessness. Each chapter is one core argument, and whether that topic resonates with the reader or not depends entirely on what you and I bring to it from our own job experiences.

Dave Winer wrote a fairly negative essay a few months ago on this so-called OAuthcalypse:

"When Twitter breaks all the apps in the OAuthcalypse, they will break all of mine, and I have no intention of fixing them. I don't expect anyone to care. But what you should think about is how many of the Twitter apps that you do care about will break and how many of them will say the hell with it? And how many of them will be around for the next time Twitter breaks everything, because that's certainly coming unless Twitter develops some kind of philosophy about itself as a developer platform."

I didn't want to agree with him at first — I'm a big fan of nearly everything Twitter does — but it's a fair question to ask whether backwards compatibility is getting the attention it deserves. Software moves fast, but this kind of thing hurts users, not just developers.

In the desktop world, OS APIs are unlikely to change so severely, and if they do you always have the option to run an older version of the OS or app indefinitely. For web services, though, you can't keep an older copy of the internet around. Web apps are forced upgrades.

I'm not sure there's a solution to any of this. It's just part of tech progress, like moving data from old floppy disks to CDs to hard drives to the cloud. But it's a bummer when apps get left behind as APIs are obsoleted. Over-aggressive deprecation was common in the Rails world, and I was not a fan.

So, here's to the future, Twitter. Keep new API changes versioned and maintain the old stuff. If this OAuth switch is a one-time cost, developers can focus on what makes their apps unique instead of always playing catch-up.

If you're working by yourself and add another person to the project, a funny thing happens: you become a manager. Before, you could spend 100% of your time on the work. Now you can allocate 50-75%, because you're getting the new programmer up to speed, answering questions, and setting priorities. If you're lucky (and I usually am), the person you added is contributing so much that it easily makes up for your loss in productivity, and then some.

The trade-off is worth it. Exchange the previous low communication overhead for extra coding man-hours.

You can build something great with a team, something that would be impossible alone, if you surround yourself with people who are better at your job than you are. I love that first moment when a team doubles in size from 1 to 2, or 2 to 4.

But after the initial frenzy of coding and emails and new features, I usually get burned out again. The project doesn't strictly need me anymore, and I'm ready to get back to starting an app from scratch, when the scope is so small that the whole thing still fits in my head.

"On any project, whether it's a band performance or a team shipping, there's a time to curse, and a time to praise. Someone who gets those in the right order is an inspiring leader. Someone who gets them backwards is just an asshole."

As I mentioned on a recent Core Intuition episode, I have a really hard time remembering who I meet unless I read their blog, or follow them on Twitter, or have heard about their reputation. None of these were true when I first met Mike Lee, walking to pizza one night at C4[1]. I didn't even know at the time that he worked at Delicious Monster. But it didn't matter because he essentially opened with: "I was hit by a car last week."

Bam! World's toughest programmer indeed, and now I'll never forget his face or the conversation. We can't all be as relentlessly passionate and memorable as Mike, but there is a lesson here in personal brand: finding what sets us apart from every other programmer and letting that shape our voice and the projects we work on.

It is fairly well known that after the App Store prompts for your iTunes password, you can download more apps for a certain length of time (at least a few minutes) before it requires a password again. What seemed less clear is that this applies to in-app purchases as well.

To be sure, I ran a test to confirm the behavior:

• Download a new free app from the App Store (I downloaded the current number 1 iPhone app, Farm Story Summer).
• Enter your password to confirm the download.
• As soon as it finishes, go to another completely different app (in my case it was Iconfactory's Ramp Champ, which I had downloaded months ago).
• Purchase an in-app virtual item.
• It prompts for whether you want to buy the item (the standard Apple prompt), but without requiring a password.

What must have happened to Mike is that he bought something, entered his password, and then handed the iPad over to his son. His son played the fish game and clicked a bunch of random stuff (likely got the Buy prompt), but because the whole concept of virtual currency is kind of confusing, and because it didn't ask for a password, the app happily let him make all the purchases.

I doubt the developer of this app did anything wrong. A reasonable argument could be made that iTunes should either not cache passwords at all, or keep a separate cache for app downloads vs. in-app purchases, or maybe always prompt for a password on in-app purchases. My kids and other kids I know have also used this backdoor trick to sneak a couple app downloads, but usually it's a few bucks, not $190. Consumable virtual items (that you can keep buying over and over) make this problem much worse.

On episode 60 of This Week In Startups, Jason Calacanis interviewed ngmoco founder Neil Young about the mobile game business, focusing on the hit iPhone/iPad game We Rule. I was stunned to learn from the show that some individuals spend not only hundreds of dollars but up to $10,000 on in-app purchases in We Rule. Neil Young was happy to take their money, but something feels wrong here, like a gambling addiction gotten way out of hand. Or maybe just kids running up their dad's credit card bill.

For me, there was less urgency to this launch then for previous iPhone releases. I wanted the 3GS on day one (video recording!) and of course I waited all afternoon for the original iPhone (shiny!). Likewise I couldn't wait for the iPad. This time I viewed iMovie and FaceTime as the killer apps. Sign me up!

But I wasn't willing to wait all day. I tried the same approach that had worked great for the iPad: show up late in the day after the madness has settled down. No luck this time. I waited about half an hour, then came back before closing and waited a couple more hours to get a voucher for the next day. Total wait time about 3.5 hours over 2 days and 3 visits.

To get it on day 1, most people waited 6 hours. I'm sure John Gruber's story on Flickr was common too.

This was Apple's most poorly-managed launch I've been to. The 3GS line was pretty fast. For iPad it was extremely quick — in and out in half an hour. I mostly blame the extra step of requiring activation in-store, but there were enough problems that I think this whole thing was mismanaged somewhere.

Some of the inconsistent messages I heard depending on which Apple Store employee I talked to:

• AT&T activation is not the bottleneck / yes it is.
• We are selling 30 phones every 10 minutes / no idea how long the wait is.
• We'll shut down the line at 7pm and give out vouchers / staying open until 2am.
• Vouchers will allow you to skip everyone else in line the next day / you're guaranteed a phone but have to wait in line.

I also collected a few tweets about the launch.

Anyway, the phone. It's the best phone I've ever seen. No question.

Now that some time has passed, I think I can comment on the reception issue. It's real. Outside my house, I don't notice it. But my street is a notoriously bad dead zone, and while I don't get any more dropped calls than I used to, I can no longer hold the phone in the palm of my left hand when using mobile Safari. It's pretty frustrating because I've been holding the phone this way for 3 years. It's awkward to break the habit.

Having said that, I'll close with the same thing I told strangers who came up asking about the phone. It's easy to overlook the reception issue because of how great the rest of the phone is, and all existing iPhone users will love the iPhone 4. Eventually I'll just cave in and buy a bumper.

• 99-cent apps and the race to the bottom.
• Users expecting apps to be cheaper because the device is smaller.
• The high-end successes like OmniGraffle.
• Sales and pricing gimmicks.
• Whether apps can compete outside of the top 100.

So when 37signals launched their first iPad app — Draft, for sketching mockups and quickly uploading them to Campfire — the first thing I wondered was: "how much?" The comments on their launch blog post are a hilarious and sad mix of the usual cheapskates balanced with 37signals defenders. But the most amusing part is that at only $10, Draft is a bargain compared to Campfire itself, which has an entry-level paid plan of nearly $150/year.

(I'm a big Campfire fan, actually. The best iPhone client for Campfire, Ember, has a permanent spot on my home screen.)

My first indie iPad app, a 3-4 week project that has stretched to 3-4 months, will also be $10. At that price it will be twice as expensive as its competition. I'm pricing it that way for three main reasons:

• It's worth the price of two trips to Starbucks, because it takes the category in a new direction with features no one else is doing.
• It's designed for people who are serious about this stuff, not an impulse buy, not for everyone.
• It's a standalone app but includes an optional web complement, offered for free, but which will incur real hosting costs.

Daniel Jalkut and I talked about this a bit on Core Intuition 28 — that it might be okay to overcharge a little for 1.0 rather than raise the price later, and that it should be possible to build a business on the iPad the same way many developers have on the Mac: not by looking for the big overnight hit but by steadily selling some number of copies every day and letting it spread by word of mouth.

Marco Arment wrote about this as App Store B in October last year:

"More of their customers notice and demand great design and polish. More sales come from people who have heard of your product first and seek it out by name. Many of these apps are priced above $0.99. These are unlikely to have giant bursts of sales, and hardly any will come close to matching the revenue of the high-profile success stories, but they have a much greater chance of building sustained, long-term income."

We're three months into the iPad, just passed 3 million devices sold, and not every app has dropped to near-free. I think $10 iPad apps in particular are going to remain pretty common.

iPad interface design is also proving to be much more difficult than I thought it would be. Concepts that work on the iPhone don't necessarily translate to the larger device, and there are very few iPad apps to draw inspiration from. There's no standout app from Apple's lineup either, at least not in the way that iTunes 1.0 defined nearly every Mac app to follow. With the exception of some very basic ideas like splitviews collapsing in portrait mode, and a generous sprinkling of popovers, I've yet to see much consistency from new touch apps.

Apps that have had the biggest influence on me so far: from the iPhone, Birdfeed and Pastebot; and on the iPad, Mail and Twitterrific. Send me a reply on Twitter if you have any other recommendations.

But then I thought more about the $99 hurdle. What was I doing as a teenager and would the procedures Apple has in place now have stopped me? (For context, I'm 34.)

I started programming for the Mac with THINK Pascal, a beautiful little development environment. Then I moved to C with Dave Mark's book, which came with a C compiler on a floppy inside the back cover. Eventually I saved up and bought Symantec C++. Even at an educational discount these were expensive compared to the free Xcode of today.

At that point I'm pretty heavily invested in the Mac, but the killer was the documentation. I'm sure I spent hundreds of dollars on Inside Macintosh books. Our senior year in high school, my friends and I would meet at a restaurant before class for coffee and breakfast. I remember I'd get there early and sit in the booth with one of my oversized volumes of Inside Mac, taking in too much caffeine for my own good while I devoured every page, even the advanced topics that were still over my head.

I lived and breathed this stuff pretty heavily for a few years. To imagine letting a $99 iPhone dev fee and some locked-down APIs prevent me from building apps is laughable. Great computers inspire people to build new software. That's how it was when I got my first Mac, and I'm sure it's that way for the new generation of young iPhone and iPad tinkerers.

One day I hope the App Store will be more open. But it is what it is. I'll point out where I think Apple can improve, and then I'll build and ship anyway. It makes no sense to sit around and complain on my blog about the good old days while some kid half my age is taking his or her idea all the way to the top of the App Store and owning the platform of the future.

The iPhone version of Snowtape, in development for months, was rejected because it could let users record and share audio from the internet:

"His sole words were, that there are lots of things missing in the SDK agreement and that they can not foresee any circumstance that leads to a denial of an app. That's right! We did not violate any paragraph of the SDK, yet they forbid us distributing our app."

The developer removed the ability to transfer audio files off the phone and then Apple let the app through.

Then there's this post on the developer forums about an iPad app rejection because they recreated a UI innovation from the new Photos app. Apple said:

"The application uses a tap and a pinch to expand feature that is present in Apple iPad Applications. This action is associated solely with Apple applications, and we kindly ask that you update your app appropriately."

I've been doing a bunch of iPhone and iPad development this week. The more I work with it, the more I love the platform. But it just takes a couple rejections to sour the whole experience.

And yes, I realize I'm posting this on one of the most exciting days in the history of the App Store. The first round of iPad apps hitting the store today look fantastic.