There’s one language feature I crave, however, that seems to be entirely dismissed by modern programming languages: immutability. Immutable types are simply types whose instances are unmodifiable. Of course you can create immutable types in many languages, but I’m not familiar with one where you can enforce it and declare a type as such in a public interface.

Immutable types matter because they’re simple, less error-prone, and encourage better designs.

Where’s the appeal in knowing a type’s mutability value? Inheritance. Your class can’t be immutable unless it’s superclass is immutable. And how do you know that if you aren’t granted access to the implementation? You don’t. You guess. Your class’s immutability is conditional on it’s superclass’s immutability. What’s worse, is that your superclass’s immutability might be variable. Because it’s interface doesn’t change, you might incorrectly assume it is backwards compatible with your code.

The problem that comes to mind when I consider treating every class as though it only might be immutable is efficient object creation. If a class is immutable there’s no need to ever create a copy of it. Only one instance is ever needed for a given value. If you know your type is immutable, your copy method is simply a ‘return self’. Or better yet, you don’t implement a copy method.

Admittedly there are some reasons this isn’t so critical. One, memory is cheap these days. Perhaps making unnecessary copies of data is simply something you can usually afford to do. Two, you might assume any overhead in allocating and garbage collecting the redundant data is negligible — probably a safe assumption. Then again, why do what isn’t necessary? And why implement a verbose copy method when it isn’t necessary?

Maybe the feature would add too much complexity to justify it’s value, but it seems like it could fit in pretty elegantly. Add an ‘immutable’ class keyword, which can only be declared on classes whose parents are also immutable. Such a declaration would also limit member variable assignments to the constructor. Child classes can be mutable despite their immutable parents. (This might seem to violate the Liskov Substitution Principle on the surface, but I don’t believe it does.)

What do people think? Is there a flaw in my argument? Is it just not that important? Of course you might prefer a language where this is moot.

Bug Watch is a Lighthouse client for the iPhone and iPod touch. (Lighthouse is our preferred issue tracking system.) We were close to releasing this app some time ago when we got distracted by writing a Twitter push notification server. We planned to come back and finish it when we found some time. Still waiting for that to happen. Here’s a screenshot:

Code Watch is a GitHub iPhone app. This app was available on the iPhone App Store as a free download called ‘Code Watch Open Source’ and as a paid version that provided access to private repos, just called ‘Code Watch’. For now, we’ve dropped the lite version and made the ‘pro’ version a free download.

Build Watch, High Order Bit’s first project, is a simple client for various continuous integration servers (CruiseControl and Hudson). There are many types of continuous integration servers and even more customized configurations. We hope opening up the source code will allow people to implement support for their setup with minimal effort while being able to leverage the full range of Build Watch features.

All of these projects are licensed under the MIT License, which basically means you can do whatever you want with the code. Unfortunately, we don’t anticipate having a ton of time to further contribute to these projects, so we’re hoping they’ll attract some new developers. If that’s you, we’d love to hear from you and answer any questions you might have.

We fall into a useful state of denial during a release phase. We rationalize away problems with our design and conclude the code couldn’t possibly be any better. That’s useful for the purpose of getting something out the door. But once it’s out, and once we’ve had some time to recover from a frantic development cycle, our self-evaluation becomes a little more sober.

In the case of Twitbit 1.1, we really had a problem with the ‘More’ tab. That is, we had 7 functional tabs, but the last three were tucked under an organizational tab called ‘More’.  It just didn’t feel right. We deliberated long and hard about whether to even use tabs — and we’re comfortable with that decision — but are the functions of Twitter so diverse as to justify more than 5 tabs? After all, much of the appeal of Twitter is its simplicity. It wasn’t so much a matter of concrete problems with 5+ tabs, but that it indicated a degree of laziness on our part. It felt bloated; like the UI was too big for the feature set. There was a mentality of “new function, new tab”. Simple solutions are usually best, and our solutions were definitely that. But in this case that reasoning felt like an excuse.

We swallowed our pride and set out to get our app back to 5 tabs. We were open to every possibility, no matter how much work it entailed. You’ll have to wait for Twitbit 2.0 to see exactly how we did it, but we did do it.  5 tabs. I’ll give you a hint: some of the common tricks in our toolbox were persistence, shortcuts and generally considering how other apps solved similar problems elegantly.

