
Back before my iPhone was torn from me (sniffle) for the Round Robin, Twitteriffic was (and will be again) my mobile Twitter client of choice. Since TiPb has also been looking into App development and iPhone UI lately, this all added up to make Craig Hockenberry’s post today on furbo.org especially interesting. Hockenberry talks about the importance of making choices in development, about what features to add and what to leave out, and perhaps most importantly to us, in variety of different approaches:
There will always be more than one way to solve a problem: a developer’s personal preferences will inevitably seep into the implementation. Having many choices for a Twitter client means that developers don’t need to create a “one size fits all” solution. In essence, users get to choose a developer whose preferences match their own.
If you’re at all interested in a behind-the-curtains peak into what makes a good app great, be sure to read the whole article.
Also, let us know if you’re currently using Twitterrific, if what he mentions was already obvious to you, or if you’re using another Twitter client, what you’re using and why you prefer it?

Twitter, Twitter, Twitter, oh how I love thee. Now I can really love thee with Twitterrific for the iPhone! If you are a fan of the very popular microblogging service Twitter, you are in for a rare treat with Twitterrific for iPhone from The Icon Factory! This application comes in two flavors: a free version with a very unobtrusive banner at the top or a paid version for $10 with no banner advertising and an extra theme.
Read the rest of this entry »

The iPhone SDK will not allow 3rd party apps to multitask or run background services. We’ve previously covered both initial developer Twitter-rage at this, and pundit counter-points. We’ve also covered Craig Hockenberry before — the man who (perhaps poetically) develops Twitterrific for the Mac and jailbroken iPhones, and is now bringing it to the SDK.
Hockenberry, via his furbo.org blog, shares his experience on iPhone development and his views on the multitasking (non-?) issue.
To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.
Wha-wha-wha-what? Please, allow Mr. Hockenberry to continue:
Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”
Hockenberry goes on to discuss the power demand problem of the radios, both EDGE and Wi-Fi, and the danger of even well-intentioned developers getting individually reasonable but collectively overwhelming access to background services. He does, however, expect that in a future release Apple may include some method of notifying network apps that the radios are being used (for example, by MobileMail Touch), and allowing brief TCP/IP connections during that period. Bottom-line, at the OS’s discretion, not the individual apps’.
Sound reasonable? Sound crazy? Should Apple give unfettered access to everyone immediately an trust users to sort through it themselves? Or should Apple be as strict as possible from the get-go? What do you think?