Update: It appears Apple has done a lot of these things, so thanks!

If you follow me on Twitter, you’ve probably seen my disapproval of the templates that ship with Xcode. Disapproval is a nice way of saying, “The templates are really bad.” So, I have to ask for a favor from everyone. Please submit a bug report to Apple and ask them to change their approach on templates. You can link to this article, copy and paste its contents, or write your own thoughts.

Now, before I point out the bad, I’d like to give my opinion on what a good template should do:

1. A template should minimize keystrokes by adding code you always need and never code you will usually delete.

2. A template can provide simple boiler-plate code for beginning programmers so they can add substance to existing form, without sacrificing rule 1.

3. A template should not make any design or stylistic choices for developers.

I think we can all agree on the first two rules. The third rule is subjective: what is the best design? What is the best style? There isn’t a right answer. Therefore, a template should omit any code that potentially interferes with rule 3. When it doubt, leave it out. Here are two of the worst offenders of these rules:

1. Creating a universal window-based application gives you an abstract superclass for the app delegate, two concrete subclasses of that superclass and two XIB files.

This violates rule 3. There is an alternative design for universal applications that only requires a single application delegate and a single XIB file.

To be honest, this template is very bad. You do not need two MainWindow XIB files. You can have a single XIB file with a window and an app delegate. Check the box that says “Full Screen at Launch.” With this flag set, no matter what device you are on, the window is the right size. You don’t need three app delegates either, here’s an example of a single app delegate that works on both devices:
`

- (BOOL)application:(UIApplication *)app
  didFinishLaunchingWithOptions:(NSDictionary *)opts
{
    UIViewController *rootMaster = ...;
    if([[UIDevice currentDevice] userInterfaceIdiom] ==
              UIUserInterfaceIdiomPad)
    {
        UISplitViewController *svc = ...;
        ...
        [window setRootViewController:svc];
    }
    else
    {
        UINavigationController *nvc = ...;
        ...
        [window setRootViewController:nvc];
    }
    [window makeKeyAndVisible];
    return YES;
}

`

Not only do you not need the multiple app delegate/XIB monster, I would argue you don’t want it either. Why? Where you once had 3 files to maintain (AppDelegate.h, AppDelegate.m, MainWindow.xib), you now have eight. Instead of one class to write your code in, you have three. Adding complexity like this when you can make a very simple if statement in places where the behavior differs seems like a better choice, right?

2. The UITableViewController has code completion tags in it.

This breaks rule 1. Why? When I create a table view controller subclass, there are plenty of things I need to do before I write the data source methods. In other words, I need to write out the model objects that will be presented by the view object.

The code completion placeholders prevent building the application from being built while doing this. Thus, I must replace those placeholders with “return 0;” right away so I can check my work on those model objects as I write. This is extra work that could easily be avoided by just putting a return 0 in there in the first place.

Now, for rule 2: the errors generated by not replacing the completion handlers are not easy for a beginner to figure out. This hurts them more than helps: they have to type code there anyway, let them figure it out without introducing more issues to fix.

These are the two huge ones. There are other smaller ones that I will just list. (Some of these were introduced in [redacted], so my pretext is, “If you’re thinking about or have already done this, don’t do it…”)

1. Don’t put a label that says “My Universal View Controller” on the window in MainWindow.xib. That doesn’t even deserve my rationale.

2. Ivars are by default protected. Placing a @private at the top of every interface ivar block effectively makes the default private. Developers should opt-in to non-default behavior, not have to opt-out.

3. The app delegate doesn’t need to expose the window as a property; there are other ways of getting the window. I find that using the app delegate as an object dispenser to be very poor design – if someone chooses another design, they can add the property on top of an existing ivar.

4. The code doesn’t need to be chalked with comments. Experienced developers just delete it. For beginners, Apple has a fantastic documentation viewer and great content. Beginners need to learn to use that documentation instead of relying on commented cookie cutter code, or else they will never be able to expand their knowledge.

5. If you’re going to add applicationWillTerminate: as a stub to the app delegate, applicationDidEnterBackground: better be in there, too.

6. Every method that could potentially be overridden or implemented does not need to be stubbed in the templates. viewWillAppear:, viewDidAppear:, the rest of the app delegate methods, etc. We know how to write code, we’ll implement those if we need them. Put the necessary stuff in there.

Overall, I wish they would keep it simple. If a developer wants to customize their own templates, then there should be tools for doing that. (In Xcode 3, this is almost simple. In [redacted] 4, it is very difficult. I spent two hours trying to make you guys some better templates; it did not go well. However, the form of those templates leaves me hopeful that there may be a tool in the future…)

This may seem like a bit much for something so small. And you’re right, it is a small amount of time each developer spends correcting the issues. But it still is an amount of time that could be used more productively.

However, I have an ulterior motive. The templates have caused lots of issues for our students and readers. So much so that the next edition of the book will most likely not use anything but the NSObject template. This is either a lot of extra typing or a lot of explanation to the reader for something that they shouldn’t really worry about. (Imagine if, everytime we told you to create a new class, we had to preface it with a 1/2 page of text showing where to delete code from.)

The templates have become cumbersome instead of helpful. Let’s fix that. Here is my compromise: give us some very simple templates that follow these rules in one category of the left hand table, and some “learning” or highly bloated templates in another category in the left hand table. Everyone is happy!

(You can submit a bug report by going here, logging in with your Apple ID and selecting New Problem. Then, fill out the Problem Report Title to be Xcode Templates. Product: Developers Tools. Version/Build Number: 4. Classification: Enhancement. In the details, just fill out the Summary: with a link to this blog post and a quick summary of the issue.)