The interesting part has nothing to do with 5 being a magic number, but what we observed during this exercise of reduction. The natural assumption is that you’d have to make sacrifices in the UI to support more functionality. Turns out, the opposite can also happen. We learned that there’s an optimal UI density — and it’s possible to be both too dense, but also too sparse. I’m reminded of that saying, “Sorry this letter is so long. I didn’t have time to make it shorter.”.

The result is a UI that feels a lot more powerful and intuitive. Patterns emerge and the app feels more familiar. Where we expected the user to choose tabs before based on arbitrary distinctions, there are now fewer choices. The UI feels more like a helpful guide than it had previously. The tradeoff, in some cases, is the number of taps to get you to your destination. In such cases, elegant shortcuts can help and even make the app feel more familiar and reduce taps.

I’m really pleased we overcame our state of denial. And I think Twitbit users will be, too.

It’s really easy to convince yourself that you just need this view to collect some basic info and be done with it. It won’t need to push other views onto a stack; it will always be the root of the modal view controller. So what do you do? You manually throw a navigation bar in your nib file, slap some buttons and a title on there and you’re done right?

No, you’re not done. You were wrong — you’ll need this view to appear in a stack of views, and sometimes it won’t be at the root of the modal view controller. In this case, I needed to add a help view. Save yourself the trouble and just wrap your view in a navigation controller from the get-go. Set its navigation item (why can’t you do this in Interface Builder, by the way?) and always put your view in a UINavigationController and you’ll have a more portable view. You win.

While I’m on the topic, does anybody else build just about every interface in IB only to redo it in code? Don’t get me wrong, I like the idea of IB, but it seems like there’s always something, whether that’s optimizing drawing, controlling initialization, or realizing everything is a table view cell, anyway, and you don’t need to lay anything out.

My weapon of choice for day-to-day iPhone development is Vim. Of course, at its core Vim is a text editor, not an IDE, so those looking to duplicate the functionality of more modern development environments in Vim have to either look to Vim’s rich plug-in ecosystem, or roll their own.

One of the first problems I wanted solved was to build my programs and fix compiler errors in Vim. I’m trying to minimize the number of times I need to switch between Vim and Xcode (in other words, reduce my Xcode use) as much as possible.

Xcode helpfully ships with a command line build tool called xcodebuild. It should be in your $PATH by default once you’ve installed the Xcode tools:

