High Order Blog

I’m going to be giving a presentation at the Boulder CocoaHeads meeting tonight. If you’re going to be in Boulder, I encourage you to come say hello.

The meeting will be at InspiringApps’ office from 7 – 9 PM.

What Happened

Some time around late afternoon or early evening yesterday, July 27, Twitter pushed out a security update to its OAuth implementation. This security fix had the extremely unfortunate side effect of exposing a bug in how Twitbit submits new tweets and new direct messages to Twitter.

The result of their update and our bug is the now infamous error message everyone started getting at about the same time when sending tweets or direct messages:

We apologize to our customers for this problem.

The Fix

The good news is that fixing this issue is extremely simple. So simple, in fact, that it’s already been done and required changing only a single line of Twitbit code.

Even better news is that we’ve been wrapping up development of Twitbit 1.1 over the last few days and were already planning to submit it to Apple today. We included the fix for this issue into 1.1 and gave it to Apple earlier this afternoon.

What’s New in Twitbit 1.1

Twitbit 1.1 is a significant upgrade from 1.0.1, the current App Store version. Its new features include:

• More granular push configuration
  • Selectively push DMs, mentions, neither, or both for each Twitter account.
• Better push support while the app is running (new message badges, vibrations, etc.)
• New direct message workflow
  • Summary/inbox view that’s modeled after the built-in “Messages” app, organized by user
  • Threaded conversations
• Landscape typing of tweets and direct messages
• Built-in photo browser with landscape support
• Landscape mode in the built-in web browser
• Saved searches
• Person search
• Saved timeline position
• More tweet actions (open in browser, send in email)
• More browser actions (send in email, post link in tweet)
• Customizable tab order
• Customizable re-tweet format
• Ability to view users by their Twitter usernames or real names.
• Lots of other UI enhancements and bug fixes

You can read more about what’s in Twitbit 1.1 on our release notes page.

That Sounds Awesome! When Do I Get the New Version?

The bad news is that Apple’s App Store approval process is notoriously slow. Approval could take a week or more. Worse, they provide no facility for developers to expedite the release of critical bug fixes. We are at their mercy.

We do have one trick up our sleeve, though.

Getting Twitbit 1.1 Before It’s on the App Store

Apple allows for developers to send the application to people for testing without going through the App Store. Apple calls this “ad hoc distribution.”

We encourage Twitbit customers to send us their iPhone or iPod Touch’s device ID, along with their Twitter username. We’ll then send you Twitbit 1.1, which you’ll be able to use until Apple approves “the official version” for the App Store. Once it’s on the App Store, you can simply switch back to the App Store version. You’ll continue to receive all future upgrades for free as normal.

For instructions on obtaining your iPhone or iPod Touch’s device ID, please see Apple’s documentation and follow the steps under “Sending Your Device ID to Developers.” Email us your device ID along with your Twitter username, and we’ll send you a copy.

We’d like to apologize again to all of our customers for this issue. We recognize this is an inconvenience, and we’re doing everything we can to make things easy for our users.

If you have any further questions, comments, problems, or suggestions, please don’t hesitate to contact us.

I don’t want to bite the hand that feeds, but, I’m not going to try and hide it: we’re getting a little frustrated with the App Store approval process.  I won’t complain about the details here, as I’m sure you can find complaints all over the internet, and I don’t think our experiences are unique. Suffice it to say, our app has been in review for about three weeks now and each time we submit we consider approval a near certainty. Well, we’re starting to learn and have decided to take things into our own hands.

Starting today, you can request a free copy of Code Watch Open Source on our website.  Unfortunately, we need to manually provision for devices when we don’t release through the App Store, and we can only provision a limited number of devices. Don’t let that deter you, though, as the process really isn’t that bad.

Hurry up and get your copy! Otherwise, it’s in the hands of a higher power.

Edit: We’ve decided to give away the full version of Code Watch, with full access to your private repos and news feed. Get ‘em while they’re hot!

Our first application, Build Watch, should hit the iPhone App Store later this week so I thought now would be a good time to share a little about our early business strategy. As I’ve mentioned in previous blog posts and elsewhere on our website, John and I are less focused on ideas as compared to methodology and implementation. It’s not that the idea doesn’t matter — it might be the most important factor in determining a product’s success. It’s that we don’t claim to identify good ideas a priori. Build Watch is an example of what this implies about our approach. That approach is to start small.

If you accept that the success of a particular business venture is difficult to predict, you may also believe that vital to your success is not upside, but a limited downside. Moreover, downside is relatively controllable. In other words, if there’s a significant chance any given venture will fail, we can’t afford to invest in just one such venture. The cost can’t be so great that it will ruin our company. The cost in our case is our time commitment — both to develop a product and also to maintain it. That’s why we chose to build an app like Build Watch: one month after the initial idea, we’re on the app store. If its an utter failure? Who cares. We’re only talking about a month of time down the drain. And, as I’ll explain next, utter failure is a near impossibility.

Let’s assume our one-month app sells exceedingly poorly — barely a blip on the bottom line. Was it worthless? I don’t think so. For one, we proved to ourselves that we can deliver a quality application to market. If we couldn’t do that, it might have been time to start looking for jobs. Second, we learned a great deal about new technologies. If we’re serious about Mac and iPhone development, it’s nice to hone our skills on a project where we can afford to have a less than perfect implementation. Third, we’ll get a feel for what it takes to sell something. Will we sell thousands of apps or hardly any? We have a feeling sales might be slow in the early going, but wouldn’t it be a pleasant surprise if we exceeded expectations. Getting some data will be very helpful in setting our longer term direction.

Starting small will produce numerous other benefits. We’ll tend to limit entropy and maintenance costs. It will force our apps to remain simple and user-friendly. We’ll start building credibility which will help us establish reasonable consulting rates, should we decide to more aggressively pursue that route. And perhaps the biggest benefit of all is that we’ll generate ideas as we code. Such ideas will tend to have a much higher chance of success, because, presumably, they’re related to something we’re already building, and are a great deal less uncertain.

We don’t believe this makes us bullet-proof. Of course it’s possible to have 10 small failures instead of one big one. Perhaps the upside of 10 small apps is so limited that even the sum of which won’t allow us to sustain a living. But if that’s the case, we’ll figure it out pretty quickly. We won’t build 10 failures. We’ll adjust and maybe build 3 small failures and one larger one.

But I like our odds. We don’t need the big pay-off. Not yet. All we need is to earn enough to support a modest living. And if we keep costs low, we’ll give ourselves a lot of time to meet that goal. Once met, we can start slowly raising the bar. I’ll take regular growth with a few pleasant surprises over a roller coaster that may lead to riches — but most likely leads to a desk job.