I didn't really take last week's Twitocalypse that seriously, but as you probably know by now, it turned out a little worse than expected -- we'd been told that Twitterrific (and, we assumed, most other Twitter apps) would be fine, and of course, as Craig Hockenberry explains on his blog, things ended up not-so-fine. Desktop app developers, of course, could publish updates as quickly as they could code them; iPhone developers were in a different situation.
When the Iconfactory's app stopped working, most people (including me) got an API error all weekend. Craig found the bug, then he and his team were able to leverage their contacts at Apple Developer Relations to help expedite the release; in short order, an update was pushed out to the App Store. I downloaded it yesterday, and can tell you that things are fixed... at least until the numerical limit on Twitter's tweet identifier raises its head again (or the Newton flips out, but that's another story).
Hockenberry also has ideas about how to keep issues like this from happening again. Not the actual issue of a variable overflow (that will undoubtedly happen again at some point, on Twitter or any other API that scales way faster than anyone expects it to), but the issue of iPhone apps needing a quick fix. He says that Apple should give every developer a number of "incidents" -- situations rarely used, in which a high priority fix can get sent out to apps in major emergencies. He says, and it's true, that for most developers, it's not a question of if you'll need to send out a critical fix, it's a matter of when. And support by Apple, obviously limited to one or two instances per developer, would help developers, distributors, and consumers.
Of course, it's up to Apple, and it's not like they've smoothed out the approval process so well already that they can start adding wrinkles to it. But clearly, given that the Twitterrific update went through quickly, there's room for exceptions to be made.