High Order Blog

We’ve released our first application! It’s a continuous integration client for the iPhone. You can learn more about it (and purchase it) at the Build Watch product page. If you want to tell us how awesome it is, or suggest an improvement, please contact us at feedback@highorderbit.com.

We plan to invest a modest amount of money in advertising, and perhaps post the resulting sales on this blog. We’re also underway with our next app in the “Dev Watch” series, which we’ll be blogging about soon. So, if you haven’t yet done so, subscribe.

One of the first things many users of Xcode want to do is customize the file templates used to generate stubs for classes and other items in your project. We’re spending most of our time building iPhone applications, so we’re interested in customizing the Cocoa Touch templates.

Losing __MyCompanyName__

Getting rid of the __MyCompanyName__ placeholder is almost always the first thing people want changed when they start using Xcode. This can be done in one of two ways.

Set Your Company in Address Book

Definitely the simplest method: just set the company field for your personal card in Address Book.

Set Your Company Manually

You can set your company manually by running the following command in your terminal:

$ defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions \
  '{"ORGANIZATIONNAME"="High Order Bit";}'

Customizing Cocoa Touch Templates

You’ll save a lot of time over the long term with a bit of up-front investment configuring Xcode with your own templates.

You can find the standard Xcode Cocoa Touch plugins here:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/
    File Templates/Cocoa Touch Classes/

Each directory with the extension .pbfiletemplate is its own template.

You don’t want to edit these files. While doing so will work, the next time you install Xcode, your changes will be overwritten. Instead, you should place your custom templates within your home directory (create these folders if they don’t already exist):

~/Library/Application Support/Developer/Shared/Xcode/File Templates

Inside the File Templates directory, your templates must be placed in a Cocoa Touch Classes directory. This directory can either sit directly within File Templates, or you can create subfolders to further group your templates. For example, I’ve created a High Order Bit subfolder where the templates include our standard comment header and the boilerplate code is formatted per our coding conventions.

We’ve also added to the list of available templates, adding one for creating new protocols and another for creating class categories. Creating new templates is pretty self-explanatory once you crack open the .pbfiletemplate folder contents.

We keep these templates in source control. I want Xcode to pick up changes automatically when I pull from our repository, and I want to easily share any local changes I make. I could just clone the repository into the Xcode File Template directory, but I prefer to keep them in the directory where I keep the rest of my source code and create a symbolic link to this location where Xcode expects it:

$ ln -s $HOME/src/xcode-configuration/File\ Templates/Cocoa\ Touch\ Classes \
  ~/Library/Application\ Support/Developer/Shared/Xcode/\
  File\ Templates/High\ Order\ Bit/Cocoa\ Touch\ Classes

Done! Your own custom Xcode Cocoa Touch templates, tracked and shared in source control.

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.