$ xcodebuild -help
    Usage: xcodebuild [-project <projectname>] [-activetarget]
          [-alltargets] [-target <targetname>]... [-parallelizeTargets]
          [-activeconfiguration] [-configuration <configurationname>]
          [-sdk <sdkfullpath>|<sdkname>] [<buildsetting>=<value>]...
          [<buildaction>]...
        xcodebuild [-version [-sdk [<sdkfullpath>|<sdkname>] [<item>] ]
        xcodebuild [-showsdks]
        xcodebuild [-find <binary> -sdk <sdkfullpath>|<sdkname>]
        xcodebuild [-list]

Vim includes the ability to build programs via make, and, more importantly for me, supports customizing the command-line builder is uses as its make program. All that’s needed is to configure Vim to use xcodebuild as our make program, instead of make, and we should be in business.

For xcodebuild to work properly, the command needs to be run from within the same directory as your .xcodeproj file, or it needs to be told where that file is located via the -project command line option. This is a problem for me, since I like Vim to set its working directory to the directory of the file I’m editing, which is never the same directory that contains my .xcodeproj file. Since my current directory can’t be relied upon, I needed to find a way to dynamically locate the .xcodeproj file in order to correctly trigger a build.

Enter Rake. Anyone whose ever done any Ruby programming is probably familiar with it, and if you’ve never heard of it, I encourage you to check it out. I like to use Rake for simple project automation, including updating my tags file and performing certain git operations.

One feature of Rake that came in handy for solving this particular problem is that when rake is typed at the command line, it will recursively search up your directory tree looking for a Rakefile. That means if I execute Rake from within foo/bar/baz, and my Rakefile is in foo, Rake will find it and run it correctly.

Taking advantage of this, I’ve set up a build task within my project’s Rakefile that will perform the default Xcode build (which is configured within the Xcode project itself) via xcodebuild. The relevant Rakefile snippets looks something like this:

def project_file(root_dir='.')
  Find.find(root_dir) do |f|
    if f =~ /\.xcodeproj$/
      return f
    end
  end
  nil
end

def xcodebuild
  "xcodebuild -project #{project_file}"
end

desc 'Build the default target using the default configuration'
task :build do |t|
  puts %x{
    #{xcodebuild} |
    grep -v "note: This view overlaps one of its siblings ."
  }
end

task :default => [ :build ]

Note that I have to search for my .xcodeproj file because our project structure conventions have it living in a subdirectory of the project root, and I don’t want to hardcode the path or the project file name for project portability reasons. Note also that piping the output through grep is a hack to suppress annoying Interface Builder warnings that I can’t figure out how to shut off in IB or Xcode. If anyone knows how to do this, please share.

Now all you have to do is invoke your Rakefile from within Vim by setting Rake to be your make program by typing:

:set makeprg=rake

Now when you type :make from within Vim, it’ll invoke Rake. If your working directory is within your project’s root directory, Rake will search for your Rakefile, and, when it’s found, invoke the build task. You can also pass arguments to the make command within Vim, so you’re not restricted to running a single Rake task with no arguments.

Since Xcode uses GCC to compile iPhone programs, Vim can already parse the compiler’s output and make sense of compiler warnings and errors. This allows you to navigate to those warnings and errors From within Vim using the standard cnext and cprevious commands.

To load the build output as a Vim window that spans the width of the frame underneath any other windows (important for me as I like to run Vim with two vertically split editor windows and a NERDTree window to the left of those), just type :botright cwindow.

I also set this configuration automatically whenever I edit an Objective-C file via my .vimrc file:

autocmd FileType objc set makeprg=rake

That’s my setup. I hope it helps more people get out of the swamp of Xcode and into an environment that’s actually productive. And of course, any suggestions for improvements, or other tips or tricks, are always welcome.

I can speak to this not only because we’re a small company (tiny, really) building iPhone applications, but because at least one, maybe two, and probably more of our applications could be improved by adding “background notifications,” regardless of whether the implementation takes the form of processing done on our server and a small notification pushed to the phone, as Apple proposes, or processing done in the background on the client.

First, let me say that I can understand the reasons why Apple is hesitant to open up the phone to background processing. My own iPhone currently has about 5 or 6 “pages” of applications. The vast majority are ones I’ve downloaded, run once or twice, and have never run again, a pattern which seems to be representative. Furthermore, the quality of those apps varies dramatically.

Many of these apps would run in the background if they could. Would I want them to? I’m not sure. While it would be possible for developers to write background processes that are well-behaved, and therefore don’t needlessly suck up CPU cycles and battery life, I’m not convinced that would be the common case.

The cost to the user of a misbehaving background app is pretty high. Worse, troubleshooting the problem isn’t exactly straightforward. All the user knows is that his phone seems sluggish, or that his battery life doesn’t seem to be what it was. Is it the phone or an app? If it’s an app, which one out of the 30 or 40 that have been installed is the problem?

I can definitely understand why Apple wants to sidestep this whole issue.

All that said, I think the utility of Build Watch would be increased dramatically if notifications of failed builds could be pushed to users in the background. Let’s consider what would be required for Build Watch to leverage push notifications.

First, we’d have to replicate most of the business logic that’s implemented in the app within a web application. This would include storing the list of servers for each user, the show/hide status of each project (since we don’t want to be sending notifications for projects they don’t care about), and the most recent build status for each project, so we know when that status changes. This would all have to be new code, since we’re not going to be running Objective-C on our web servers. The iPhone and web applications would then have to be maintained in parallel as new features are added and bugs are fixed. (Maybe this duplication means that the architecture of iPhone apps leveraging background notifications will fundamentally shift over time. All important state and business logic will live on the server, and the native iPhone client will reduce to just a pretty front-end.)

Some functionality won’t work at all. For example, it’s currently possible to hide and unhide projects even when the phone doesn’t have an Internet connection. This is just configuration stored locally, so the current implementation is simple. Getting this working in conjunction with push notifications requires us either to forbid the behavior altogether, which is a clumsy compromise, or devise some mechanism for syncing the user’s offline changes with the server’s state. The latter can only be performed the next time the user opens the app while connected to the Internet. In the meantime, perhaps confusingly, they’ll continue to receive updates for projects they don’t care about and/or miss updates for projects they do care about.

More critically, consider people whose build servers are protected behind corporate firewalls. I suspect the majority of our users fall into this category. A web service pushing notifications doesn’t work at all for these users. One might argue that they’re not any worse off than they are now, but push notifications as a general purpose solution has no answer for this problem. Background processes, on the other hand, would work quite nicely.

Next we have to consider cost. Build Watch currently costs $2.99, and that’s a price point we like and will likely follow for future apps that are similar in scope. That’s about the price of a small latte. If we want to support background notifications, we can no longer just code up the app, release, and move on. We now have server processes we have to continue to develop, pay for, and maintain, with no obvious path for earning continuing revenue from the user.

All this must be overcome just so our little app can download a few kilobytes of RSS data and alert the user if necessary. Seems a little disproportionate, doesn’t it?

This becomes an even bigger problem for small shops like us as background notifications become a user expectation. Will users even bother checking out our apps if we don’t support this behavior?

I’m not terribly concerned with the scaling issue pointed out in the Ars article. Granted, we’re not building Twitter clients, but even if we were I’d consider scaling problems to be a good one to have. Several hundred thousand paying customers sounds just fine to me. I’m much more concerned about its limited usefulness for a large class of applications that could benefit tremendously from background processing.

Before I do that, however, let me get the following disclaimer out of the way: I think there’s something weird about issue tracking software. I rarely, if ever, hear anyone praise their issue tracking system — which isn’t the case with other types of software, like version control. And there are all kinds of issue tracking systems out there, which is somewhat unique. These trends probably result from the fact that issue tracking systems are meant to help people in a realm in which we all work very differently. Things like team and organization size and structure, project scope and culture vary considerably and these are just a few factors that determine how we work.

Given that, maybe there isn’t a ‘best’ system. Perhaps we ought to have a million different issue tracking systems to meet our diverging needs. Or perhaps we are the problem. Perhaps we tend to organize ourselves and communicate in dysfunctional ways, and we blame the software for our dysfunctions. I’m sure there’s some truth to both theories, but, regardless, I’ll explain what I want from my issue tracking system:

Not much. I’m a big believer in keeping things simple. Software teams should be as small as possible. That’s the most effective way of managing a project. Sure, issue tracking and project management systems can facilitate communication to a point, but there’s no software substitute for small focused teams. I don’t dispute the fact that some tasks involved with software development like testing and ‘project management’ are quite different from coding, and it’s tempting to hire specialists, create special teams and create software to help manage these entities. And I don’t dispute that these skill sets aren’t necessarily correlated. Furthermore, a great coder is worth his weight in gold despite any deficiencies in other software development skills. I just believe that those skills aren’t mutually exclusive, either. The fewer points of knowledge and dependencies the better. That’s my theory. Simple.

So, specifically now, what do I want from my issue tracking system? I want it to get out of the way. The easier question to answer is ‘what don’t I want’.  

I don’t want ‘workflows’. I don’t want to submit an issue that gets sent to one department for processing, which then sends it to another department upon completion, and so on. Assembly lines are cool, but creative human work doesn’t seem to resemble them.

I don’t want to set a task’s priority. If a team is small and focused, everyone knows how to best spend their time.

I don’t want to estimate how long a ticket will take to implement. I’m always way off. I spent multiple hours yesterday getting a table cell to display properly. In the same amount of time, I probably often times knock off 2 or 3 sizable features. And as far as aggregating time estimations (even with some fancy statistical considerations) to estimate a deadline? Forget about it. What about the five huge features you didn’t expect, the three that ended up not making any sense, and the massive refactoring two weeks into the project? How do you account for those? You should constantly re-evaluate scope and priorities. It’s safe to say ‘this is the focus for the next month and we’ll get at least this far, and nowhere near that far’, but that’s about it. Again, if you’re confident that everyone is working on the most important things, how much does it really matter? What tradeoff would you make?

Interestingly, most of my Lighthouse tickets are less than a couple days old.  There’s no way I could have anticipated those issues before we started development.  I could have anticipated some set of issues, but I would have deleted them over time and created new ones.

Lighthouse doesn’t support any of the above features, and I hope they never do. It really is ‘beautifully simple issue tracking’. Useful features like tags, milestones, powerful search, ticket status and ownership, attachments, extensibility, etc. are all there — and not much else. Check it out.

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.

Installed Custom Templates

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.