Xcode has a little known feature that can save you time, frustration, and ultimately can even improve code quality. Templates are what Xcode uses to create new projects and files — when you create an “Objective-C Class” Xcode is just populating the Objective-C class.xctemplate with your options. While Xcode is stingy about allowing us to create full blown plug-ins, creating new templates is a snap.
The Basics
An xctemplate file is actually (as so many things are in OS X) a folder containing the important bits. The most important part of a template is the TemplateInfo.plist file; it contains the settings and information that Xcode needs to make sense of the other files you provide. Typically you’ll want to have some other files named something like ___FILEBASENAME___.m which would create a file renamed to, for instance, MyClass.m once the template is run. There’s no end to the number of other substitutions you can use, but they are far less useful and I’ll leave it as an exercise to the reader to learn more about them.
TemplateInfo.plist
Most of the keys in this file are self explanatory, things like Description and title. The most useful key and the focus of today is the options key; it holds a dictionary that allows you to request information from the user in order to tailor how Xcode uses the template when creating the new files.
<key>Options</key>
<array>
<dict>
<key>Description</key>
<string>The name of the class to create</string>
<key>Identifier</key>
<string>productName</string>
<key>Name</key>
<string>Class</string>
<key>NotPersisted</key>
<true/>
<key>Required</key>
<true/>
<key>Type</key>
<string>text</string>
</dict>
</array>
This is a very basic but very real options dictionary, it’s the one straight out of the included template for simultaneously creating view & controller. It’s going to tell Xcode to present the following screen to the user:
Not exactly rocket science if we’re honest, but what that will do is give us access to a text variable in our template named productName (which automatically corresponds to ___FILEBASENAME___). You can go a lot deeper with both TemplateInfo and the options array, and I will in a future blog post, but this is where we stop for today.
___FILEBASENAME___.m
You’re almost certainly going to have one of these files in your template, or at least something very similar. There isn’t much to it, Xcode will create a file with the name that was provided substituted in and whatever contents are in the template file will be in the new file (with appropriate substitutions). Here’s a sample file from the included template for view & controller:
#import “___FILEBASENAME___ViewController.h”
@interface ___FILEBASENAME___ViewController ()
@end
@implementation ___FILEBASENAME___ViewController
– (void)loadView {
if(self.nibName || self.storyboard) {
[super loadView];
} else {
self.view = [[___FILEBASENAME___ alloc] init];
}
}
@end
That’s a lot of filebasename. What this does is provide a base implementation for a ViewController (for the view class ___FILEBASENAME___) with an overridden loadView to load the correct view subclass into the view controller. I’ve even included the check to ensure that we don’t clobber the view-to-be-loaded from a nib/storyboard unpacking. The rest of this template is provided for free use below.
Go, Become a Template Master
So I’ve only given you a preview here, and there is more on the way soon — much more! But if you want to do some learning right now, you can check out all of the iOS templates provided with Xcode for Projects and Files right on your own machine. You can find them at
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates
Finally, a link to my file templates repository, which you are free to do with as you please. Contributions are of course welcome. Coming soon is a template that aims to simplify and standardize code reuse.
