9 tips for setting up a new Xcode project

There’s a development podcast called Mobile Couch I’ve been listening to more and more lately. They cover everything from git to ReactiveCocoa to working remotely, and they approach each topic with a great combination of experience, open-mindedness, and humour (and they’re from Australia). Anyways, just as I was really getting into the episodes, they recently decided to say goodbye to the world and announce everything was ending. Sad news indeed. In any case, their final episode came out last month, called “File > New > Project,” and it inspired this article.

Starting a new project in Xcode

For their final episode, Ben, Jelly, and Jake discussed the act of starting a new project in Xcode, and it got me thinking about my process for this. See, I really like starting a new project. It lets me try out new ways to keep things organized, hone my testing approach—and maybe I’ll add a new framework from time-to-time. (Though like many others I’ve been burned, so a little more wary about that these days!)

So I keep a handy list. It’s a steadily evolving list that changes, somewhat, with every project—but mostly it stays the same. So, in honour of Mobile Couch’s final episode, here’s my “File -> New -> Project” routine!

Top 9 Xcode project tips

  1. Auto-incrementing build numbers. With this script, every time you build your project the build number will go up automatically. Under Build phases, add a Run Script phase and drag it before Copy Bundle Resources. Turns out you can double-click “Run Script” to give it a more meaningful name too. Then paste the following:

    buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
    buildNumber=$(($buildNumber + 1))
    /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE"

    Change the current build to 1 (or whatever you like) and you’re good to go! I usually change my version to 1.0.0 at this point too. (This tip’s best-suited for single-developer projects, otherwise builds will be independently incrementing in each local repo.)

  2. Crash reporting. Add Crashlytics and Answers, but (if you like) restrict them to run on Release builds only. The onboarding for Crashlytics/Answers is some of the best I’ve experienced, so not much explanation needed there. To run them only on Release builds, I add the flags “-DDEBUG” and “-DRELEASE” to Build Settings -> Swift Compiler – Custom Flags -> Other Swift Flags (under Debug and Release, respectively). Then I surround the setup call in AppDelegate.swift like so:

    #if RELEASE
      Fabric.with([Crashlytics.self])
    #else
      print("DEBUG MODE: Not registering with Crashlytics")
    #endif

    (The “-DDEBUG” isn’t necessary for this particular block of code, but it’s handy to setup that flag for later.)

  3. Minimum version. Pick the minimum iOS version in Build Settings > iOS Deployment Target. For my Ten Kettles apps, I usually support the most recent two versions of iOS. For some client apps with huge user bases, maybe the last three.
  4. Custom warnings #1. Add a build script to display warnings for certain words that appear in the source files (e.g., TODO, TEMP). I’ve been doing this one a while. I probably could live without it, but it’s handy to have that template in the project to whip up custom warnings when needed. Just add a Run Script under Build Phases with the following:

    KEYWORDS="TODO|FIXME|TEMP|\?\?\?:|\!\!\!:"
    find "${SRCROOT}" \( -name "*.swift" \) -print0 | \
    xargs -0 egrep --with-filename --line-number --only-matching "($KEYWORDS).*\$" | \
    perl -p -e "s/($KEYWORDS)/ warning: \$1/"

  5. Custom warnings #2. After stumbling upon this article by Soroush Khanlou, I’ve started adding warnings for methods that yield particularly long compile times. There have definitely been a couple times in the past where the compiler just takes forever to do its business, and I track it down to some seemingly simple line(s) of code. It’s always been a hassle, but no longer! Just add these two flags to Build Settings -> Swift Compiler – Custom Flags -> Other Swift Flags -> Debug:

    -Xfrontend -warn-long-function-bodies=100

    (100 is the ms limit above which warnings kick in.)

  6. My favourite tools. Here’s where I clone my personal framework into the project. This is the accumulation of utility methods (often as extensions), handy custom operators, and other miscellanea that make it from project to project.
  7. Tidy git. While Xcode takes care of setting up my local git repository, I still need to create my .gitignore file. Just navigate to the Xcode project directory in Terminal, type touch .gitignore, and then open the new file in your favourite text editor. When a project has just started, I’ll often just add two entries to my .gitignore file:

    .gitignore
    Frameworks/*

    (As I’m sure you can guess, Frameworks is the folder where I put all my frameworks.)

  8. GitHub. Setup the project on GitHub, do my initial commit, and push! Then I branch over to my develop branch and get started. (I started using the gitflow protocol last year and so far I’m a huge fan.)
  9. Miscellanea. There’s a grab bag of other steps that I’ll do depending on the project. That could include incorporating a playground into the project (such that it has access to all my target’s classes), adding RxSwift (love the idea, but I’ve yet to find it saves me much time… for my projects at least), and adding Nimble.

So that’s it! A big thanks to the iOS developer community at large for many of these ideas, and StackOverflow in particular for the two Run Scripts. As I said, the list is always changing (e.g., I’ve recently started using a separate AppDelegate for testing) but here’s the current snapshot.

Got any project setup tips of your own? Please share them below. In any case, a fond farewell to Mobile Couch: you guys did some great work!

-Alex (@leakywellington)

One thought on “9 tips for setting up a new Xcode project

Leave a Reply

Your email address will not be published. Required fields are marked *